Добрый день.
Сегодня у меня упал сервер и хотел бы оставить заметку для себя на будущее.
Тогда я решил воспользоваться программой nmon - которая разработана для анализа и мониторинга данных производительности системы.
$ nmon
увидев приглашение:
Странно это все подумал я, но сразу обнаружил откуда такое количество процессов чтения и записи. Походу при перезагрузке сервера произошла ошибка и информация на дисках раз синхронизировалась. И теперь идет процесс синхронизации.
В Linux есть две переменные, которые задают минимальную и максимальную скорость синхронизации рейд массива. Для того, что бы их посмотреть можно воспользоваться такими командами:
Просмотреть минимальную скорость:
$ sysctl dev.raid.speed_limit_min
или
$ cat /proc/sys/dev/raid/speed_limit_min
Просмотреть максимальную скорость:
$ sysctl dev.raid.speed_limit_max
или
$ cat /proc/sys/dev/raid/speed_limit_max
или
$ sysctl -w dev.raid.speed_limit_min=50000
Увеличили минимальную скорость до 50 мб/c.
$ echo "300000" > /proc/sys/dev/raid/speed_limit_max
или
$ sysctl -w dev.raid.speed_limit_max=300000
Увеличив максимальную скорость до 300 мб/c.
И с этим я закончил в ожидании когда синхронизируется рейд. Так как у меня занято всего 32Гб дискового пространства, то это должно занять максимум пару часов.
Дальше я решил разобраться в чем же проблема зависания сервера.
$ cat /var/log/message | less
И ищем записи предшествующие:
Jan 28 23:17:24 serv kernel: [ 0.000000] Initializing cgroup subsys cpuset
Jan 28 23:17:24 serv kernel: [ 0.000000] Initializing cgroup subsys cpu
Jan 28 23:13:43 serv kernel: [2245853.425738] Total swap = 2096056kB
Jan 28 23:13:43 serv kernel: [2245853.453090] 515968 pages RAM
Jan 28 23:13:43 serv kernel: [2245853.453105] 8992 pages reserved
Jan 28 23:13:43 serv kernel: [2245853.453117] 66634 pages shared
Jan 28 23:13:43 serv kernel: [2245853.453130] 476069 pages non-shared
Jan 28 23:14:06 serv kernel: [2245874.237441] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
А точнее даже в строках выделенные красным цветом.
Я сразу обратился в гугл за сведениями о oom-killer и вот что я нашел.
OOM Killer - это способ ядра решить проблему, когда памяти недостаточно. Известно, что виртуальной памяти может быть бесконечно много (в пределах адресации), а вот физической - вполне конечное число. Иногда процессы системы съедают ее всю. и системе надо кого-то убить, чтобы продолжить работу. Текущая версия OOM Killer в Linux стремится выбрать наименее важный процесс. Он выбирает среди всех процессов, кроме init и kernel threads, самый негодный (badness).
Теперь ясно, что проблема, скорее всего, заключается в прожорливых php и mysql.
Так как опыта у меня мало, я сразу решил пойти в настройки и тюнить php и mysql.
А это уже тема для отдельной заметки.
Полезные ссылки:
[1] HowTo: Speed UP Linux Software Raid Building And Re-syncing
[2] Увеличение скорости перестроения программного RAID в Linux
[3] Про память: OOM Killer
Сегодня у меня упал сервер и хотел бы оставить заметку для себя на будущее.
Ехал домой и тут мне пришла смска с Zabbix-сервера, о недоступности одного из моих серверов. Приехав домой и проверив, что сервер не доступен. Первым делом я решил его перезагрузить (сильно не пинайте, я только начинающий), через панель управления серверами hetznera.
После перезагрузки удостоверился, что сервер работает в штатном режиме.
Но когда я вызвал atop, я увидел, что DISK busy 100% и тогда я немного запаниковал, в чем же может быть причина.
Первым делом в интерактивном режиме atop я нажал клавишу d, который строит процессы по использованию диска и на удивление для себя не обнаружил ни одного процесса, который бы забивал диск.
$ nmon
увидев приглашение:
Нажимаем на кнопку d .
И увидел не утешительную информацию о Disk I/O:
Как-то сразу я решил проверить, а все ли хорошо у меня с рейдом, так как hetzner при заказе сервера сразу устанавливает все на рейдах и вот что я увидел:
В Linux есть две переменные, которые задают минимальную и максимальную скорость синхронизации рейд массива. Для того, что бы их посмотреть можно воспользоваться такими командами:
Просмотреть минимальную скорость:
$ sysctl dev.raid.speed_limit_min
или
$ cat /proc/sys/dev/raid/speed_limit_min
Просмотреть максимальную скорость:
$ sysctl dev.raid.speed_limit_max
или
$ cat /proc/sys/dev/raid/speed_limit_max
Для увеличения скорости перестроения программного RAID я решил увеличить минимальную и максимальную скорость для этого дела:
$ echo "50000" > /proc/sys/dev/raid/speed_limit_minили
$ sysctl -w dev.raid.speed_limit_min=50000
Увеличили минимальную скорость до 50 мб/c.
$ echo "300000" > /proc/sys/dev/raid/speed_limit_max
или
$ sysctl -w dev.raid.speed_limit_max=300000
Увеличив максимальную скорость до 300 мб/c.
И с этим я закончил в ожидании когда синхронизируется рейд. Так как у меня занято всего 32Гб дискового пространства, то это должно занять максимум пару часов.
Дальше я решил разобраться в чем же проблема зависания сервера.
$ cat /var/log/message | less
И ищем записи предшествующие:
Jan 28 23:17:24 serv kernel: [ 0.000000] Initializing cgroup subsys cpuset
Jan 28 23:17:24 serv kernel: [ 0.000000] Initializing cgroup subsys cpu
Тут я увидел очень много непонятного мне текста. Но самое важное (как мне кажется) находится примерно в таких строках:
Jan 28 23:13:35 serv kernel: [2245843.840156] Free swap = 0kB
Jan 28 23:13:35 serv kernel: [2245843.840164] Total swap = 2096056kB
Jan 28 23:13:35 serv kernel: [2245843.865152] 515968 pages RAM
Jan 28 23:13:35 serv kernel: [2245843.865166] 8992 pages reserved
Jan 28 23:13:35 serv kernel: [2245843.865179] 68362 pages shared
Jan 28 23:13:35 serv kernel: [2245843.865192] 474470 pages non-shared
Jan 28 23:13:43 serv kernel: [2245853.424972] php invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
...
Jan 28 23:13:43 serv kernel: [2245853.425729] Free swap = 0kBJan 28 23:13:43 serv kernel: [2245853.425738] Total swap = 2096056kB
Jan 28 23:13:43 serv kernel: [2245853.453090] 515968 pages RAM
Jan 28 23:13:43 serv kernel: [2245853.453105] 8992 pages reserved
Jan 28 23:13:43 serv kernel: [2245853.453117] 66634 pages shared
Jan 28 23:13:43 serv kernel: [2245853.453130] 476069 pages non-shared
Jan 28 23:14:06 serv kernel: [2245874.237441] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
А точнее даже в строках выделенные красным цветом.
Я сразу обратился в гугл за сведениями о oom-killer и вот что я нашел.
OOM Killer - это способ ядра решить проблему, когда памяти недостаточно. Известно, что виртуальной памяти может быть бесконечно много (в пределах адресации), а вот физической - вполне конечное число. Иногда процессы системы съедают ее всю. и системе надо кого-то убить, чтобы продолжить работу. Текущая версия OOM Killer в Linux стремится выбрать наименее важный процесс. Он выбирает среди всех процессов, кроме init и kernel threads, самый негодный (badness).
Алгоритм расчета уровня негодности процесса (итоговое значение будет измеряться в очках негодности (badness ponts)):
- Берется размер виртуальной памяти процесса (
total_vm). Это базовые очки негодности (mm/oom_kill.c:69). - К текущим очкам прибавляется
total_vm/2 + 1для всех порожденных процессов (mm/oom_kill.c:85). - Текущие очки делятся на
int_sqrt(cpu_time), где cpu_time — это user + system время процесса сдвинутое вправо наSHIFT_HZ + 3, т.е. дляHZ=1000приблизительно будет равен значениюint_sqrt((utime+stime)/10). причем если результат деления и последующего округления будет 0 — то очки не изменяются (mm/oom_kill.c:100). - Текущие очки делятся на
int_sqrt(int_sqrt(run_time/1024)), где run_time — время прошедшое с момента запуска процесса. Если результат 0 — то очки не изменяются (mm/oom_kill.c:100). - Очки умножаются на 2, если
niceпроцесса больше 0 (mm/oom_kill.c:118). - Если процесс имеет привилегию CAP_SYS_ADMIN или CAP_SYS_RESOURCE или (e)uid в нуле, то текущие очки делятся на 4 (mm/oom_kill.c:125).
- Если процесс имеет привилегию CAP_SYS_RAWIO, то текущие очки делятся на 4 (mm/oom_kill.c:133).
- Если память процесса, для которого мы считаем очки негодности, пересекается с памятью процесса, для которого в момент выделения новой памяти произошла ошибка
out of memory, тогда очки делятся на 8 (для ядер старше 2.6.28,mm/oom_kill.c:142). - Набранные очки умножаются на
2oom_adj, где oom_adj — берется из/proc/$PID/oom_adj, он может принимать значения от -17 до 15. В случае значения -17 процесс не будет тронут OOM Killer (mm/oom_kill.c:150).
И самый негодный (с самыми большими очками) процесс будет убит.
Вся эта информация нагло украдена отсюда [3], за что и спасибо ему. Там есть немного дополнительной информации и пояснений.
Вся эта информация нагло украдена отсюда [3], за что и спасибо ему. Там есть немного дополнительной информации и пояснений.
Теперь ясно, что проблема, скорее всего, заключается в прожорливых php и mysql.
Так как опыта у меня мало, я сразу решил пойти в настройки и тюнить php и mysql.
А это уже тема для отдельной заметки.
Полезные ссылки:
[1] HowTo: Speed UP Linux Software Raid Building And Re-syncing
[2] Увеличение скорости перестроения программного RAID в Linux
[3] Про память: OOM Killer
Комментариев нет:
Отправить комментарий