У меня форум с большим количеством посетителей, иногда нагрузка увеличивается до 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
Вот несколько инструментов для определения активности диска:
iotopvmstat 1iostat 1lsofstrace -e trace=open <application>strace -e trace=open -p <pid>В ps auxf вы также увидите, какие процессы находятся в неинтерпретируемом спящем режиме диска (D), потому что они ждут ввода-вывода.
В отдельные дни нагрузка увеличивается до 40 без увеличения количества посетителей.
Вы также можете создать резервную копию и посмотреть, не выходит ли из строя жесткий диск. Жесткий диск обычно начинает замедляться до того, как выйдет из строя. Это также могло объяснить высокую нагрузку.
Вывод сверху предполагает, что СУБД испытывает большую часть ожиданий ввода-вывода, поэтому проблемы настройки базы данных - очевидный кандидат для исследования.
Ожидание ввода-вывода на сервере базы данных - особенно при пиках нагрузки - указывает на то, что ваша СУБД может быть либо привязана к диску (т.е. вам нужна более быстрая дисковая подсистема), либо может иметь проблемы с настройкой. Вероятно, вам также следует изучить профилирование своего сервера базы данных, то есть получить информацию о том, что он делает и какие запросы требуют времени.
Некоторые отправные пункты для диагностики проблем настройки базы данных: -
Найдите запросы, которые занимают больше всего времени, и просмотрите планы запросов. Посмотрите, есть ли у кого-то странные планы запросов, например сканирование таблицы, где их быть не должно. Может быть, в базу данных нужно добавить индекс.
Длительное время ожидания ресурсов может означать, что некоторый пул ключевых ресурсов необходимо расширить.
Длительное время ожидания ввода-вывода может означать, что вам нужна более быстрая дисковая подсистема.
Ваши журналы и тома данных находятся на разных дисках? Журналы базы данных содержат много небольших последовательных записей (по сути, они ведут себя как кольцевой буфер). Если у вас есть загруженная рабочая нагрузка с произвольным доступом, использующая одни и те же диски с вашими журналами, это непропорционально повлияет на пропускную способность журналирования. Чтобы транзакция базы данных зафиксировала, записи журнала должны быть записаны на диск, так что это создаст узкое место для всей системы.
Обратите внимание, что некоторые механизмы хранения MySQL не используют журналы, поэтому в вашем случае это может не быть проблемой.
Сноска: системы массового обслуживания
Системы массового обслуживания (статистическая модель пропускной способности) становятся гиперболически медленнее, когда система приближается к насыщению. Для высокоуровневого приближения система с 50% -ным насыщением имеет среднюю длину очереди 2. Система с 90-процентным насыщением имеет длину очереди 10, а система с 99-процентным насыщением имеет длину очереди 100.
Таким образом, в системе, близкой к насыщению, небольшие изменения нагрузки могут привести к большим изменениям времени ожидания, в этом случае проявляющимся как время, затраченное на ожидание ввода-вывода. Если емкость ввода-вывода вашей дисковой подсистемы почти заполнена, небольшие изменения нагрузки могут привести к значительным изменениям времени отклика.
Бегать iotop, или atop -dD, чтобы увидеть, какие процессы делают io. Использовать strace если вам нужно поближе.
На обоих экранах похоже, что виноват mysqld.
Вам нужно увидеть, что делает этот демон ... какие запросы выполняются.
В отдельные дни нагрузка увеличивается до 40 без увеличения количества посетителей.
То, что делают пользователи, может быть столь же значительным, как и их количество. Такие операции, как поиск по форуму, будут более сложными, чем просто загрузка и просмотр отдельных цепочек или списков цепочек.
Также: вы работаете на выделенном сервере или на VPS? Если ваша служба не находится на выделенном сервере, то действия приложений, запущенных на том же хосте, будут иметь эффект, поскольку виртуальные машины, с которыми ваша виртуальная машина совместно использует хост, будут соревноваться за долю ресурса ввода-вывода.
Как отмечали другие, такие инструменты, как iotop поможет вам глубже понять, какие задачи находятся в ожидании ответов ввода-вывода и к каким файлам они обращаются в данный момент.
Как говорит Флип, похоже, проблема в том, что делает mysql.
Около половины вашей физической памяти в настоящее время используется для кэширования ввода-вывода - программное обеспечение форума обычно генерирует множество быстрых запросов, возвращающих небольшое количество строк с сильно искаженными горячими областями диска - так что есть что-то определенно неприятное, если система тратит столько времени в ожидании.
Я вижу такое использование ЦП / диска только при выполнении запросов, которые обновляют миллионы строк.
Высокая средняя нагрузка является прямым следствием ввода-вывода.
Включите ведение журнала mysql, чтобы увидеть, есть ли там плохой код / изменение индексов поможет. Может помочь анализ ваших таблиц (но, вероятно, не сильно).
С.
После проверки всех iotop и других инструментов, также проверьте очередь "dmesg", вы можете увидеть корень проблемы для этой проблемы. В моем случае это было «CIFS VFS: сервер file.core.windows.net не ответил в течение 120 секунд. Повторное подключение ...»
Я получил это очень высоко wa Использование ЦП на сервере. Оказалось, что не хватает доступной памяти и kswapd0 процесс вызывал такой высокий wa Использование процессора.
На сервере не было памяти подкачки, поэтому я создал ее (1 ГБ), выполнив следующие команды (сервер Ubuntu):
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
В wa Загрузка ЦП сейчас очень низкая или в большинстве случаев составляет 0%.