Назад | Перейти на главную страницу

MySQL и высокий jdb2 io / подождите

Я запускаю MySQL 5.5 с таблицами InnoDB. Есть около 200 запросов в секунду. Также есть таблицы с 500 000 и более строк. Но у меня большие проблемы с загрузкой сервера и io / wait, особенно с jdb2.

jdb2 / md2-8 занимает 99% операций ввода-вывода / подождите, см. выходное изображение iotop: Вывод Iotop

Технические характеристики бокса: Xeon 1246 v3, 32 ГБ RAM, 2x 240 Intel SSD RAID 1

Я не знаю, что-то не так в моей конфигурации или проблема связана с RAID. Какие-нибудь советы ?

Мой mysql my.cfg:

innodb_file_per_table   = 1
join_buffer_size    = 1M
open_files_limit    = 10000
myisam_use_mmap     = 1
query_cache_type    = 1
table_open_cache    = 2000
concurrent_insert   = 2
max_connections     = 3000

query_cache_size    = 16M
key_buffer_size     = 16M
read_buffer_size        = 8M
query_cache_limit   = 4M
query_cache_min_res_unit = 1K
tmp_table_size      = 64M
thread_cache_size   = 1500

sort_buffer_size    = 2M
max_heap_table_size     = 64M
innodb_buffer_pool_size = 5000M
read_rnd_buffer_size    = 128M
thread_concurrency      = 8
thread_stack        = 1M
innodb_log_buffer_size  = 2M

Спасибо.

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

Такая высокая загрузка jdb2 при таком малом количестве запросов (200 в секунду) довольно странна, особенно с быстрым SSD. Вы используете карту RAID без кеширования? Это может отключить внутренние кеши вашего SSD, что приведет к ужасной производительности. Если да, вы можете попробовать:

  1. повторно включить частный кеш вашего диска
  2. используйте опцию my.cnf innodb_flush_log_at_trx_commit=0
  3. используйте карту RAID с поддержкой BBU с 512+ МБ защищенной кеш-памяти DRAM

Обратите внимание, что варианты №1 и №2 имеют небольшой, но ненулевой риск потери транзакции в случае потери питания. Безусловно, самый безопасный вариант - третий - купить подходящую карту RAID.

Ваш my.cnf включает 4 строки, которые следует удалить, это

read_buffer_size
read_rnd_buffer_size
join_buffer_size
thread_stack

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

Для более подробного анализа добавьте в OriginalPost следующее:

SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;
SHOW ENGINE INNODB STATUS;

для выполнения до пяти конкретных рекомендаций CFG, по одной в день, monitor.

Следует учитывать две вещи:

1) Есть ли у вас соответствующие индексы для ваших запросов?

2) Можете ли вы добавить RAM на свой сервер?

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

Обращаясь к пункту 2, вы разрешите кэширование большей части вашей базы данных в ОЗУ, что одновременно ускорит запросы и сократит ввод-вывод.