Высокая нагрузка без объяснения причин
У меня очень высокая нагрузка на мою машину, и я не знаю, что за это отвечает и как это выяснить.
На машине работает jboss appserver и 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 является нормальным. Пики отображаются только при развертывании определенного веб-приложения. Может ли результирующий сетевой трафик увеличить нагрузку таким образом, чтобы я не видел его сверху?
4 ответа
Таким образом, средняя загрузка на самом деле довольно сложная, но я понимаю, что это в основном то, что ожидает в очереди выполнения. Так что я думаю, что у вас могут быть вещи, ожидающие на IO. Вот хороший украденный фрагмент, чтобы увидеть, что ждет:
ps -eo stat,pid,user,command | egrep "^STAT|^D|^R"
D : Uninterruptible sleep (usually IO)
R : Running or runnable (on run queue)
Как указано, iostat хорошо работает, чтобы увидеть, вероятно ли это диск.
Трудно сказать с одного верхнего снимка. Требуется больше информации.
Предполагая, что, как вы говорите, загрузка ЦП нормальная, похоже, что у вас есть запасной ЦП, похоже, что у вас нет нехватки памяти, поэтому следующее, на что я бы посмотрел, - это IO.
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, но не перезагрузился после него. Глядя на дампы виртуальных машин, это была сама виртуальная машина, а не программное обеспечение поверх нее, которое делало что-то странное с библиотеками ОС. Перезагрузка ОС исправила проблему.
Обычный ответ в таких случаях - начать собирать статистику с мунином или кактусами, потому что теперь вы довольно слепы. вещи для сюжета:
- io statistics - чтение / запись на диск
- потребление памяти, читает и пишет из свопа
- количество процессов и количество потоков [может ли быть, что java по какой-то причине порождает их тоны в этом конкретном сценарии? ]
- количество открытых сокетов TCP, дескрипторы открытых файлов [возможно...]
- средняя нагрузка
- использование процессора с обычным nice/iowait/user/softirq и т. д.
- для tomcat вы также можете получить [вероятно] неплохую статистику java - размер кучи, размер PermGen/Survivor/Tenured, количество попаданий в секунду