Ядро Linux 6.x: важные нововведения для хостинг-серверов

Правильно определить состояние ядра

Название «Linux 6.x» объединяет множество основных выпусков, а не обозначает единый функциональный уровень. Основной веткой считается та, которую поддерживает Линус Торвальдс: после завершения периода слияния (Merge Window) обычно следуют кандидатские версии (Release Candidates) вплоть до финального основного выпуска. От неё следует отличать ветки «Stable» и «LTS», в которых продолжается поддержка выпущенных ядер с учётом определённых исправлений. Ядра дистрибутивов, в свою очередь, следуют собственным версиям пакетов, обязательствам по поддержке и решениям об интеграции.

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

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

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

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

Четыре направления деятельности в сфере хостинга

Для хостинг-серверов особое значение имеют четыре области эксплуатации: давление в аккумуляторе, конкуренция за ресурсы ЦП, дополнительная изоляция процессов и обслуживание. Речь идет не о том, чтобы активировать как можно больше функций ядра, а о подборе подходящих инструментов для решения конкретной проблемы. Пулы PHP-FPM, базы данных, кэши, пакетные задания и специализированные рабочие процессы предъявляют различные требования, которые невозможно определить, исходя только из версии ядра.

cgroup v2 является междисциплинарной темой, но не является нововведением версии 6.x. Иерархия структурирует ресурсы памяти и ЦП для служб, контейнеров или групп клиентов. Какие контроллеры доступны и активированы в подиерархии, необходимо проверять в соответствующем монтировании cgroup-v2. Поэтому для выделенного веб-сервера требуется иная оценка, чем для хоста контейнеров или виртуальных машин.

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

Давление в памяти и освобождение страниц

Linux часто использует свободную оперативную память в качестве кэша файлов. Поэтому большая загруженность ОЗУ сама по себе не является ошибкой и не свидетельствует о нерациональном использовании памяти: кэшированные страницы файлов можно освободить при необходимости. Для диагностики более важны динамика и последствия нагрузки, например, время отклика, активность файлового обмена, журналы ошибок и прерывания процессов.

Решающим фактором является давление в накопителе Освобождение страниц , какие страницы можно удалить из кэша или, при необходимости, переместить в аут-кэш. Ядро может выполнять эту работу асинхронно посредством kswapd выполнить. Если процессу при запросе на запись в память приходится самостоятельно освобождать страницы, в документации ядра это называется «прямым освобождением»; это может негативно повлиять на выполняемый процесс и, как следствие, на наблюдаемые задержки.

Сигналы тревоги, как правило, возникают в виде комбинации: длительная запись или выгрузка в/из файла подкачки, события OOM, увеличение времени ожидания и ошибки на уровне приложений следует отображать на общей временной шкале. В то же время однократный скачок может быть вызван запланированным пакетным заданием. Даже служба кэша, занимающая значительную часть оперативной памяти, не является автоматически причиной, если её cgroup и остальные процессы сохраняют достаточную работоспособность.

cgroup v2 дополняет глобальную картину границами на уровне сервисов или контейнеров. Контроллер памяти предоставляет счетчики событий; memory.events имеет иерархическую структуру, тогда как memory.events.local отображает только локальные события соответствующей cgroup. Это позволяет определить, связана ли проблема с лимитом собственной службы или с нагрузкой в вышестоящей структуре.

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

Целенаправленная проверка LRU нескольких поколений

Multi-Gen LRU — это альтернативная реализация для Освобождение страниц и описан в рассматриваемой здесь документации по ядру, начиная с Linux 6.1. В условиях нехватки памяти ядро должно решать, какие страницы файлового кэша или анонимной памяти можно освободить. Для этого алгоритм Multi-Gen LRU группирует страницы по поколениям в зависимости от времени доступа и учитывает модели доступа, чтобы снизить вероятность выбора часто используемых страниц для освобождения.

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

Перед каждой оценкой сначала проверь, присутствует ли интерфейс выполнения и доступен ли он для чтения. В актуальной документации по ядру для этого указаны следующие параметры конфигурации: CONFIG_LRU_GEN и CONFIG_LRU_GEN_ENABLED а также путь по адресу /sys/kernel/mm/lru_gen/. Ядро дистрибутива может обратно портировать функциональные версии или настраивать их иным образом; поэтому номер версии сам по себе не является достоверным доказательством.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Вывод сначала лишь подтверждает, что задокументированный интерфейс sysfs существует и доступен для чтения. Для определения состояния активации важно значение бита: 0x0001 является главным переключателем модуля Multi-Gen LRU. Если этот бит отсутствует, файл может отображать отключенный главный переключатель, несмотря на наличие интерфейса; остальные биты относятся к дополнительным компонентам. Даже установленный главный бит не является общим рекомендацией по изменению значения в производственной среде.

Поэтому запись данных в sysfs не является стандартной настройкой. Сначала соберите временные ряды по показателям Reclaim, Swap, задержкам и событиям cgroup; при обоснованном изменении зафиксируйте исходное значение и определите способ возврата к исходному состоянию. Таким образом, можно будет отследить, действительно ли наблюдаемая проблема изменилась или же просто одновременно были изменены несколько регулируемых параметров.

Следует проявлять особую осторожность в случаях, когда ограничения по памяти невелики, а сервисы перегружены. Измененный алгоритм reclaim не устраняет чрезмерно большие пулы PHP-рабочих процессов, несоответствующие кэши баз данных или отсутствие разделения конкурирующих клиентов. Разумная последовательность действий выглядит следующим образом: определить причину и затронутую cgroup, ограничить или распределить нагрузку и только после этого оценить доступную функцию ядра как возможный фактор влияния.

Надежное выявление проблем с памятью

Занятая оперативная память сама по себе не является ошибкой: Linux целенаправленно использует свободную память в качестве кэша файлов. Необходимость принимать меры возникает скорее тогда, когда требования в прямой возврат работают, растёт активность свопа, возникают события OOM или одновременно замедляется обработка запросов. Асинхронное освобождение памяти с помощью kswapd работает в фоновом режиме; прямой реклайм, напротив, происходит в контексте задачи, запрашивающей память, и может задержать её выполнение.

Файл событий memory.events подсчитывает события иерархически, то есть с учётом подчинённых cgroups. Для исключительно локального просмотра используется memory.events.local готово. high означает ограничение и непосредственное восстановление после превышения memory.high, в то время как oom учитывается попытка выделения памяти, которая может завершиться сбоем из-за достижения лимита cgroup. oom_kill В то же время учитываются процессы этой cgroup, которые были завершены каким-либо OOM-киллером.

Начните диагностику с четкого определения: какой сервис или контейнер входит в подозрительную cgroup, когда произошли события и какие сигналы приложения наблюдались одновременно? Затем сравните локальные и иерархические счетчики, системный журнал, историю использования свопа, а также задержки HTTP, время ожидания базы данных или частоту ошибок. В случае возникновения OOM необходимо дополнительно выяснить, указывают ли данные на процесс, связанный с cgroup, или на возможную глобальную нехватку памяти.

Значение memory.max является жестким ограничением cgroup и не является первоочередной стандартной мерой. Более строгое ограничение может защитить клиентов, но также может привести к тому, что приложение раньше окажется в ситуации OOM; более высокое ограничение может усилить вытеснение соседних служб. Поэтому сначала проверьте количество рабочих процессов, размеры кэшей, пиковые нагрузки и структуру cgroup. Затем изменяйте только одну обоснованную настройку, предусмотрев период наблюдения и план возврата к исходным настройкам.

Понимание EEVDF и конкуренции между процессорами

В актуальной официальной документации по ядру указано, что начало перехода на EEVDF Linux 6.6. Алгоритм «Earliest Eligible Virtual Deadline First» изменяет порядок выбора обычных задач, распределяемых по принципу справедливости: при этом учитываются виртуальное время выполнения, отклонение от идеального распределения (Lag) и виртуальные сроки. Благодаря этому задачи, имеющие право на выполнение и самый ранний виртуальный срок, могут первыми получить время процессора.

Важное значение имеет термин „переход“. EEVDF не заменяет выбор класса справедливого планирования (Fair Scheduling) в том смысле, что при этом исчезают все структуры данных, интерфейсы и концепции, исторически обозначавшиеся как CFS. Даже в текущей документации EEVDF по-прежнему сравнивается с CFS. Поэтому для конкретного ядра распределения необходимо проверять его встроенные патчи и версию функционала, а не полагаться исключительно на 6.6 или выше, можно сделать вывод о полностью единообразном поведении.

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

Операционное разделение по-прежнему осуществляется по границам служб и платформ. Весовые коэффициенты ЦП влияют на относительное распределение при конкуренции, тогда как квоты могут ограничивать доступное вычислительное время. Если необходимо надёжно отделить веб-нагрузку, для которой важна низкая задержка, от объёмных пакетных заданий, целесообразно использовать отдельную виртуальную машину или отдельный хост. EEVDF заменяет их Планирование ресурсов не.

Перед запросом cgroup.controllers тебе нужно определить, подключена ли cgroup v2 и где именно. Приведенный ниже алгоритм поиска ищет точку подключения cgroup v2 вместо обычного пути /sys/fs/cgroup предполагается. В системе, использующей исключительно cgroup v1, эта переменная остаётся пустой; в случае гибридной иерархии она указывает только найденный моунт v2.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r указывает только текущую строку версии. cgroup.controllers перечисляет контроллеры, доступные для активации именно в этой cgroup; это не подтверждает, что они были включены в соответствующих подиерархиях. Для этого, в частности, используется cgroup.subtree_control проверять на соответствующих уровнях иерархии. Контроллеры предоставляются по принципу «сверху вниз», поэтому дочерняя cgroup может передавать только те контроллеры, которые предоставлены родительским узлом.

systemd-cgtop также дает лишь моментальную картину и не является анализом причин. Соберите данные о загрузке ЦП по группам служб, задержках запросов, времени выполнения пакетных заданий и, при необходимости, времени ожидания ввода-вывода за несколько сопоставимых фаз нагрузки. Если задержки возникают только во время резервного копирования, то его временное окно, доля загрузки ЦП или квота, как правило, являются более конкретными первыми точками отсчёта, чем предполагаемая настройка планировщика.

Landlock для специалистов

Функция Landlock была впервые реализована в Linux 5.13, поэтому она не является оригинальной нововведением серии 6.x. В ядрах серии 6.x доступны различные расширенные версии ABI в зависимости от выпуска и ядра дистрибутива. Эта функция представляет собой дополнительный механизм безопасности, с помощью которого процесс может самостоятельно налагать на себя дополнительные ограничения.

Landlock — это модуль безопасности Linux, работающий в режиме наслоения, который действует в дополнение к уже действующим правилам доступа; он не заменяет ни права доступа к файлам в Unix, ни SELinux, ни AppArmor, ни пространства имён, ни контейнеры. Правила могут, в частности, ограничивать доступ к файловой системе и передаются запускаемым впоследствии дочерним процессам. Практический набор функций зависит от доступного ABI и конфигурации ядра.

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

Продуктивное правило не должно основываться исключительно на текущей версии ядра. Landlock имеет версии ABI; приложение должно запрашивать доступные версии ABI во время выполнения и запрашивать только те права доступа или функции, которые поддерживаются данной версией ABI. Таким образом, оно может работать в ограниченном режиме на старых системах, вместо того чтобы полностью выходить из строя из-за недоступности какого-либо интерфейса.

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

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

Особую осторожность следует проявлять при OverlayFS. Правила для слоя оверлея не ограничивают автоматически объединенную иерархию моунтов и наоборот. Поэтому контейнерные и сборные среды с оверлеями требуют отдельной проверки конкретных моунтов и путей доступа. Landlock может служить в этом случае дополнительным уровнем защиты, но не обеспечивает полного разделения клиентов и не заменяет надежную концепцию контейнеров или системы прав доступа.

DAMON — только для особых случаев

DAMON и основанные на нём механизмы Reclaim нельзя однозначно отнести к функциям, впервые появившимся в Linux 6.x. Для администраторов важен функциональный уровень конкретно используемого ядра версии 6.x или ядра дистрибутива. DAMON отслеживает обращения к памяти с целью классификации областей в зависимости от их использования.

Исходя из этого, пытается DAMON_RECLAIM, проактивно освобождать память, которая долгое время не использовалась, при небольшом давлении. Этот метод дополняет обычный процесс освобождения памяти на основе алгоритма LRU; он не предназначен для его замены. В документации ядра он относится к общим системам с перезагрузкой памяти, и в качестве примера приводится виртуализация на основе отчётов о свободных страницах.

В данном сценарии виртуализации решающую роль играет уровень: гостевые системы сообщают хосту о свободных страницах памяти, которые хост может выделить другим гостевым системам. Если гостевая система сообщает о небольшом объеме свободной памяти, хотя у неё есть давно неиспользуемые страницы, можно применить проактивный механизм reclaim в гостях помочь сообщить хосту о большем количестве свободных страниц. Таким образом, DAMON_RECLAIM не является решением на стороне хоста для неиспользуемой оперативной памяти гостей без дополнительной проверки.

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

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

Поэтому для принятия обоснованного решения необходимо провести измерения с использованием четких контрольных показателей, таких как свободное место на хранилище, указанное пользователем, активность реклайминга, поведение свопа, задержка хранилища и время отклика приложений. Сначала тестируйте изменения в аналогичной тестовой среде, определите план отката и наблюдайте за ними в течение типичных фаз нагрузки. Если эти условия не соблюдены или причина перегрузки хранилища не выяснена, DAMON сознательно остается отключенным.

Обновления, исправления в режиме реального времени и перезагрузки

Обслуживание ядра начинается с сопоставления сообщения о безопасности, установленного пакета и фактически запущенного ядра. Затем проверьте в инструкциях к вашему дистрибутиву, какой патч предусмотрен именно для этой ветки ядра и требуется ли перезагрузка. Сам по себе более высокий номер версии 6.x не свидетельствует ни о наличии патча, ни о доступности соответствующего Livepatch; исправления безопасности могут быть портированы и в более старые ядра дистрибутивов.

Также Патчирование в режиме реального времени Эта концепция была внедрена не только в Linux 6.x. Инфраструктура, относящаяся к ядрам версии 6.x, позволяет применять определённые изменения ядра во время работы системы. При этом кумулятивные Livepatches могут атомарно заменить старый патч более новым. Документированные ограничения касаются, в частности, изменений состояния, обратных вызовов и переключения между патчами.

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

Сначала оцените степень срочности и последствия обновления, затем сверьте версии пакетов и текущего ядра и проверьте конкретное предложение по Livepatch. После регулярного обновления ядра с перезапуском проверьте, включено ли ожидаемое ядро и правильно ли работают критически важные службы, сетевые пути, системы резервного копирования и мониторинга. Эта проверка является частью процедуры технического обслуживания и не должна сводиться к простой проверке доступности сервера.

A запланированный перезапуск может потребоваться даже при использовании Livepatching. Изменения в параметрах загрузки ядра, как правило, вступают в силу только при следующей загрузке. Что касается драйверов, прошивки устройств и аппаратного обеспечения, то порядок действий зависит от конкретного компонента, способа его интеграции и методов, применяемых производителем: в некоторых случаях достаточно перезапуска модуля, устройства или службы, в других — требуется полная перезагрузка хоста.

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

• Сознательно ничего не менять, если у наблюдаемого сбоя пока нет понятной причины.
• Не планировать применение Livepatch или внесение изменений в ядро без соответствующей проверки в тестовой среде и задокументированного плана возврата к исходному состоянию.
• Не следует активировать функцию, если соответствующее приложение или платформа не использует её интерфейс.
• Не следует из-за отсутствия окна технического обслуживания полагать, что функция Livepatching охватывает все обновления ядра.