Процессы ядра, периодически съедая ЦП во время высокой загрузки
Я выполняю производственный веб-сервер с 24 ядрами, в которых работой является и ЦП и интенсивно использующий средства ввода-вывода, но главным образом ЦП. Мои сценарии задерживают выполнение, когда общая загрузка ЦП составляет ~85% или выше для хранения загрузки управляемой. Таким образом ЦП никогда не находится в условиях большего стресса, чем мои сценарии знают, что он может обработать.
Теперь, мой сервер подвергается макс. плановой мощности в блоках времени 3 часа длиной за один раз. Большая часть времени, работа идет гладко, но в середине этого периода, часто системная нагрузка ЦП увеличивается существенно. Это происходит из-за "events/x" процессов ядра, "migration/x", и "ksoftirqd/x", где "x" является числом ЦП для того процесса. Я считал, что это указывает, что ядро борется с задачами с очередями, который происходит при подавляющей системной нагрузке. Однако моя загрузка ЦП, которая является основным узким местом, сознательно сохранена на уровне ~85% для предотвращения этого вида проблемы, как я упомянул. Это использование ядра ЦП существенно замедляет производство и только продлевает задачи с очередями. Странная часть - то, что приблизительно после 30 минут системная нагрузка исчезнет, с процессами ядра, уменьшающимися назад, чтобы обнулить использование ЦП, только начать hogging ЦП снова позже. В течение этого всего времени объем работы, питаемый к центральным процессорам, не изменился и обычно обрабатывается очень хорошо. Однако, когда эти процессы ядра умирают, это полностью уничтожает производство.
Вот является вывод "вершины-u корнем" во время одного из этих событий. Пользовательское использование ЦП составляет 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 PR NI VIRT RES SHR S %CPU %MEM ВРЕМЯ + КОМАНДА 51 базируется миграция/12 0 0 0 0 S 11.1 0.0 436:03.06 RT 100 корней 20 0 0 0 0 событий/1 S 9.5 0.0 49:19.45 114 корней 20 0 0 0 0 событий/15 S 5.9 0.0 48:14.75 3 корневых миграции/0 0 0 0 0 S 4.3 0.0 517:58.05 RT 112 корней 20 0 0 0 0 событий/13 S 3.6 0.0 42:00.54 27 корневых миграций/6 0 0 0 0 S 2.3 0.0 200:59.58 RT 8 149 корней 20 0 165 м 7732 3 928 корней S 2.3 0.0 0:00.07 exim 15 миграция/3 0 0 0 0 S 2.0 0.0 450:05.62 RT 39 корневых миграций/9 0 0 0 0 S 2.0 0.0 178:08.17 RT 113 корней 20 0 0 0 0 событий/14 S 1.6 0.0 44:00.04 178 корней 20 корней 0 0 0 0 R 1.6 0.0 53:27.57 kacpid 63 миграция/15 0 0 0 0 S 1.3 0.0 439:11.96 RT 81 корень 20 корней 0 0 0 0 S 1.0 0.0 17:14.83 ksoftirqd/19 104 20 0 0 0 0 событий/5 S 1.0 0.0 44:58.55 115 корней 20 0 0 0 0 событий/16 S 1.0 0.0 47:18.46 9 корней 20 корней 0 0 0 0 S 0.7 0.0 13:56.20 ksoftirqd/1 25 20 корней 0 0 0 0 S 0.7 0.0 12:46.52 ksoftirqd/5 57 20 корней 0 0 0 0 S 0.7 0.0 11:12.62 ksoftirqd/13 75 миграция/18 0 0 0 0 S 0.7 0.0 181:00.24 RT 118 корней 20 0 0 0 0 событий/19 S 0.7 0.0 30:13.06 10 497 корней 20 0 77964 6244 4 096 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 решил, что процессы необходимо перенести на другой ЦП, а процесс миграции съедает время ЦП.
Вы можете попробовать привязать процессы к определенным ЦП или попробовать другие планировщики с вашим ядром. Может быть, какой-то другой планировщик не очень хочет переносить процессы на другие Процессоры.
Я отслеживал проблемы с процессом миграции ядра, о которых сообщалось здесь . Похоже, что это касается ядра Linux до 3.6.11. По ссылке показан аналогичный симптом, когда процесс миграции занимает много времени ЦП. Если возможно, вы можете обновить ядро, чтобы проверить, сохраняется ли проблема.