У меня очень большая нагрузка на машину, и я не знаю, что за это отвечает и как это выяснить.
На машине работает сервер приложений jboss и mysql. Вот топ от пользователя в пиковое время:
top - 16:23:01 up 101 days, 6:50, 1 user, load average: 23.42, 21.53, 24.73
Tasks: 9 total, 1 running, 8 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.2%us, 1.6%sy, 0.0%ni, 80.4%id, 0.1%wa, 0.1%hi, 0.7%si, 0.0%st
Mem: 16440784k total, 16263720k used, 177064k free, 151916k buffers
Swap: 16780872k total, 30428k used, 16750444k free, 8963648k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27344 b 40 0 16.0g 6.5g 14m S 169 41.7 1184:09 java
6047 b 40 0 11484 1232 1228 S 0 0.0 0:00.01 mysqld_safe
6192 b 40 0 604m 182m 4696 S 0 1.1 93:30.40 mysqld
7948 b 40 0 84036 1968 1176 S 0 0.0 0:00.07 sshd
7949 b 40 0 14004 2900 1608 S 0 0.0 0:00.03 bash
7975 b 40 0 8604 1044 840 S 0 0.0 0:00.44 top
Использование процессора Java-процессом нормальное. Пики появляются только тогда, когда я развернул определенное веб-приложение. Мог ли полученный сетевой трафик увеличить нагрузку так, что я не вижу его в топе?
Так что средняя нагрузка на самом деле достаточно сложная, но я понимаю, что в основном это то, что ждет в очереди выполнения. Так что я предполагаю, что у вас могут быть вещи, ожидающие ввода-вывода. Вот хороший украденный фрагмент чтобы увидеть, что ждет:
ps -eo stat,pid,user,command | egrep "^STAT|^D|^R"
D : Uninterruptible sleep (usually IO)
R : Running or runnable (on run queue)
Как уже отмечалось, iostat также хорошо работает, чтобы узнать, вероятно ли это диск.
Сложно сказать по одному снимку сверху. Требуется дополнительная информация.
Если предположить, что использование ЦП нормальное, похоже, что у вас есть запасной ЦП, похоже, что у вас не закончилась память, поэтому следующее, на что я посмотрю, будет ввод-вывод.
Всегда ли значение IOWait (% wa) низкое или этот снимок не является типичным с точки зрения IOWait?
vmstat 1 покажет нам вашу память, т. е. со временем.
iostat -x 1 также покажет нам, на какой диск / разделы выполняется запись.
На хостах, где веб-приложения и базы данных размещаются в одном и том же блоке, я не раз видел, что журналы для веб-приложения и каталога данных баз данных часто оказываются на одном диске / разделе / файловой системе, что может вызвать раздор. Ряд дистрибутивов, которые я видел, помещают данные mysql в / var / lib / mysql и веб-приложения tomcat в / var / lib / tomcat / webapps и, конечно же, журналы в / var / log / tomcat.
Т.е. ваше веб-приложение принимает много обращений и пытается записать эти обращения в раздел, но в то же время он пытается читать данные для БД из того же раздела.
Я обычно считаю использование времени ожидания и времени обслуживания наиболее полезной статистикой от iostat, если я подозреваю наличие разногласий.
Быстрый и грязный способ узнать - просто переместить местоположение журнала tomcat на другой раздел / диск, если это возможно.
обычный ответ в таких случаях - начните собирать статистику с Мунин или кактусы, потому что теперь ты изрядно ослеп. вещи для сюжета:
В нашем случае это было вызвано тем, что базовый сервер Ubuntu запустил do-release-upgrade, но не был перезагружен после этого. Глядя на дампы виртуальных машин, оказалось, что что-то странное с библиотеками ОС сделала сама виртуальная машина, а не программное обеспечение поверх нее. Перезагрузка ОС устранила проблему.