Утечка Fedora 33 OpenVPN DNF с «systemd -разрешена»

Для большинства серверов RHEL7 RedHat предлагает увеличить sched_min_granularity_nsдо 10 мс и sched_wakeup_granularity_nsдо 15 мс.(Источник . Технически эта ссылка говорит о 10 мкс, что было бы в 1000 раз меньше. Это ошибка ).

Мы можем попытаться понять это предположение более подробно.

Увеличение графика _мин. _детализация _нс

В современных ядрах Linux кванты времени процессора выделяются задачам с помощью CFS, полностью справедливого планировщика. CFS можно настроить с помощью нескольких настроек sysctl.

• kernel.sched_min_granularity_ns
• kernel.sched_latency_ns
• kernel.sched_wakeup_granularity_ns

Вы можете установить sysctl временно до следующей перезагрузки или навсегда в файле конфигурации, который применяется при каждой загрузке. Чтобы узнать, как применять этот тип настройки,найдите «sysctl» или прочитайте краткое введение здесь .

sched_min_granularity_nsявляется наиболее заметным параметром. В исходном запланированном -дизайне -CFS.txt это было описано как единственная «настраиваемая» настройка, «для настройки планировщика с« рабочего стола »(с низкими задержками )на« server' (хорошая пакетная обработка )рабочих нагрузок».

Другими словами, мы можем изменить этот параметр, чтобы уменьшить накладные расходы на переключение контекста -и, следовательно, повысить пропускную способность за счет скорости отклика («задержки» ).

Я думаю, что эта настройка CFS имитирует настройку времени предыдущей сборки -, CONFIG _HZ . В первой версии кода CFS значение по умолчанию составляло 1 мс, что эквивалентно 1000 Гц для использования на рабочем столе. Другими поддерживаемыми значениями CONFIG _HZ были 250 Гц (по умолчанию )и 100 Гц для "серверной" стороны. 100 Гц также было полезно при запуске Linux на очень медленных процессорах, это была одна из причин, указанных , когда CONFIG _HZ впервые был добавлен в качестве параметра сборки на X86 .

Кажется разумным попробовать изменить это значение на 10 мс (, т. е. 100 Гц ), и измерить результаты. Помните, что sysctl измеряются в нс . 1 мс = 1 000 000 нс.

Мы можем видеть, что эта старая -настройка «сервера» все еще была очень актуальна в 2011 году для пропускной способности в некоторых высоконагруженных -тестах производительности :https://events.static.linuxfound.org/slides/2011/linuxcon/lcna2011_rajan.pdf

.

И, возможно, еще пара настроек

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

sched_wakeup_granularity_nsкасается «упреждающего -пробуждения -». т.е.он контролирует, когда задача, разбуженная событием, может немедленно -прервать выполнение текущего процесса. Слайды 2011 года также показали разницу в производительности для этого параметра.

См. также «Отключение WAKEUP _PREEMPT» в этом справочнике IBM за 2010 год , в котором говорится, что «для некоторых рабочих нагрузок» эта функция по умолчанию -«может стоить несколько процентов загрузки ЦП». ".

У SUSE Linux есть документация, в которой предлагается установить для этого параметра значение, превышающее половину sched_latency_ns, чтобы эффективно отключить пробуждение -до предварительного -срабатывания, и тогда «задачи с коротким рабочим циклом не смогут эффективно конкурировать с процессором-свиньем». ".

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

https://www.suse.com/documentation/opensuse121/book_tuning/data/sec_tuning_taskscheduler_cfs.html

Если вы поэкспериментируете с любой из этих переменных планирования, я думаю, вы также должны знать, что все три масштабируются (умножаются )на 1+log _2 числа процессоров. Это масштабирование можно отключить с помощью kernel.sched_tunable_scaling. Я мог что-то упустить, но это кажется удивительным, например. если вы рассматриваете скорость отклика серверов, предоставляющих интерактивные приложения и работающих с полной или почти полной нагрузкой, и как эта скорость будет меняться в зависимости от количества процессоров на сервер.

Предложение, если ваша рабочая нагрузка имеет большое количество потоков/процессов

Я также наткнулся на предложение 2013 года относительно нескольких других параметров, которые могут значительно увеличить пропускную способность, если ваша рабочая нагрузка включает большое количество потоков. (Или, возможно, более точно, он -увеличивает пропускную способность, которую они получили на ядрах до -CFS ).

• " Две необходимые настройки ядра " -обсуждение в списке рассылки PostgreSQL.
• " Увеличьте стоимость миграции kernel.sched __в профиле виртуального -хоста " -Ошибка Red Hat 969491.

ИгнорироватьCONFIG_HZ

Я думаю, вам не нужно беспокоиться о том, что установлено CONFIG_HZ. Насколько я понимаю, это не относится к текущим ядрам, если у вас есть разумное оборудование таймера. См. также коммит 8f4d37ec073c, «sched :высокий -тик вытеснения разрешения» , найденный в этом комментарии в ветке об изменении:https://lwn.net/Articles/549754/.

(Если вы посмотрите на коммит, я бы не стал беспокоиться, что SCHED_HRTICKзависит от X86. Похоже, что это требование было снято в более позднем коммите ).