wa (в ожидании ввода / вывода) из верхней команды велика

У меня есть форум с большим количеством посетителей, в некоторые дни нагрузка увеличивается до 40 без увеличения числа посетителей. Как видно из приведенного ниже вывода, время ожидания велико (57%). как мне найти причину для этого?
Серверное программное обеспечение - Apache, MySQL и PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

,

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Вот несколько инструментов для поиска активности диска:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

Кроме того, ps auxfвы увидите, какие процессы находятся в неинтерпретируемом режиме сна ( D), поскольку они ожидают ввода-вывода.

В некоторые дни нагрузка увеличивается до 40 без увеличения числа висторов.

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

Вывод top предполагает, что СУБД испытывает большую часть ожиданий ввода-вывода, поэтому проблемы с настройкой базы данных являются очевидным кандидатом для изучения.

Ожидание ввода-вывода на сервере базы данных - особенно при скачках нагрузки - является признаком того, что ваша СУБД может быть либо привязана к диску (т. Е. Вам нужна более быстрая дисковая подсистема), либо возникнет проблема с настройкой. Вы, вероятно, также должны изучить профилирование вашего сервера базы данных - то есть получить информацию о том, что он делает и какие запросы занимают время.

Некоторые начальные точки для диагностики проблем с настройкой базы данных: -

• Найдите запросы, которые занимают больше всего времени, и посмотрите на планы запросов. Посмотрите, есть ли у каких-либо странных планов запросов, таких как сканирование таблицы, где это не должно быть. Возможно, к базе данных нужен индекс.

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

• Длительное время ожидания ввода-вывода может означать, что вам нужна более быстрая дисковая подсистема.

• Ваши журналы и тома данных находятся на разных дисках? Журналы базы данных имеют много небольших последовательных записей (по сути, они ведут себя как кольцевой буфер). Если у вас занятая рабочая нагрузка произвольного доступа, использующая те же диски, что и ваши журналы, это непропорционально повлияет на пропускную способность ведения журнала. Для фиксации транзакции базы данных записи в журнале должны быть записаны на диск, поэтому это создаст узкое место во всей системе.
  
  Обратите внимание, что некоторые механизмы хранения MySQL не используют журналы, поэтому это может не быть проблемой в вашем случае.

Сноска: Системы массового обслуживания

Системы массового обслуживания (статистическая модель пропускной способности) становятся гиперболически медленнее, когда система приближается к насыщению. В приближении высокого уровня система, которая на 50% насыщена, имеет среднюю длину очереди 2. Система, которая на 90% насыщена, имеет длину очереди 10, а система, которая на 99% насыщена, имеет длину очереди 100.

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

Запустите iotopили atop -dD, чтобы увидеть, какие процессы делают io. Используйте, straceесли вам нужно присмотреться.

На обоих экранах уверен, что "mysqld" отвечает.

Вы должны увидеть, что делает этот демон ... какие запросы выполняются.

В некоторые дни нагрузка увеличивается до 40 без увеличения числа висторов.

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

Кроме того: вы работаете на выделенном сервере или VPS? Если ваша служба не находится на выделенном сервере, то действия приложений, работающих на одном и том же хосте, будут иметь эффект, поскольку виртуальные машины, с которыми ваша виртуальная машина совместно использует хост, будут конкурировать за долю ресурса ввода-вывода.

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

Как говорит Флип, похоже, проблема в том, что делает MySQL.

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

Я только когда-либо вижу такое использование процессора / диска при выполнении запросов, которые обновляют миллионы строк.

Высокая средняя нагрузка является прямым следствием ввода-вывода.

Поднимите свой журнал MySQL, чтобы увидеть, есть ли там плохой код / ​​изменение индексов поможет. Анализ ваших таблиц может помочь (но, вероятно, не очень).

C.