Вау, у вас есть какое-то ужасное оборудование для этой проблемы. С аппаратной точки зрения не так уж и много, за исключением обновления до, возможно, процессоров Sandy / Ivy Bridge, чтобы повысить производительность поиска на Btree на 20-50% и т. Д.
Обратите внимание, что моя сильная сторона - Innodb, поэтому я собираюсь
- Не обращайте внимания на то, что вы myisam и ведите себя так, как будто это ничего не изменит.
- Предположим, что эта проблема является достаточным стимулом, чтобы заставить вас обновить. Да, это обновление.
Innodb может помочь в использовании всей этой памяти, храня эти часто используемые строки в своем пуле буферов. Вы можете настроить его на нужный размер (скажем, 80% памяти), и свежие чтения / записи останутся в памяти до тех пор, пока не потребуется перенести их на диск, чтобы освободить место для последних данных. В памяти это на порядок быстрее, чем у ваших FusionIO.
Есть много других функций Innodb, таких как адаптивные хэши, механизмы автоматической блокировки и т. Д., Которые могут быть благом для вашей среды. Вы, однако, знаете свои данные лучше, чем я.
В мире innodb хорошим краткосрочным решением является оптимизация вашего ведомого устройства - действительно ли вам нужен каждый индекс на подчиненном устройстве, который имеется на вашем ведущем устройстве? Индексы - это шарик и цепочка на вставках / обновлениях / удалениях, ДАЖЕ с картами Fusion IO. IOPS не все здесь. Мосты Sandy / Ivy Bridge имеют гораздо лучшую пропускную способность памяти и производительность вычислений - они могут иметь огромное значение для Westmeres, который вы сейчас имеете. (Рисунок 20-50% в целом). Удалите все индексы, которые вам не нужны на ведомом устройстве!
Во-вторых, и почти наверняка применимо только к innodb, mk-prefetch может знать, какие обновления и до того, как ведомый записывает их. Это позволяет mk-prefetch сначала выполнить запрос на чтение, тем самым вынуждая данные находиться в памяти к моменту, когда отдельный реплик выполняет запрос на запись. Это означает, что данные находятся в памяти, а не в fusionIO, что дает быстрый прирост производительности. Это делает ОГРОМНАЯ разница, более чем можно было бы ожидать. Многие компании используют это как постоянное решение. Узнайте больше, ознакомившись с инструментарием Percona .
В-третьих, и, самое главное, после того, как вы перейдете на Innodb, обязательно оформите Tokutek. У этих ребят есть несколько потрясающе классных вещей, которые намного превышают производительность записи / обновления / удаления Innodb. Они отмечают повышение скорости репликации как одно из ключевых преимуществ, и по их тестам видно, что Fusions crazy IOPS все равно не поможет вам в случае Btrees . (Примечание: я не проверен независимо). Они используют вставную замену индекса btree, которая, хотя и ужасно сложна, улучшает многие из алгоритмических ограничений скорости индексов btree.
Я нахожусь в процессе рассмотрения вопроса об усыновлении Tokutek. Если они освобождают так много скорости записи, это позволяет мне добавлять больше индексов. Поскольку они сжимают данные и индексы в таких замечательных соотношениях (25-кратное, как они указывают), вы даже не платите (производительность, обслуживание) за увеличение объема данных. Вы платите ($) за их движок, хотя, $ 2500 / год за предварительно сжатый ГБ, IIRC. У них есть скидки, если у вас есть реплицированные данные, но вы можете даже просто установить Tokutek на подчиненное устройство и сохранить свой мастер как есть. Ознакомьтесь с техническими подробностями в лекции MIT Algoritms Open Courseware . Кроме того, у них есть тонны технического материала в их блоге и регулярные технические документы для тех, у кого нет 1:20 для просмотра видео. Я полагаю, что это видео также дает формулу Big-O для того, как быстро читать. У меня естьпредположить, что чтение происходит медленнее (всегда есть компромисс!), но формула слишком сложна, чтобы я мог оценить, сколько. Они утверждают, что это примерно то же самое, но я бы лучше понял математику (маловероятно!). Вы можете оказаться в лучшем положении, чтобы обнаружить это, чем я.
Ps Я не связан с Tokutek, я никогда не запускал их продукт, и они даже не знают, что я смотрю на них.
Обновление :
Я вижу, у вас есть другие вопросы на этой странице, и я подумал:
Во-первых, предварительная выборка раба почти наверняка не подойдет для myisam, если у вас нет исключительной среды. Это происходит главным образом потому, что предварительная выборка будет блокировать те таблицы, в которые вы собираетесь писать, или у ведомого потока заблокирована таблица, в которой нуждается демон предварительной выборки. Если ваши таблицы очень хорошо сбалансированы для репликации, а разные таблицы пишутся в циклическом порядке, это может сработать, но имейте в виду, что это очень теоретически. Книга «High Performance Mysql» содержит дополнительную информацию в разделе «Проблемы с репликацией».
Во-вторых, предположительно, ваш ведомый имеет нагрузку 1,0-1,5, он может быть выше, если у вас запущены другие процессы или запросы, но базовый уровень 1,0. Это означает, что вы, скорее всего, связаны с процессором, что, скорее всего, с вашим FusionIO на борту. Как я упоминал ранее, Sandy / Ivy Bridge собирается дать немного больше энергии, но, вероятно, этого недостаточно, чтобы провести вас в более трудные времена с минимальным запаздыванием. Если нагрузка на это ведомое устройство в основном предназначена только для записи (то есть, не много операций чтения), ваш ЦП почти наверняка тратит свое время на вычисление позиций для вставок / удалений btree. Это должно подтвердить мою точку зрения об удалении некритических индексов - вы всегда можете добавить их позже. Отключение гиперпоточности не сработает, больше ЦП не ваш враг. Как только вы получите более 32 ГБ ОЗУ, скажем, 64 ГБ, вам нужно беспокоиться о распределении памяти, но даже тогда симптомы разные.
Наконец, и самое главное (не пропустите эту часть;)), я предполагаю, что вы сейчас запускаете RBR (репликацию на основе строк), потому что вы упомянули нетривиальное увеличение производительности при его переключении. Однако здесь может быть способ получить еще большую производительность. Ошибка MySQL 53375 может проявиться, если у вас есть реплицируемые таблицы без первичного ключа. Ведомый в основном не достаточно умен, чтобы использовать что-либо кроме первичного ключа, поэтому его отсутствие заставляет поток репликации выполнять полное сканирование таблицы для каждого обновления, Исправление - просто добавление мягкого, суррогатного автоинкрементного первичного ключа. Я сделал бы это только если бы таблица была большой (скажем, несколько десятков тысяч строк или больше). Это, конечно, происходит за счет наличия другого индекса на столе, который поднимает цену, которую вы платите в CPU. Обратите внимание, что против этого очень мало теоретических аргументов, поскольку InnoDB добавляет один закулисный, если вы этого не сделаете. Призрачный, однако, не является полезной защитой от 53375. Вольфрам также может решить эту проблему, но вы должны быть уверены, что при использовании вольфрама у вас правильная кодировка. В последний раз, когда я играл с ним, он ужасно умирал, когда любая не-UTF8 строка нуждалась в репликации. Это время, когда я отказался от этого.
