Представлены методы оптимизации MYSQL с нескольких аспектов для достижения производительности. Оптимизация — сложная задача, поскольку в конечном итоге она требует понимания всей системы. Несмотря на то, что можно провести некоторую локальную оптимизацию, не обладая глубокими знаниями о вашей системе/приложении, чем больше вы хотите сделать свою систему более оптимизированной, вы должны знать, что это так. и многое другое. Поэтому в этой главе мы попытаемся объяснить и привести несколько примеров различных способов оптимизации MySQL. Но помните, что всегда остаются определенные (все более сложные) способы сделать это быстрее для системы. Самая важная часть повышения скорости вашей системы, конечно же, — это базовая конструкция. Вам также необходимо знать, что ваша система будет делать такие вещи, и это ваше узкое место. Наиболее распространенными узкими местами являются:
Поиск на диске. Время, необходимое диску для поиска фрагмента данных. Среднее время для современного диска, использовавшегося в 1999 году, обычно составляло менее 10 мс, поэтому теоретически мы могли выполнять поиск примерно 1000 раз в секунду. дисков, и это трудно измерить. Оптимизация одной таблицы. Способ оптимизации - распределить данные по нескольким дискам. Диски читают/записывают, когда диски находятся в правильном месте, где нам нужно читать данные. скорость одной передачи на диск составляет 10-20 Мбит/с. Это должно быть проще оптимизировать, поскольку вы можете читать с нескольких дисков в параллельных циклах ЦП. Когда мы считываем данные в память (или если они уже там), нам необходимо их обработать для достижения цели. наши результаты. Когда Это наиболее распространенный ограничивающий фактор, когда у нас есть таблицы с относительно небольшим объемом памяти, но при небольших таблицах скорость обычно не является проблемой. Пропускная способность кэша становится узким местом в памяти, когда процессору требуется больше данных, чем может поместиться. в кэше ЦП. Это редкое узкое место в большинстве систем, но вы должны об этом знать. 10.2 Настройка параметров системы/компиляции и загрузки Мы начнем с системного уровня, поскольку некоторые из этих решений принимаются очень рано. В других случаях беглого просмотра этого раздела может быть достаточно, поскольку он не имеет решающего значения для большого выигрыша, но всегда полезно почувствовать, насколько велик выигрыш на этом уровне. Используемая ОС по умолчанию имеет значение для максимального использования! В определенной степени с несколькими процессорами вам следует использовать Solaris (поскольку потоки работают очень хорошо) или Linux (потому что ядро 2.2 действительно хорошо поддерживает SMP). А на 32-битных машинах Linux по умолчанию имеет ограничение размера файла 2G. Надеюсь, это будет исправлено в ближайшее время, когда будет выпущена новая файловая система (XFS). Поскольку мы не запускаем производственный MySQL на многих платформах, мы советуем вам протестировать платформу, на которой вы собираетесь ее использовать, прежде чем выбирать ее.
Другие предложения:
Если у вас достаточно оперативной памяти, вы можете удалить все устройства подкачки. Некоторые операционные системы в некоторых случаях будут использовать устройство подкачки, даже если у вас есть свободная память. Используйте опцию MySQL -skip -locking, чтобы избежать внешней блокировки. Функциональность MySQL, пока она работает только на одном сервере. Не забудьте остановить сервер (или заблокировать соответствующие части) перед запуском myisamchk. В некоторых системах этот переключатель является обязательным, поскольку внешняя блокировка доступна не во всех случаях. При компиляции с MIT-pthreads опция --skip-locking по умолчанию включена (on), поскольку flock() не полностью поддерживается MIT-pthreads на всех платформах. Единственный случай — если вы запускаете сервер MySQL (не). клиент) для тех же данных, вы не можете использовать --skip-locking, иначе запустите myisamchk для таблицы без предварительной очистки или блокировки сервера mysqld. Вы все равно можете использовать LOCK TABLES/UNLOCK TABLES, даже если вы используете --skip. -запирание.
Как компиляция и компоновка влияют на скорость MySQL
Большинство следующих тестов проводились в Linux и с использованием эталонного теста MySQL, но они должны дать некоторое представление о других операционных системах и рабочих нагрузках. Самые быстрые исполняемые файлы получаются при подключении с помощью -static. Подключение к базе данных вместо TCP. /IP также может обеспечить лучшую производительность. В Linux вы получите самый быстрый код при компиляции с помощью pgcc и -O6. Для компиляции «sql_yacc.cc» с этими параметрами требуется около 200 МБ памяти, поскольку gcc/pgcc требует много памяти. памяти, чтобы сделать все функции встроенными. При настройке MySQL вам также следует установить CXX=gcc, чтобы избежать включения библиотеки libstdc++ (она не нужна). Просто используя лучший компилятор или лучшие параметры компилятора, вы можете получить 10. -30% ускорение вашего приложения. Это особенно важно, если вы компилируете SQL-сервер самостоятельно! На Intel вам следует, например, использовать pgcc или компилятор Cygnus CodeFusion. Мы протестировали новый компилятор Fujitsu, но его еще нет. достаточно безошибочный, чтобы оптимизировать компиляцию MySQL.
Вот некоторые таблицы измерений, которые мы сделали:
Если вы используете pgcc с -O6 и что-либо компилируете, сервер mysqld работает на 11% быстрее, чем с gcc (с версией строки 99). Если вы компонуете динамически (без -static), результат будет на 13% медленнее. по-прежнему можно использовать динамически подключаемую библиотеку MySQL. Только сервер имеет решающее значение для производительности. Если вы используете TCP/IP вместо сокетов Unix, результат будет на 7,5% медленнее. На Sun SPARCstation 10 gcc2.7.3 работает быстрее, чем Sun Pro C++. 4.2 на 13% быстрее. В Solaris 2.5.1 MIT-pthreads на 8-12% медленнее, чем в Solaris с собственными потоками на одном процессоре. При большей нагрузке на процессор разница должна стать еще больше. Дистрибутив Linux скомпилирован с помощью pgcc и статически скомпонован.
Как упоминалось ранее, поиск дисков является большим узким местом производительности. Эта проблема становится все более очевидной, когда данные начинают расти, и кэширование становится невозможным. полагайтесь на тот факт, что вам понадобится хотя бы один диск для чтения и несколько дисков для записи. Чтобы свести к минимуму эту проблему, используйте диски с низким временем поиска. Чтобы увеличить количество доступных дисковых шпинделей (и тем самым уменьшить накладные расходы на поиск). можно символически связать файлы с разными дисками или разделить диск. Использование символических ссылок означает, что вы символически связываете файлы индекса/данных из обычного каталога данных с другим диском (который также можно разделить). раз лучше (если диск не используется для других целей). См. 10.2.2.1 Использование символических ссылок на базы данных и таблицы. Разделение означает, что у вас много дисков и вы помещаете первый блок на один диск, второй блок — на второй диск. , а n-й блок находится на (n mod number_of_disks)-м диске и т. д. Это означает, что если ваш обычный размер данных меньше размера разделения (или идеален (организован соответствующим образом), вы получите немного лучшую производительность. Обратите внимание, что разделение сильно зависит от ОС и размера разделения. Поэтому протестируйте свое приложение с различными размерами разделения. Обратите внимание, что разделение очень зависит от ОС и размера разделения. Разница в скорости во многом зависит от того, как вы разделяете. в параметрах и количестве дисков вы можете получить разницу на порядки. Обратите внимание, что вам придется выбрать оптимизацию для произвольного или последовательного доступа. Для надежности вы можете использовать RAID 0+1 (разделение + зеркало), но. в этом случае вам понадобится 2*N дисков для хранения данных на N дисках. Если у вас есть деньги, это, вероятно, лучший вариант! Однако вам, возможно, придется инвестировать в программное обеспечение для управления томами, чтобы справиться с этим эффективно. Хороший вариант — разместить менее важные данные (которые можно воспроизвести) на диске RAID 0, а действительно важные данные (например, информацию о хосте и файлы журналов) — на дисках RAID 0+ 1 или RAID N, если у вас их много. Из-за обновления битов четности может возникнуть проблема с RAID N. Вы также можете установить параметры файловой системы, используемой базой данных. Простое изменение — смонтировать файловую систему с параметром noatime. Это время последнего доступа. индексный дескриптор, который он не обновляет, и это позволит избежать некоторых поисков на диске.
Вы можете переместить таблицы и базы данных из каталога базы данных в другое место и заменить их символами, которые ссылаются на новое местоположение. Возможно, вы захотите сделать это, например, переместив базу данных в файловую систему, в которой больше свободного места. Замечания MySQL. Таблица — это символическая ссылка, которая разрешает символическую ссылку и использует таблицу, на которую она фактически указывает. Она работает во всех системах, поддерживающих вызов realpath() (по крайней мере, Linux и Solaris поддерживают realpath())! которые не поддерживают realpath(). В вашей системе не следует обращаться к таблице одновременно по реальному пути и по символической ссылке. Если вы это сделаете, таблица будет несогласованной после любых обновлений. MySQL не поддерживает ссылки на базы данных. по умолчанию, пока вы не создадите символическую ссылку между базами данных, все будет работать нормально. Предположим, у вас есть база данных db1 в каталоге данных MySQL, и создайте символическую ссылку db2, указывающую на db1:
оболочка&> cd /путь/к/каталогу данных
оболочка&> ln -s db1 db2
Теперь для любой таблицы tbl_a в db1 также будет таблица tbl_a в db2. Если один поток обновит db1.tbl_a, а другой поток обновит db2.tbl_a, возникнут проблемы. Если вам это действительно нужно, вы можете использовать следующий код. «mysys/mf_format.c» необходимо изменить:
if (!lstat(to,&stat_buff)) /* Проверяем, является ли это символической ссылкой */
if (S_ISLNK(stat_buff.st_mode) && реальный путь(к,бафф))
Измените код на это:
если (реальный путь(к,бафф))