Я запускаю производственный веб-сервер с 24 ядрами, работа на котором интенсивна как ЦП, так и ввода-вывода, но в основном ЦП. Мои скрипты откладывают выполнение, когда общая загрузка ЦП составляет ~ 85% или выше, чтобы поддерживать управляемость нагрузки. Таким образом, ЦП никогда не подвергается большей нагрузке, чем мои сценарии могут выдержать.
Теперь мой сервер работает с максимальной производительностью во временных блоках до 3 часов за раз. Большую часть времени работа идет гладко, но в середине этого периода часто загрузка системы ЦП резко возрастает. Это связано с процессами ядра «events / x», «migration / x» и «ksoftirqd / x», где «x» - это номер процессора для этого процесса. Я читал, что это указывает на то, что ядро борется с задачами в очереди, что происходит при чрезмерной загрузке системы. Однако, как я уже упоминал, загрузка моего процессора, которая является основным узким местом, намеренно поддерживается на уровне ~ 85%, чтобы избежать такого рода проблем. Такое использование ЦП ядром резко замедляет производство и только продлевает выполнение задач в очереди. Странно то, что примерно через 30 минут нагрузка на систему исчезнет, а процессы ядра уменьшатся до нулевого уровня использования ЦП, а позже снова начнут загружать ЦП. В течение всего этого времени объем работы, передаваемой на ЦП, не изменился и обычно выполняется нормально. Однако, когда эти процессы ядра запускаются, это полностью убивает производство.
Вот результат команды «top -u root» во время одного из этих событий. Использование ЦП пользователем составляет 49%, так как загрузка системы составляет 40%. Обычно это должно быть пользовательское ~ 85%, системное ~ 5%. Однако iowait отсутствует, а средняя загрузка системы составляет 22 (из 24 ядер), что нормально.
top - 13:10:49 up 44 days, 20:29, 1 user, load average: 22.87, 22.73, 21.36
Tasks: 622 total, 24 running, 585 sleeping, 0 stopped, 13 zombie
Cpu(s): 49.4%us, 40.3%sy, 0.0%ni, 10.1%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 32728060k total, 31045092k used, 1682968k free, 353768k buffers
Swap: 4194300k total, 243136k used, 3951164k free, 19117436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
51 root RT 0 0 0 0 S 11.1 0.0 436:03.06 migration/12
100 root 20 0 0 0 0 S 9.5 0.0 49:19.45 events/1
114 root 20 0 0 0 0 S 5.9 0.0 48:14.75 events/15
3 root RT 0 0 0 0 S 4.3 0.0 517:58.05 migration/0
112 root 20 0 0 0 0 S 3.6 0.0 42:00.54 events/13
27 root RT 0 0 0 0 S 2.3 0.0 200:59.58 migration/6
8149 root 20 0 165m 7732 3928 S 2.3 0.0 0:00.07 exim
15 root RT 0 0 0 0 S 2.0 0.0 450:05.62 migration/3
39 root RT 0 0 0 0 S 2.0 0.0 178:08.17 migration/9
113 root 20 0 0 0 0 S 1.6 0.0 44:00.04 events/14
178 root 20 0 0 0 0 R 1.6 0.0 53:27.57 kacpid
63 root RT 0 0 0 0 S 1.3 0.0 439:11.96 migration/15
81 root 20 0 0 0 0 S 1.0 0.0 17:14.83 ksoftirqd/19
104 root 20 0 0 0 0 S 1.0 0.0 44:58.55 events/5
115 root 20 0 0 0 0 S 1.0 0.0 47:18.46 events/16
9 root 20 0 0 0 0 S 0.7 0.0 13:56.20 ksoftirqd/1
25 root 20 0 0 0 0 S 0.7 0.0 12:46.52 ksoftirqd/5
57 root 20 0 0 0 0 S 0.7 0.0 11:12.62 ksoftirqd/13
75 root RT 0 0 0 0 S 0.7 0.0 181:00.24 migration/18
118 root 20 0 0 0 0 S 0.7 0.0 30:13.06 events/19
10497 root 20 0 77964 6244 4096 S 0.7 0.0 17:40.25 httpd
Есть ли какие-либо возможные объяснения поведения этих процессов, когда загрузка ЦП строго регулируется, чтобы можно было управлять? Память не является проблемой, поскольку использование буферов / кеша никогда не превышает 30% емкости системы. При поиске в Интернете все винят чрезмерную загрузку системы, но поведение моего сервера не предполагает, что используемые ресурсы должны вызывать эту блокировку.
Мы ценим любые предложения.
РЕДАКТИРОВАТЬ: Я опубликовал то, что кажется решением в разделе ответов.
Похоже, что процессы ядра могли красть процессорное время во время передачи в / из свопа. Параметры кэша сервера каким-то образом были сброшены без моего ведома, установив swappiness на 60. Судя по выходным данным «sar -W», зависания, похоже, совпадали с периодами высокой нагрузки, в течение которых pswpin / s и pswpout / s были большими ( более 2,00 или около того, иногда даже до 15,00). После установки swappiness на 1 я не сталкивался с такими же зависаниями от процессов ядра, и sar -W всегда показывает почти нулевые значения. Подводя итог, можно сказать, что агрессивная подкачка при высокой нагрузке и передаче большого объема памяти приводила к зависанию системы во времена большого и быстро меняющегося спроса на ресурсы.
Я отслеживал проблемы с сообщением о процессе миграции ядра Вот. Похоже, что это касается ядра Linux до 3.6.11. По ссылке показан аналогичный симптом, когда процесс миграции занимает много процессорного времени. Если возможно, вы можете обновить ядро, чтобы увидеть, сохраняется ли проблема.
migration это процесс ядра, который обрабатывает перемещение процессов с одного процессора на другой.
Итак, по какой-то причине ваш планировщик Linux решает, что процессы необходимо перенести на другой ЦП, и процесс миграции съедает время ЦП.
Вы можете попробовать привязать процессы к конкретным процессорам или попробовать разные планировщики с вашим ядром. Возможно, какой-то другой планировщик не так сильно хочет переносить процессы на другие процессоры.