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

MySQL innodb имеет множество процессов, зависающих в состоянии «обновления» раз в минуту.

Описание проблемы

У меня довольно большая установка MySQL. Есть как минимум 3 отдельных сервера, на которых работает механизм хранения innoDB. Каждую минуту, в одно и то же время каждую минуту, в течение примерно 3-4 секунд каждая из моих машин innodb внезапно перестает работать хорошо.

Когда я делаю SHOW PROCESSLIST на каждом сервере в обычное время я вижу около 10-15 подключений, которые работают как обычно:

+--------+------------------+--------------------------+------+---------+------+-------+------------------+
| Id     | User             | Host                     | db   | Command | Time | State | Info             |
+--------+------------------+--------------------------+------+---------+------+-------+------------------+
|  23457 | root             | localhost                | NULL | Query   |    0 | NULL  | show processlist | 
| 180042 | **********       | web2.***.com:49867       | ***  | Sleep   |    1 |       | NULL             | 
| 180129 | **********       | web1.***.com:54302       | ***  | Sleep   |    0 |       | NULL             | 
| 180155 | **********       | web2.***.com:50225       | ***  | Sleep   |    0 |       | NULL             | 
| 180163 | **********       | web1.***.com:54425       | ***  | Sleep   |    0 |       | NULL             | 
| 180172 | **********       | web1.***.com:54507       | ***  | Sleep   |    0 |       | NULL             | 
| 180181 | **********       | web4.***.com:34893       | ***  | Sleep   |    0 |       | NULL             | 
+--------+------------+--------------------------+------+---------+------+-------+------------------------+

Затем внезапно, почти точно синхронно на каждой машине, в одно и то же время каждую минуту (что означает: 47 секунд после минуты каждую минуту на каждой машине), процессы накапливаются, зависая в состоянии «обновления»:

| 192938 |  **********       | web3.***.com:44248              | ***  | Query   |    3 | update | INSERT INTO user_stats (***_uid, data) VALUES (101670151,"{\"inbox\":{\"new\":12,\"spam_check\":1289 | 
| 192939 |  **********       | web4.***.com:50264              | ***  | Query   |    3 | update | INSERT INTO user_stats (***_uid, data) VALUES (17103785,"{\"inbox\":{\"new\":1,\"spam_check\":0,\"di | 
| 192940 |  **********       | web3.***.com:44258              | ***  | Query   |    3 | update | INSERT INTO user_stats (***_uid, data) VALUES (2245293,"{\"inbox\":{\"new\":14,\"spam_check\":128933 | 
| 192941 |  **********       | web3.***.com:44268              | ***  | Query   |    3 | update | INSERT INTO user_stats (***_uid, data) VALUES (105330063,"{\"inbox\":{\"new\":4,\"spam_check\":0,\"d | 
... 100-200 more just like this...
| 192941 |  **********       | web3.***.com:44268              | ***  | Query   |    3 | update | INSERT INTO user_stats (***_uid, data) VALUES (105330063,"{\"inbox\":{\"new\":4,\"spam_check\":0,\"d | 

При более внимательном рассмотрении кажется, что в этот момент используется высокая загрузка ЦП (хотя я полагаю, что высокая загрузка ЦП может быть вызвана высоким дисковым вводом-выводом), потому что, когда он находится посреди этого, я запускаю что-то простое, например SELECT NOW(), даже это займет около 4 секунд.

Вот что я знаю:

  1. Это не мошеннический неоптимизированный запрос. Бывает на разных машинах, которые запускают не только разные запросы, но и разные таблицы.
  2. Это происходит только на машинах, которые делают запись в таблицы innoDB. Этого не происходит на машинах, которые только читают innoDB, или машинах, которые пишут или читают только из MyISAM.

Вопросы

Есть ли процесс, который запускается каждую минуту на innoDB и требует много ресурсов ЦП или дискового ввода-вывода? Это нормально? Я знаю, что это может быть миллион разных вещей, но я ищу известные проблемы или решения. Могу ли я предоставить дополнительную информацию для решения этой проблемы?

Дополнительная информация

ОПЕРАЦИОННЫЕ СИСТЕМЫ:

uname -a
Linux db04.****.com 2.6.18-194.17.4.el5 #1 SMP Wed Oct 20 13:03:08 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

Файловая система:

/dev/sda4     ext3   785711096  80539996 665259216  11% /data

Конфигурация рейда:

/opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -aALL


Adapter 0 -- Virtual Drive Information:
Virtual Disk: 0 (target id: 0)
Name:Virtual Disk 0
RAID Level: Primary-1, Secondary-3, RAID Level Qualifier-0
Size:856704MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:2
Span Depth:3
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default

Версия MySQL

mysql> select version();
+---------------------------+
| version()                 |
+---------------------------+
| 5.0.80-enterprise-gpl-log | 
+---------------------------+
1 row in set (0.01 sec)

Вы уверены, что задание cron не запускается каждую минуту?

Какова ваша ценность innodb_flush_method?

Поскольку у вас есть RAID-контроллер с кэшем записи с поддержкой BBU (и данными / журналами, не хранящимися в SAN), рекомендуемая настройка: O_DIRECT

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

HTH

Изменить: каково ваше значение для innodb_buffer_pool_size?