Настройка параметров системы, компляции и запуска в MySQL

Мы начинаем с вопросов системного уровня, поскольку некоторые из них требуют решения на самых ранних этапах. В других случаях может оказаться достаточно только беглого просмотра этого материала, поскольку значительного выигрыша в оптимизации он не обеспечивает. Однако всегда хорошо иметь представление о том, какую пользу можно получить при изменении параметров на этом уровне.

Используемая по умолчанию операционная система имеет действительно большое значение! Чтобы получить максимальную выгоду от применения многопроцессорных компьютеров, следует применять Solaris (так как под этой ОС потоки работают в самом деле хорошо) или Linux (поскольку ядро 2.2 обеспечивает действительно хорошую поддержку SMP). Однако на 32-разрядных компьютерах Linux по умолчанию имеет ограничение размера файлов в 2 Гб. Будем надеяться, что это ограничение в скором времени будет снято при выпуске новых файловых систем (XFS/Reiserfs). Но если вам действительно не обойтись без файлов с размерами более чем 2 Гб на 32-разрядном ПК с Linux-intel, то следует использовать патч LFS для файловой системы ext2.

На многих платформах MySQL еще не находился в промышленной эксплуатации, поэтому мы рекомендуем прежде, чем остановить свой выбор на какой-либо платформе, сначала ее протестировать.

Другие советы:

• Если оперативной памяти достаточно, то можно было бы удалить все внешние запоминающие устройства. Существуют операционные системы, которые при некоторых обстоятельствах будут использовать внешние запоминающие устройства даже при наличии свободной памяти.

• Чтобы избежать внешнего блокирования, используйте опцию MySQL --skip-external-locking. Следует учитывать, что пока работает только один сервер, это не будет оказывать большого влияния на функциональные возможности MySQL. Только не забудьте остановить сервер (или блокировать соответствующие части) перед запуском myisamchk. В некоторых системах такое переключение обязательно, поскольку внешнее блокирование не работает в любом случае.

  Опция --skip-external-locking включена по умолчанию при компилировании с потоками MIT-pthreads, поскольку функция flock() не полностью поддерживается потоками MIT-pthreads на всех платформах. Для Linux также подразумевается, что блокирование файлов пока еще ненадежно.

  Нельзя использовать --skip-external-locking только в одном случае - при запуске нескольких серверов (не клиентов) MySQL на одних и тех же данных, или при запуске myisamchk на таблице без предварительного сбрасывания на диск и блокирования демона mysqld для сервера, содержащего эти таблицы. Можно также применять команду LOCK TABLES/UNLOCK TABLES даже при использовании --skip-external-locking.

Настройка параметров сервера

Размеры буферов, используемые по умолчанию сервером mysqld, можно узнать с помощью следующей команды:

shell> mysqld --help

Эта команда выдает список всех опций mysqld и конфигурируемых переменных. Вывод включает в себя величины по умолчанию и выглядит примерно следующим образом:

Possible variables for option --set-variable (-O) are:
back_log                 current value: 5
bdb_cache_size           current value: 1048540
binlog_cache_size        current value: 32768
connect_timeout          current value: 5
delayed_insert_timeout   current value: 300
delayed_insert_limit     current value: 100
delayed_queue_size       current value: 1000
flush_time               current value: 0
interactive_timeout      current value: 28800
join_buffer_size         current value: 131072
key_buffer_size          current value: 1048540
lower_case_table_names   current value: 0
long_query_time          current value: 10
max_allowed_packet       current value: 1048576
max_binlog_cache_size    current value: 4294967295
max_connections          current value: 100
max_connect_errors       current value: 10
max_delayed_threads      current value: 20
max_heap_table_size      current value: 16777216
max_join_size            current value: 4294967295
max_sort_length          current value: 1024
max_tmp_tables           current value: 32
max_write_lock_count     current value: 4294967295
myisam_sort_buffer_size  current value: 8388608
net_buffer_length        current value: 16384
net_retry_count          current value: 10
net_read_timeout         current value: 30
net_write_timeout        current value: 60
read_buffer_size         current value: 131072
record_rnd_buffer_size   current value: 131072
slow_launch_time         current value: 2
sort_buffer              current value: 2097116
table_cache              current value: 64
thread_concurrency       current value: 10
tmp_table_size           current value: 1048576
thread_stack             current value: 131072
wait_timeout             current value: 28800

Не забывайте, что --set-variable не используется в MySQL 4.0. Просто указывайте --var=option.

Если сервер mysqld в настоящее время работает, то для того, чтобы увидеть, какие величины реально используются для переменных, необходимо выполнить следующую команду:

shell> mysqladmin variables

Полное описание всех переменных можно найти в разделе SHOW VARIABLES этого руководства.

Некоторые статистические данные по работающему серверу можно также просмотреть с помощью команды SHOW STATUS.

В MySQL используются алгоритмы, масштабируемые в широких пределах, так что обычно можно работать с очень небольшой памятью. Однако если выделить для MySQL больше памяти, то и производительность, как правило, будет выше.

При настройке сервера MySQL наиболее важными из используемых являются две переменные key_buffer_size и table_cache. Но прежде чем пытаться изменить ту или иную переменную, вначале следует убедиться, что вы обладаете необходимыми для этого правами.

Если имеется большая память (>=256 Mb) и много таблиц, то для обеспечения максимальной производительности путем регулирования количества клиентов следует использовать что-нибудь вроде этого:

shell> safe_mysqld -O key_buffer=64M -O table_cache=256 \
                   -O sort_buffer=4M -O read_buffer_size=1M &

Если память составляет только 128 Mb и количество таблиц невелико, но тем не менее, выполняется много сортировок, то можно использовать что-нибудь вроде:

shell> safe_mysqld -O key_buffer=16M -O sort_buffer=1M

При малой памяти и большом количестве соединений следует использовать что-нибудь вроде следующего:

shell> safe_mysqld -O key_buffer=512k -O sort_buffer=100k \
                   -O read_buffer_size=100k &

или даже:

shell> safe_mysqld -O key_buffer=512k -O sort_buffer=16k \
                   -O table_cache=32 -O read_buffer_size=8k \
                   -O net_buffer_length=1K &

Если выполняются операции GROUP BY или ORDER BY на файлах, которые намного больше, чем доступная память, то следует увеличить величину record_rnd_buffer для ускорения чтения строк после выполнения сортировки.

После установки MySQL каталог support-files будет содержать несколько различных файлов-примеров my.cnf, а именно: my-huge.cnf, my-large.cnf, my-medium.cnf и my-small.cnf, которые можно использовать как основу для оптимизации вашей системы.

Если демон mysqld не отконфигурирован для использования очень малой памяти для каждого соединения, то в условиях очень большого количества соединений могут возникнуть проблемы с подкачкой виртуальной памяти. При наличии достаточной памяти для всех соединений mysqld, конечно, будет функционировать лучше.

Следует учитывать, что при изменении какой-либо опции для mysqld это изменение действительно только для данного экземпляра сервера.

Чтобы увидеть воздействие изменения параметра, нужно выполнить что-нибудь вроде этого:

shell> mysqld -O key_buffer=32m --help

Следует удостовериться, что опция --help расположена последней; в противном случае влияние любой опции, следующей после нее в командной строке, в данном выводе отражено не будет.

Как компиляция и линкование влияет на скорость MySQL

Большинство из последующих тестов выполняются под Linux с использованием тестов производительности MySQL, но они должны дать некоторое представление и для других операционных систем и рабочих нагрузок.

Самый быстрый исполняемый код получается при линковании с помощью -static.

Под Linux наиболее быстрый код можно получить при компилировании pgcc с опицей -O3. Чтобы скомпилировать sql_yacc.cc с этой опцией, требуется около 200 Mb памяти, поскольку компилятор gcc/pgcc забирает много памяти. При конфигурировании MySQL следует также установить CXX=gcc - чтобы не линковалась библиотека libstdc++ (в этом нет необходимости). Следует учитывать, что при некоторых версиях компилятора pgcc результирующий код будет работать только на настоящих процессорах Pentium, даже если использовать возможность компилятора выдавать результирующий код, работоспособный на всех процессорах типа x586 (например AMD).

Используя просто лучший компилятор и/или лучшую опцию компилятора, можно получить для приложения увеличение скорости на 10-30%. Это особенно важно, если вы компилируете сервер SQL самостоятельно!

Мы протестировали такие компиляторы как Cygnus CodeFusion и Fujitsu, но ни тот, ни другой не были достаточно свободны от ошибок, чтобы можно было скомпилировать MySQL с оптимизирующими параметрами.

При компилировании MySQL необходимо включать только наборы кодировок, которые вы собираетесь использовать (опция --with-charset=xxx). Стандартная поставка MySQL скомпилирована с поддержкой всех кодировок.

Ниже приводится обзор некоторых действий, которые мы предпринимали для ускорения работы:

• При использовании pgcc и компиляции всего кода с -O6 сервер mysqld на 1% быстрее, чем при gcc 2.95.2.

• При динамическом связывании (без опции -static) результирующий исполняемый файл сервера будет на 13% медленнее работать под управлением Linux. Обратите внимание: вы спокойно можете использовать динамическую библиотеку MySQL. Это касается только сервера и актуально только там, где нужна высокая производительность.

• При сокращении двоичного кода mysqld с помощью strip libexec/mysqld можно получить прирост скорости результирующего двоичного кода до 4%.

• При соединении с использованием протокола TCP/IP, а не сокетов Unix работа будет на 7,5% медленнее на том же самом компьютере (при подключении к localhost MySQL по умолчанию будет использовать сокеты).

• При соединении с использованием протокола TCP/IP с другим компьютером по сети Ethernet с пропускной способностью 100Мбит/сек скорость будет на 8-11% ниже.

• При запуске наших тестов производительности с использованием безопасных соединений (все данные зашифрованы с поддержкой протокола SSL) скорость была на 55% ниже.

• Если код компилируется с параметром --with-debug=full, то для большинства запросов потери в производительности будут составлять до 20%, но некоторые запросы могут выполняться значительно дольше (тесты производительности MySQL работают на 35% медленнее). При использовании опции --with-debug теряется только 15% производительности. При запуске mysqld, откомпилированного с --with-debug=full и --skip-safemalloc, результат должен почти таким же, как и при компиляции с --with-debug.

• На компьютере Sun UltraSPARC-IIe, Forte 5.0 дает на 4% более быстрый код чем gcc 3.2

• На компьютере Sun UltraSPARC-IIe, Forte 5.0 дает на 4% более быстрый код в 32-разрядном режиме чем в 64-разрядном.

• Компилирование посредством gcc 2.95.2 для UltraSPARC с опцией -mcpu=v8 -Wa,-xarch=v8plusa дает прирост производительности на 4%.

• Под операционной системой Solaris 2.5.1 потоки MIT-pthreads на 8-12% медленнее, чем собственные потоки Solaris для единичного процессора. При возрастании нагрузки на процессоры разница должна получиться больше.

• Запуск с --log-bin делает mysqld на 1% медленнее.

• Компилирование под Linux-x86 с использованием gcc без указателей фреймов -fomit-frame-pointer или -fomit-frame-pointer -ffixed-ebp делает mysqld на 1-4% быстрее.

Поставка MySQL под Linux, которую предоставляет MySQL AB, обычно компилировалась с pgcc, но мы должны были вернуться к обычному компилятору gcc из-за ошибок в pgcc, которая могут генерировать код, не исполняемый на AMD. Пока эти ошибки не будут устранены, мы будем продолжать использовать gcc, однако если ваш компьютер не относится к типу AMD, то можно получить более быстрый двоичный код, компилируя его с pgcc. Стандартный двоичный код MySQL для Linux слинкован статически, чтобы сделать его более быстрым и более переносимым.