Context switch per second (Linux) 1.3млн это много или мало?

Question

[asmelnik]

Есть сервер, снимаю с него статистику нагрузки.
По CPU, RAM, IOPS-ам -- есть запас "прочности"
CPU - 80-85% загрузки т.е. еще 10-15% гипотетически догрузить можно. (на синтетической нагрузке все ядра на полчаса уложить в 100% можно)
RAM - 120-150Гб свободной из 384Г установленной
IOPS - дисковая подсистема вообще мало нагружена
график "Context switch per second" в zabbix-е упирается "полкой" в 1.3млн.
Если ту же самую нагрузку распределить по 2-м серверам, то нет проблем с обработкой и суммарно "Context switch per second" с 2-х серверов получаю примерно 1.45-1.5млн.
Т.е. не смотря на запас примерно 15% производительности по CPU скорее всего упираюсь именно в "Context switch per second"
Поиск по проблеме ничего вразумительного не дал.
Какими параметрами ядра это может регламентироваться -- найти не удалось.
Где может быть потенциально узкое место, не позволяющее нагрузить в 100% CPU?

реальность 1.
nginx с сжатием gzip по максимуму для отдающихся текстовых файлов грузит CPU в "полку" на 100% и обслуживает некоторое количество подключений и выдает отказы в обслуживании

реальность 2.
nginx c gzip с минимальным сжатием (уровень 3) для тех же файлов гузит CPU только на 80-85% и обслуживает большее количество подключений, чем с максимальным сжатием, но есть отказы в обслуживании

реальность 3
nginx c gzip с минимальным сжатием (уровень 3) для тех же файлов с распределением нагрузки по 2-м серверам без отказов в обслуживании обслуживает реальную нагрузку на 5-10% большую, чем в "реальности 2" (больше просто пользователи реально не создают) .

Вопрос: что мешает в "реальность 2" обслужить эти 5-10%? явно не CPU/RAM/IOPS
единственное обнаруженное, что отличает по набору снятых метрик в "реальность 2" и "реальность 3" -- Context switch per second 1.3млн

Comments

[Everything_is_bad]

Так наверно надо разбираться с софтом что делает эту нагрузку?

[res2001]

Что же означает параметр "Context switch per second"?
Если это количество переключений задач в секунду планировщиком ОС, то он не адекватно высок. Разве что у вас 1300 ядер в проце.

[asmelnik]

res2001, Я понимаю, что он высок.
Вопрос -- что мешает ему подрасти еще немножко :)

[jcmvbkbc]

что мешает ему подрасти еще немножко :)

asmelnik, не факт, что ему нужно расти. Один из сценариев приводящих к большому числу переключений -- слишком маленький буфер между программами обрабатывающими один поток данных. Нужно смотреть, какие именно процессы дают вклад в этот показатель.

[jcmvbkbc]

откуда берется этот "потолок"

я ничего не знаю про nginx, но логика подсказывает, что если есть отказы в обслуживании, то каким-то образом он сам должен решить, что вот конкретно этому клиенту нужно отказать. Может это среднее время обработки запроса, может это cpu load average, может это связано с невозможностью открыть новый файл или запустить новый процесс, может что-то ещё. Я бы смотрел в это место сначала.

[edo1h]

asmelnik, с чего вы взяли, что сервер может больше? При включенном ht виртуальных ядер вдвое больше, чем физических, то есть загрузка процессора в 50% по мониторингу может уже полностью задействовать все его ресурсы, и дальнейшее увеличение нагрузки не приведёт к росту производительности.
Второй момент: вы видите усреднённую нагрузку в 80%, но это совершенно не исключает того, что продолжительное время процессор может быть загружен на 100%.
Кстати, что именно вы понимаете под нагрузкой в 80%? Можно конкретные цифры user, system, iowait,…?

И да, context switch — это достаточно тяжелая операция, на вашем месте я бы в первую очередь искал не как обработать больше context switch в секунду, а как наоборот снизить количество переключений контекста при текущей нагрузке.
Первое, что приходит в голову — излишнее число прерываний от сетевой карты.
Кстати, на какой нагрузке (в мегабайтах в секунду и в rps) у вас случается затык?

С чего бы начал я (помимо сбора ответов на озвученные выше вопросы):
1. mitigations=off, это снизит стоимость переключения контекста;
2. «Зажал» бы частоту процессора и отключил всякие c3, энергосберегающие опции плохо совместимы с короткими запросами.
processor.max_cstate=1 intel_idle.max_cstate=1 к параметрам ядра, плюс поставить pstate-frequency и запустить pstate-frequency -p max (если помогло, то в systemd включаем pstate-frequency@max)
3. Посмотрел на статистику прерываний в /proc/interrupts, при необходимости подтюнил бы сетевую с помощью ethtool

[asmelnik]

jcmvbkbc,

если есть отказы в обслуживании, то каким-то образом он сам должен решить, что вот конкретно этому клиенту нужно отказать.

Не факт. Если запрос до него вообще не дошел то он и не откажет, но и не обслужит, т.к. для nginx-а этого запроса по-просту не было.

[asmelnik]

edo1h,
Спасибо.
В следующий пик нагрузки буду проверять что и какой эффект может дать.

[jcmvbkbc]

Если запрос до него вообще не дошел

asmelnik, то узкое место в сети. Я не вижу, как ещё он может не дойти. Но ты говоришь, что с сетью есть запас.

[jcmvbkbc]

И да, context switch — это достаточно тяжелая операция…Первое, что приходит в голову — излишнее число прерываний от сетевой карты.

edo1h, смена контекста и прерывания связаны друг с другом в единственном случае -- когда драйвер устройства вызывающего прерывание хочет обрабатывать его в отдельном потоке. Для сетевых карт это скорее исключение чем правило. В остальных случаях прямой связи нет, можно получить миллион прерываний и ни одного переключения контекста.

[asmelnik]

Итак, предварительные результаты:
Увы (или ура?), но нагрузка не поднялась до пороговых значений, но кое-что есть.
Статистика показала, что при 20Гб канале занято до 3Гб, НО при этом 600К PPS как на вход, так и на выход.
Т.к. сервер не транзитный, то по факту нагрузка на сетевой стек 1.2млн пакетов.
в то же время нагрузка на nginx 200.000 подключений/сек
Мониторинг сети показал, что на пиках нагрузки скорее всего есть дропы в сетевом стеке ОС.
Т.к. очереди на адаптерах уже выставлены на максимум, небольшой тюнинг sysctl был выполнен, результаты опять же будут ясны при пиковых нагрузках.
Посмотрим будут ли расти счетчики.

edo1h,

1. mitigations=off, это снизит стоимость переключения контекста;
2. «Зажал» бы частоту процессора и отключил всякие c3, энергосберегающие опции плохо совместимы с короткими запросами. processor.max_cstate=1 intel_idle.max_cstate=1 к параметрам ядра

Субъективно на нагрузках ниже пороговых отличий нет, все графики ведут себя одинаково что с
1. что с 2. что 1+2.

из просто применимых инструментов:
tuned при профиле network-latency дал снижение "Interrupts per second" примерно на 10-12%.

Итого
пока оставил mitigations=off и подожду увеличения нагрузки.

[asmelnik]

jcmvbkbc,

узкое место в сети. Я не вижу, как ещё он может не дойти. Но ты говоришь, что с сетью есть запас.

Сетевое оборудование на L2-L3 все отдаст с большим запасом, до адаптера сервера пакеты точно долетают (что в моем понимании и есть собственно "сеть"; и лично мое мнение, что сетевой стек ОС - не есть проблема транспортной сети)
Где-то в дебрях ОС может и потеряться.
Начиная от очереди адаптера и дальше.
Возможно мы с вами об одном и том же, но в разных терминах :)

Answer 1

[asmelnik]

Спасибо всем неравнодушным и ответившим по существу проблемы.

Всякое решение плодит новые проблемы.(один из законов Мэрфологии)

Похоже время ответить на вопрос и закрыть тему

Context switch per second (Linux) 1.3млн это много или мало?
Если коротко — это для конфигурации
E5-2699v4 — 2шт
RAM 378Gb
Довольно много, но не предел.
Достигнутый максимум 1.5 млн.
Достигнут был при следующих условиях:
Совет от edo1h,

1. mitigations=off, это снизит стоимость переключения контекста;
2. «Зажал» бы частоту процессора и отключил всякие c3, энергосберегающие опции плохо совместимы с короткими запросами.
processor.max_cstate=1 intel_idle.max_cstate=1 к параметрам ядра, плюс поставить pstate-frequency и запустить pstate-frequency -p max (если помогло, то в systemd включаем pstate-frequency@max)

Дал направление копания, итоговый набор параметров ядра совпал с советом выше.
mitigations=off intel_idle.max_cstate=1 processor.max_cstate=1

Замечания jcmvbkbc, res2001, Everything_is_bad натолкнули на мысль разделить задачи сервера на более-менее автономные блоки и исследовать как по отдельности, так и взаимосвязи между ними.

Результат оказался для меня неожиданным (об этом в п.3)

1. Сеть
Тюнинг сетевой подсистемы дал снижение количества прерываний/сек (не слишком значительное, но это положительным образом сказалось на результатах).
Убрал bonding интерфейсов (выигрыш на уровне погрешностей измерения, но иногда(хоть и крайне редко) при работающем bonding наблюдались всплески interrupts, которые полностью отсутствовали при выключенном bonding в течении 4-х дней)
Максимальный размер буферов на адаптере.
Воспользовался tuned + корректировка параметров sysctl.
Профиль network-latency субъективно подошел лучше всего.

2. Работа nginx-а
Тут дало положительный эффект запуск 2-х независимых серверов на 2-х dummy интерфейсах. Не могу пока предположить с чем связано.

3. Неожиданный эффект — т.к. логирование таки необходимо, довольно много сливалось в rsyslog по unix.socket (сеть не вариант, нагрузка выше заметно)
Вот отказ от заливки логов nginx-а в rsyslog снял 75-76% (С 1.3млн до 0.3млн на пиках нагрузки) количества «Context switch per second».
Буквально «на коленке» на python написал заменитель, вся задача — сообщение из unix.socket записать в файл в нужном формате.

Итог, сервер выполняет те же функций:
«Context switch per second» -- снизился на 50% от исходного.
Нагрузка на CPU — снижение примерно на 25-30%.
При тех нагрузках, при которых ранее появлялись отказы, отказов нет.

Comments

[res2001]

Отличная работа!

[edo1h]

а почему логирование было через unix socket, а не в файл? запись в лог-файл nginx агрегирует, там всё хорошо.

и какого плана заменитель написали?

[asmelnik]

edo1h,
Логи ротируются очень часто, каждые 30 секунд.
При прямой записи логов с nginx когда происходит ротация nginx на несколько секунд даёт повышение нагрузки на ЦПУ. При частой ротации это сильно повышает среднюю нагрузку.
А логов набегает как выяснилось до 20гб в минуту.

[asmelnik]

edo1h,

и какого плана заменитель написали?

Пока самого тупого.
Блок данных из сокета принимает как строку, что-то обрезается/меняется/добавляется. И запись в файл.

Answer 2

[Saboteur]

Нужно понимать как работает многозадачность и распределение процессорного времени по ядрам.
В Линукс довольно сложно посчитать реальную занятость процессора.
В сам свитчинг ничего упираться не может, точнее нет каких-то специальных лимитов. Это обычная процессорная занятость, относящаяся наверное к system cpu usage, но это неточно. Чем быстрее процессор, тем быстрее он может выполнять свитчинг и тем больше свитчингов в секунду может быть выполнено, это просто выполнение инструкций процессора вне рамках процессов, а внутри ядра системы, точнее process scheduler.

Но проблема в том, как именно распределяется процессорное время. process scheduler в ядре линукса выделяет слайсы примерно по 10-15 милисекунд на процесс, потом переключает на другой. Для процессов, которые что-то активно вычисляют (например архивация), после анализа деятельности может быть выделен более длинный слайс или несколько подряд, то есть уменьшается свитчинг. При этом оценка времени, которая нужна на сам свитчинг - она довольно сложная, ведь для подсчета количество потраченного cpu нужно потратить cpu, и эти 10-15% может на самом деле не существовать.

Если парралельных процессов очень много и все хотят что-то делать (чекнуть load average), то машина просто не успевает обработать их все, и тратить на переключение приличное количество ресурса, вместо того чтобы непосредственно выполнять код ваших программ.
Таким образом какого-то определенного лимита на context switching нет, это просто еще одна метрика, которая может подсказать что слишком много одновременно запускаете, можно попробовать оптимизировать.

Ну или просто не хватает CPU, а система ошибочно показывает свободные ресурсы, которых на самом деле нет.

Линукс на самом деле не так уж детально может посчитать точное количество ресурсов. Там выполняется все очень просто - на входе в контекст засекается timestamp, на выходе из контекста засекается таймстамп, и потраченное время дописывается в метаданные процесса (для каждого ядра, если процесс многопоточный). Исторические значения не записываются, в метаданных процесса есть только вот это - сколько всего cpu usage с момента старта процесса.
Если запустить какой-нить top, он будет каждые 1-2 секунды бегать по списку процессов, сравнивать этот параметр и показывать результат загруженности за последние 1-2 секунды, но вот уточнить процесс занял свои 25% cpu плавно в течение секунды, или он занимал 100% cpu первую четверть секунды или третью - вы уже не сможете.

Ну и само ядро считает свои внутренние потоки так же само.
И только активность самого process scheduler (то есть cpu затраченное на анализ и переключения процессов) не может быть красиво подсчитана.

p.s. я не разработчик линукс, поэтому это мое IMHO основанное на наблюдениях и обзорных статьях о работе современного планировщика, если будут гуру которые меня поправят или подтвердят сказанное - будет круто.

Answer 3

[ky0]

Цель "нагрузить 100% процессора" - странная. Замеры нужно проводить не синтетических попугаев, а прикладных метрик - и уже потом пытаться искать узкие места и что-то менять.

Comments

[asmelnik]

Цель не нагрузить 100%, цель понять почему не грузится больше.
Если смотреть на CPU/RAM/IOPS то сервер может обработать бОльшую нагрузку.
Вопрос какое "узкое место" не дает это сделать на реальной нагрузке, но дает - на синтетике.
Чем регламентирована величина именно 1.3млн??

[Everything_is_bad]

asmelnik,

Чем регламентирована величина именно 1.3млн??

спецификой софта, который столько делает, вот с ним и нужно разбираться

[asmelnik]

Everything_is_bad,
реальность 1.
nginx с сжатием gzip по максимуму для отдающихся текстовых файлов грузит CPU в "полку" на 100% и обслуживает некоторое количество подключений и выдает отказы в обслуживании

реальность 2.
nginx c gzip с минимальным сжатием (уровень 3) для тех же файлов гузит CPU только на 80-85% и обслуживает большее количество подключений, чем с максимальным сжатием, но есть отказы в обслуживании

реальность 3
nginx c gzip с минимальным сжатием (уровень 3) для тех же файлов с распределением нагрузки по 2-м серверам без отказов в обслуживании обслуживает реальную нагрузку на 5-10% большую, чем в "реальности 2" (больше просто пользователи реально не создают) .

Вопрос: что мешает в "реальность 2" обслужить эти 5-10%? явно не CPU/RAM/IOPS
единственное обнаруженное, что отличает по набору снятых метрик в "реальность 2" и "реальность 3" -- Context switch per second 1.3млн

[Everything_is_bad]

asmelnik, а теперь это всё надо вынести в сам вопрос.

[Everything_is_bad]

asmelnik, ну и сразу, может эти текстовые файлы изначально сжать, чтобы не делать каждый раз одинаковую работу?

[asmelnik]

Everything_is_bad,

а теперь это всё надо вынести в сам вопрос.

Разумно, добавил :)

ну и сразу, может эти текстовые файлы изначально сжать, чтобы не делать каждый раз одинаковую работу?

Не вариант, не вдаваясь -- потребуется переделка во многих местах от меня не зависящих.

Да и исходной проблемы это не решит.

[Everything_is_bad]

asmelnik, в сеть не уперлись?

[asmelnik]

Everything_is_bad,
Однозначно нет.
Это первое, что проверено было :)

[SunTechnik]

Сколько и каких процессоров стоит ? Это физическая машина или виртуалка ?
Интернет говорит, что CS должен быть меньше 7500 из расчета на 1 CPU (это не абсолютный максимум, некая рекомендация по мониторингу системы).
СS происходит при переключении задач или при прерываниии. Причем само переключение так же занимает время. Поэтому, при большом количестве CS, система просто не успевает делать что-то полезное. Она только и занимается переключением контекста...

[asmelnik]

Машина физическая.
Ее единственная задача описана выше.
CPU: Xeon E5-2699v4 -- 2 шт.
Но это по-прежнему не дает ответа на вопрос откуда берется этот "потолок".
Разве что при переключении контекста наблюдается простой ЦПУ?

[res2001]

asmelnik, Учитывая слишком высокое значение сейчас, я бы стремился на вашем месте его уменьшить, а не увеличить. Такое впечатление, что нагрузку на проц создают именно переключения контекста, а не реальная работа.
Если прерывания учитываются в этой цифре, то возможно у вас их слишком много. Попробуйте получить статистику по прерываниям другими способами и определить какие именно срабатывают наиболее часто. Возможно найдете способ повлиять на их количество, а это в свою очередь разгрузит процессор и позволит вашим рабочим процессам выполнять больше работы при меньшем значении CS.

[hint000]

res2001,

Учитывая слишком высокое значение сейчас, я бы стремился на вашем месте его уменьшить, а не увеличить.

Кстати, в интернетах рекомендуют для этого задействовать CPU affinity.

asmelnik, и ещё мне видится изъян в этом утверждении;

Вопрос: что мешает в "реальность 2" обслужить эти 5-10%? явно не CPU/RAM/IOPS

насчёт IOPS - это штука эфемерная. При линейном чтении большого файла IOPS маленький, а фактически диск плотно нагружен. И наоборот, относительно высокий IOPS ещё не гарантирует, что в него упирается общая производительность. Так что я бы пристальнее присмотрелся к работе дисков, но не зацикливаясь на показателе IOPS. Сколько прочитано\записано байт в секунду - это тоже показатель. Доля процессорного времени в состоянии IOWait - это тоже показатель.

[SunTechnik]

asmelnik,
Покажите вывод: vmstat 5 5

Просто vmstat различает 4 разных способа утилизации CPU. И непонятно, о каком идет речь, когда говорят, что CPU занят на 85%

us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

На Вашей системе, даже если считать HyperThreading, получается больше 14000 CS на процессор.

[asmelnik]

hint000,

spoiler

Сколько прочитано\записано байт в секунду - это тоже показатель.

Нет там достойной нагрузки на диск, все нужные файлы в tmpfs в RAM сразу лежат. Логи или по сети льются или отключены.
Максимальный iowait за неделю 0.007%, средний практически 0.
Запись/чтение с ДИСКА в пределах 2-3Мб/сек и то в пиках на 1-2 секунды.

[asmelnik]

SunTechnik,
Сейчас нагрузка снизилась "естественным образом"
В начале недели она как правило побольше, в конце поменьше и сейчас до нужных для проверки идей не дотягивает.

Просто vmstat различает 4 разных способа утилизации CPU. И непонятно, о каком идет речь, когда говорят, что CPU занят на 85%

idle составляет 15-20%, ядро 5.10

[asmelnik]

res2001,

Попробуйте получить статистику по прерываниям другими способами и определить какие именно срабатывают наиболее часто. Возможно найдете способ повлиять на их количество, а это в свою очередь разгрузит процессор и позволит вашим рабочим процессам выполнять больше работы при меньшем значении CS.

Спасибо, Покопаю на эту тему.