Improving performance (Русский)

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

Основы

Узнай свою систему

Лучший способ настроить систему — определить «узкие места», то есть подсистемы, которые снижают общую скорость работы. Знание характеристик системы поможет определить их, но также есть несколько основных симптомов.

• Если компьютер начинает медленнее работать при одновременном запуске нескольких «больших» приложений (таких как LibreOffice и Firefox), то существует большая вероятность того, что не хватает оперативной памяти. Чтобы проверить объём свободной памяти, выполните эту команду и посмотрите столбец «available»:

  $ free -h

• Если время загрузки очень большое и если приложения запускаются медленно только при первом запуске, а потом работают нормально, то скорее всего виноват жёсткий диск. Его скорость может быть измерена с помощью команды hdparm:

  # hdparm -t /dev/sdX

  Примечание: hdparm измеряет только чистую скорость чтения жёсткого диска и не может считаться полноценным тестом производительности. Тем не менее, значение скорости выше 40 МБ/с (при бездействии) можно считать приемлемым для средней системы.
• Если загрузка процессора постоянно высокая, даже когда есть достаточно оперативной памяти, попробуйте снизить нагрузку, остановив работающие демоны и/или процессы. Загрузку процессора можно контролировать множеством способов, например с помощью htop, pstree или любого другого инструмента для мониторинга:

  $ htop

• Если медленно работают только те приложения, которые используют аппаратное ускорение (direct rendering), то есть где используется видеокарта (видеоплееры, игры или даже оконный менеджер), то увеличение производительности видеокарты должно помочь. Сперва нужно проверить, включен ли direct rendering. Это можно проверить с помощью команды glxinfo, которая входит в состав пакета mesa-utils, которая должна вернуть direct rendering: Yes в ответ на команду

  $ glxinfo | grep "direct rendering"

• Если вы используете среду рабочего стола, отключение (ненужных) визуальных эффектов может уменьшить нагрузку на видеокарту. Попробуйте использовать более легковесную среду или создайте свою собственную среду, если существующие не подходят под ваши требования или требования железа.
• Использование оптимизированного ядра улучшает производительность. Обычно linux-zen является хорошим выбором. Однако стандартное ядро тоже может быть настроено для повышения производительности, как показано далее в статье.

Тестирование производительности

Результаты оптимизации часто трудно оценить. Однако их можно измерить с помощью инструментов тестирования производительности.

Устройства хранения

Размер сектора

Перед разметкой NVMe-накопителей и жёстких дисков с расширенным форматом (Advanced Format) проверьте, что они используют оптимальный логический размер сектора.

Разметка дисков

Убедитесь, что разделы на ваших дисках правильно выровнены.

Несколько дисков

Если у вас есть несколько дисков, их можно объединить в программный RAID, что сильно увеличит скорость.

Размещение подкачки на отдельном диске также может немного помочь, особенно если ваш компьютер часто обращается к ней.

SSD в качестве кэша перед HDD

Если полностью отказаться от жёстких дисков не получается, можно добавить твердотельный накопитель в качестве кэширующего слоя, чтобы повысить скорость и уменьшить шум при случайном доступе. Доступны следующие варианты реализации: LVM#Cache, Bcache, Bcachefs#SSD caching.

Расположение на HDD

При использовании обычных HDD с вращающимися пластинами структура разделов может повлиять на производительность системы. Секторы в начале диска (ближе к внешней стороне диска) быстрее, чем в конце. Кроме того, меньший раздел требует меньше движений головки диска и, следовательно, ускоряет операции с диском. Поэтому рекомендуется создать небольшой раздел (примерно 15-20 ГиБ в зависимости от ваших потребностей) только под вашу систему как можно ближе к началу диска. Остальные данные (изображения, видео) стоит хранить на отдельном разделе, и это обычно достигается путём отделения домашнего каталога (/home) от системы (/).

Выбор и настройка файловых систем

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

Параметры монтирования

Различные параметры *atime могут повысить производительность относительно strictatime.

Другие параметры специфичны для конкретных файловых систем, поэтому смотрите соответствующие статьи:

• Ext3 (Русский)
• Ext4#Improving performance
• JFS#Optimizations
• XFS (Русский)#Производительность
• Btrfs (Русский)#Дефрагментация, Btrfs (Русский)#Сжатие и btrfs(5)
• ZFS#Tuning
• NTFS (Русский)#Увеличение производительности

Изменение параметров ядра

Есть несколько ключевых параметров, влияющих на производительность блочных устройств, смотрите sysctl (Русский)#Виртуальная память.

Планировщики ввода-вывода

Информация

Планировщик ввода-вывода (I/O scheduler) — это компонент ядра, который решает, в каком порядке операции блочного ввода-вывода отправляются на запоминающие устройства. Здесь полезно вспомнить особенности двух основных типов дисков, потому что цель планировщика ввода-вывода — оптимизировать способ обработки запросов на чтение:

• У обычного жёсткого диска (HDD) есть вращающиеся диски и головка, которая физически перемещается в нужное место. Как следствие, задержки случайных операций довольно высоки и составляют от 3 до 12 мс (будь то высокопроизводительный серверный накопитель или накопитель ноутбука при использовании в обход буфера записи контроллера диска), в то время как последовательный доступ обеспечивает гораздо более высокую пропускную способность. Типичная пропускная способность жёсткого диска составляет около 200 операций ввода-вывода в секунду (IOPS).

• Твердотельный накопитель (SSD) не имеет движущихся частей, случайные операции выполняются так же быстро, как и последовательный доступ, обычно менее 0,1 мс, и он может обрабатывать несколько одновременных запросов. Типичная пропускная способность SSD превышает 10000 IOPS, чего более чем достаточно при обычных рабочих нагрузках.

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

Алгоритмы планирования

Одним из способов повышения пропускной способности является линеаризация доступа: упорядочивание ожидающих запросов по их логическим адресам и группировка самых близких из них. Исторически это был первый планировщик ввода-вывода Linux под названием elevator.

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

Хотя эти планировщики пытаются улучшить общую пропускную способность, они могут оставлять некоторые невезучие запросы в ожидании очень долгое время. Например, представьте, что большинство процессов отправляют запросы в начало диска, в то время как невезучий процесс делает запрос в другой конец диска. Это потенциально бесконечное откладывание процесса называется голоданием (starvation). Для повышения справедливости (fairness) был разработан алгоритм deadline. У него есть очередь, упорядоченная по адресу, аналогичная elevator, но если какой-либо запрос находится в этой очереди слишком долго, он перемещается в очередь «истёкших» запросов, упорядоченную по времени истечения. Планировщик сначала проверяет очередь «истёкших» запросов, обрабатывает запросы оттуда и только затем переходит в очередь elevator. Обратите внимание, что такая справедливость отрицательно сказывается на общей пропускной способности.

Completely Fair Queuing (CFQ) («абсолютно справедливая очередь») подходит к проблеме иначе, выделяя временной интервал и количество разрешённых запросов по очереди в зависимости от приоритета процесса, отправляющего их. Он поддерживает cgroups, что позволяет зарезервировать некоторый объём ввода-вывода для определённого набора процессов. Это особенно полезно для общего и облачного хостинга: пользователи, которые заплатили за определённое число IOPS, хотят получать свою долю, когда это необходимо. Кроме того, он простаивает в конце синхронного ввода-вывода в ожидании других ближайших операций, переняв эту функцию у планировщика anticipatory и внеся некоторые улучшения. Планировщики anticipatory и elevator были выведены из эксплуатации из ядра Linux и заменены более продвинутыми альтернативами, представленными ниже.

Budget Fair Queuing (BFQ) основан на коде CFQ и содержит некоторые улучшения. Он не предоставляет диск каждому процессу на фиксированный отрезок времени, но назначает процессу «бюджет», измеряемый в количестве секторов, и использует эвристики. Это относительно сложный планировщик, он может быть более адаптирован для HDD и медленных SSD, поскольку его высокие накладные расходы на операцию, особенно если они связаны с медленным процессором, могут замедлять работу быстрых устройств. Цель BFQ в персональных системах состоит в том, чтобы при интерактивных задачах запоминающее устройство реагировало практически так же, как если бы оно простаивало. В своей конфигурации по умолчанию он ориентирован на обеспечение минимальной задержки, а не на достижение максимальной пропускной способности, что порой может сильно ускорить запуск приложений на HDD.

Kyber — относительно новый планировщик, созданный на основе методов активного управления очередью, используемых для сетевой маршрутизации. Реализация основана на «токенах», которые служат механизмом ограничения запросов. Токен очереди необходим для выделения запроса, он используется для предотвращения голодания. Dispatch-токен также необходим и ограничивает операции определённого приоритета на данном устройстве. Наконец, определяется целевая задержка чтения, и планировщик настраивается для достижения этой цели. Реализация алгоритма относительно проста и считается эффективной для быстрых устройств.

Планировщики ввода-вывода в ядре

Хотя некоторые из ранних алгоритмов уже не используются, официальное ядро Linux поддерживает несколько планировщиков ввода-вывода. Multi-Queue Block I/O Queuing Mechanism (blk-mq) распределяет запросы ввода-вывода по нескольким очередям, задачи распределяются по потокам и, следовательно, ядрам процессора. В рамках этого механизма доступны следующие планировщики:

• None, где не применяется алгоритм организации очередей.
• mq-deadline, адаптация планировщика deadline (смотрите ниже) к многопоточности.
• Kyber
• BFQ

Изменение планировщика ввода-вывода

Чтобы посмотреть список доступных планировщиков и текущий планировщик (в квадратных скобках):

$ cat /sys/block/sda/queue/scheduler

mq-deadline kyber [bfq] none

Чтобы посмотреть доступные планировщики для всех устройств:

$ grep "" /sys/block/*/queue/scheduler

/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none

Чтобы изменить планировщик на bfq для устройства sda:

# echo bfq > /sys/block/sda/queue/scheduler

Процесс изменения планировщика ввода-вывода в зависимости от того, вращающийся ли диск или нет, может быть автоматизирован и сохранён между перезагрузками. Например, приведённые ниже правила udev устанавливают планировщик bfq для вращающихся дисков, bfq для SSD/eMMC и none для NVMe:

/etc/udev/rules.d/60-ioschedulers.rules

# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

# NVMe SSD
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

Перезагрузитесь или загрузите новые правила.

Настройка планировщика ввода-вывода

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

Чтобы посмотреть доступные настройки для устройства, в примере ниже sdb, который использует deadline, используйте:

$ ls /sys/block/sdb/queue/iosched

fifo_batch  front_merges  read_expire  write_expire  writes_starved

Чтобы улучшить пропускную способность deadline ценой увеличения задержки, можно увеличить fifo_batch с помощью команды:

# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch

Настройка управления питанием и кэшем записи

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

Смотрите hdparm (Русский)#Настройка управления питанием и hdparm (Русский)#Кэш записи.

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

Уменьшение числа операций чтения/записи

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

Отслеживание записи на диск

Пакет iotop позволяет отсортировать процессы по уровню записи на диск и увидеть, сколько и как часто программы записывают на диск. Подробнее смотрите iotop(8).

Перемещение файлов в tmpfs

Можно переместить файлы, такие как профиль вашего браузера, в файловую систему tmpfs, чтобы улучшить отзывчивость приложения с помощью хранения всех нужных файлов в оперативной памяти:

• Смотрите Profile-sync-daemon для синхронизации профилей браузера. Некоторым браузерам может потребоваться особое внимание; смотрите, например, Firefox (Русский)/Profile on RAM (Русский).
• Смотрите Anything-sync-daemon для синхронизации любого указанного каталога.
• Смотрите makepkg (Русский)#Сокращение времени сборки для ускорения времени компиляции путём сборки пакетов в tmpfs.

Файловые системы

Смотрите раздел об улучшении производительности в статье интересующей вас файловой системы; их список приведён в разделе #Выбор и настройка файловых систем.

Подкачка

Смотрите Пространство подкачки#Производительность.

Интервал writeback и размер буфера

Смотрите sysctl (Русский)#Виртуальная память.

Отключение дампов памяти

Смотрите Дамп памяти#Отключение автоматических дампов памяти.

Планирование ввода-вывода с ionice

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

Приоритет ввода-вывода фонового процесса можно снизить до уровня «Ожидание» («Idle»), запустив его с помощью команды

$ ionice -c 3 команда

Подробности доступны в кратком введении в ionice и ionice(1).

TRIM

Для более оптимальной работы и распределения износа ячеек памяти контроллеру SSD желательно знать, в каких блоках диска не хранятся данные. Для этого операционная система может отправлять диску команды TRIM. Подробнее в разделе Твердотельные накопители#TRIM.

Сеть

• Настройка параметров ядра: смотрите sysctl (Русский)#Увеличение производительности
• Сетевая карта (NIC): смотрите Настройка сети#Установка MTU и длины очереди
• DNS: используйте кэширующий резолвер DNS, смотрите Разрешение доменных имён#DNS-серверы
• Samba: смотрите Samba (Русский)#Увеличение пропускной способности

Процессор

Разгон

Разгон (оверклокинг) улучшает вычислительную производительность процессора за счёт увеличения его пиковой тактовой частоты. Возможность разгона зависит от комбинации модели процессора и модели материнской платы. Чаще всего это делается через BIOS. У разгона также есть недостатки и риски, так что выполнять его не рекомендуется.

Многие чипы Intel неправильно сообщают о своей тактовой частоте в acpi_cpufreq и большинстве других утилит. Это приводит к появлению большого количества сообщений в dmesg, чего можно избежать, выгрузив и занеся в чёрный список модуль ядра acpi_cpufreq. Чтобы узнать тактовую частоту, используйте i7z из пакета i7z. Для проверки корректности работы разогнанного процессора рекомендуется провести стресс-тестирование.

Изменение частоты процессора

Смотрите Управление частотой процессора.

Планировщик

Планировщик (CPU scheduler), используемый по умолчанию в mainline Linux, — EEVDF.

• MuQSS — Multiple Queue Skiplist Scheduler. Доступен с набором патчей -ck, разработанным Con Kolivas.

Unofficial user repositories/Repo-ck || linux-ck^AUR

• Project C — Кросс-проект по рефакторингу BMQ в Project C, с пересозданием PDS на основе кодовой базы Project C. Таким образом это слияние двух проектов, с последующим обновлением PDS в виде Project C. Рекомендуется как более свежая разработка.

https://cchalpha.blogspot.com/ || linux-prjc^AUR

• BORE — Сосредоточен на том, чтобы пожертвовать некоторой справедливостью ради меньшей задержки планирования интерактивных задач, он построен поверх CFS и корректируется только для обновления кода vruntime, поэтому общие изменения довольно малы по сравнению с другими неофициальными планировщиками CPU.

https://github.com/firelzrd/bore-scheduler || linux-cachyos-bore^AUR

• SCX — Позволяет динамически подключать различные планировщики без перезагрузки системы.

https://github.com/sched-ext/scx || scx-scheds

Ядро реального времени

Некоторые приложения, такие как запуск ТВ-тюнера в разрешении Full HD (1080p), могут выиграть от использования ядра с функционалом реального времени.

Настройка приоритета процессов

Смотрите также nice(1) и renice(1).

Ananicy

Ananicy CPP — демон, доступный в пакете ananicy-cpp или ananicy-cpp-git^AUR, предназначенный для автоматической настройки приоритета.

cgroups

Смотрите cgroups.

LimitCPU

LimitCPU — программа, ограничивающая использование процессора для определённого процесса. После установки limitcpu^AUR вы можете ограничить использование ЦП процессами по их PID, используя шкалу от 0 до 100, умноженную на число ядер вашего процессора. Например, если у вас восьмиядерный процессор, то вы можете задать значение от 0 до 800. Использование:

$ limitcpu -l 50 -p 5081

irqbalance

Цель irqbalance — распределить аппаратные прерывания между процессорами в многопроцессорной системе для повышения производительности. Его можно контролировать с помощью службы irqbalance.service.

Отключение защиты от уязвимостей

Отключение защиты от уязвимостей процессора может улучшить производительность. Используйте следующий параметр ядра для отключения всех защит:

mitigations=off

Описание всех опций, которые он переключает, доступно на kernel.org. Вы можете использовать spectre-meltdown-checker^AUR или lscpu(1) (из пакета util-linux) для проверки наличия уязвимостей.

Графика

Настройка Xorg

Производительность графики может зависеть от настроек в xorg.conf(5); смотрите статьи NVIDIA, AMDGPU и Intel. Неправильные настройки могут помешать запуску Xorg, поэтому будьте осторожны.

Настройка Mesa

Производительность драйверов Mesa можно настроить через drirc. Есть графический интерфейс adriconf (Advanced DRI Configurator).

Аппаратное ускорение видео

Аппаратное ускорение видео даёт возможность декодировать или кодировать видео с помощью видеокарты.

Разгон

Как и с процессорами, разгон видеокарт может напрямую улучшить производительность, но обычно делать его не рекомендуется. Доступно несколько пакетов: rovclock^AUR (для ATI), rocm-smi-lib (для новых AMD), nvclock^AUR (старые NVIDIA до Geforce 9), nvidia-utils (для новых NVIDIA).

Смотрите AMDGPU (Русский)#Разгон или NVIDIA/Советы и рекомендации#Включение разгона через nvidia-settings.

Включение PCIe resizable BAR

Спецификация PCI позволяет использовать базовые адресные регистры (Base Address Registers, BAR'ы) большего размера для предоставления доступа к памяти PCI-устройств контроллеру PCI. Доступ ко всей видеопамяти повышает производительность, а также позволяет задействовать оптимизации в графическом драйвере. Комбинация resizable BAR, above 4G decoding и оптимизаций в драйвере — это то, что AMD называет AMD Smart Access Memory, которая изначально стала доступна на материнских платах с чипсетами AMD Series 500, а затем была добавлена в AMD Series 400, Intel Series 300 и более поздние через обновления UEFI. Этот параметр может быть доступен не на всех материнских платах и, как известно, иногда вызывает проблемы с загрузкой на некоторых платах.

Если BAR имеет размер 256M, функция не включена или не поддерживается:

# dmesg | grep BAR=

[drm] Detected VRAM RAM=8176M, BAR=256M

Найдите и включите опцию, которая обычно называется «Above 4G Decode» или «>4GB MMIO» в настройках вашей материнской платы, и после этого BAR должен стать больше:

# dmesg | grep BAR=

[drm] Detected VRAM RAM=8176M, BAR=8192M

Оперативная память, подкачка и обработка нехватки памяти

Тактовая частота и тайминги

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

Корневая ФС на ОЗУ-оверлее

Если система загружается с медленно записывающего носителя (USB, HDD) и требования к хранилищу небольшие, можно разместить корневую файловую систему в оперативной памяти, сделав её оверлеем поверх реального корня, хранящегося на диске. Это может сильно повысить производительность ценой ограничения доступного для записи места. Смотрите liveroot^AUR.

Подкачка в zram или zswap

Похожие преимущества (с похожими затратами) можно получить с использованием zswap или zram. Они в целом похожи по назначению, но работают по-разному:

• zswap работает как сжатый кэш ОЗУ и не требует (и не допускает) обширной конфигурации в пространстве пользователя. Он работает в связке с обычной подкачкой и действует как кэш перед ней. Страницы памяти, которые должны попадать в подкачку, вместо этого попадают в zswap;
• zram — это модуль ядра, который позволяет создать сжатое блочное устройство в памяти и использовать его для любых целей, в том числе в качестве подкачки. Создавать обычную подкачку не требуется. Модуль имеет множество настраиваемых параметров, в том числе позволяет задать устройство для выгрузки на него редко используемых страниц.

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

Использование памяти видеокарты

В том маловероятном случае, когда у вас очень мало ОЗУ и много лишней видеопамяти, можно использовать последнюю в качестве подкачки. Смотрите Swap on video RAM.

Повышение отзывчивости системы в условиях нехватки памяти

В традиционной системе GNU/Linux, особенно для графических рабочих станций, когда выделенная память оказывается перегружена (overcommitted), общая отзывчивость системы может упасть до почти непригодного для использования состояния раньше чем успеет сработать встроенный в ядро OOM-киллер или освободится достаточно памяти (что вряд ли произойдёт быстро, так как у вас с трудом получится закрыть ресурсоёмкие приложения в условиях плохой отзывчивости системы). Поведение также зависит от конкретных настроек и условий, возврат к нормальному состоянию отклика может занять от нескольких секунд до более получаса, что может быть болезненным при ожидании в серьёзном сценарии, например во время презентации на конференции.

Хотя поведение ядра и пользовательского пространства в условиях нехватки памяти может улучшиться в будущем, как это обсуждается в списках рассылки kernel и Fedora, пользователи могут использовать более эффективные варианты, чем полный сброс системы или настройка sysctl параметров vm.overcommit_*:

• Запустить OOM-киллер вручную с помощью Magic SysRq key — Alt+SysRq+f.
• Использовать OOM-демон для решения этих проблем автоматически (или в интерактивном режиме).

Иногда пользователь может предпочесть демон OOM в пространстве пользователя вместо SysRq, потому что в OOM-киллере ядра вы не можете установить приоритет того, какие процессы убивать (или не убивать). Список некоторых демонов OOM:

• systemd-oomd — Предоставляется systemd как systemd-oomd.service, который использует cgroups-v2 и pressure stall information (PSI) для мониторинга и принятия мер до того, как запустится OOM-киллер в ядре.

https://github.com/systemd/systemd, systemd-oomd(8) || systemd

• earlyoom — Простая реализация OOM-киллера, написанная на C.

https://github.com/rfjakob/earlyoom || earlyoom

• oomd — Реализация OOM-киллера на основе PSI, требует ядро Linux версии 4.20+. Конфигурация в JSON и довольно сложна. Используется в производственной среде Facebook.

https://github.com/facebookincubator/oomd || oomd^AUR

• nohang — Сложный обработчик OOM, написанный на Python, с опциональной поддержкой PSI, более настраиваемый чем earlyoom.

https://github.com/hakavlad/nohang || nohang-git^AUR

• low-memory-monitor — Усилия разработчиков GNOME, направленные на обеспечение лучшей связи с приложениями для индикации состояния низкой памяти; также может быть настроен на запуск OOM-киллера. Основан на PSI, требует Linux 5.2+.

https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-git^AUR

• uresourced — Небольшой демон, который включает защиту ресурсов на базе cgroups для активного графического пользовательского сеанса.

https://gitlab.freedesktop.org/benzea/uresourced || uresourced^AUR

Сторожевые таймеры

Как пишет Wikipedia:ru:Сторожевой таймер:

Сторожевой таймер (watchdog) — аппаратно реализованная схема контроля над зависанием системы. Представляет собой таймер, который периодически сбрасывается контролируемой системой. Если сброса не произошло в течение некоторого интервала времени, происходит принудительная перезагрузка системы.

Сторожевой таймер используется для восстановления работы системы в исключительных ситуациях. Если ключевой компонент системы (например, сеть, файловая система, ACPI или systemd) приводит к зависанию, сторожевой таймер обнаруживает это и запускает перезагрузку. Важно отличать этот аварийный механизм от управления системными ресурсами во время работы системы, которое описано в разделе #Повышение отзывчивости системы в условиях нехватки памяти.

systemd watchdog

В systemd есть встроенный механизм сброса сторожевого таймера, работающий через /dev/watchdog, если загружен соответствующий модуль ядра (подробнее ниже). Когда система зависает, аппаратный сторожевой таймер запускает перезагрузку системы.

Настройка сторожевого таймера в systemd

По умолчанию RuntimeWatchdogSec отключен. Для включения создайте такой drop-in файл для systemd-system.conf(5):

/etc/systemd/system.conf.d/watchdog.conf

[Manager]
RuntimeWatchdogSec=10s
RebootWatchdogSec=45s

• RuntimeWatchdogSec=10s: если systemd не отвечает более 10 секунд, система принудительно перезагружается.
• RebootWatchdogSec=45s: если в процессе штатной перезагрузки система зависает, сторожевой таймер запустит принудительную перезагрузку через 45 секунд.

Перезагрузите systemd для применения изменений:

# systemctl daemon-reexec

Проверьте, что настройки применились:

$ systemctl show | grep Watchdog

RuntimeWatchdogUSec=10s
RebootWatchdogUSec=45s

Проверка поддержки аппаратного сторожевого таймера

В зависимости от оборудования поддержка аппаратного сторожевого таймера обеспечивается разными модулями ядра (например, iTCO_wdt на некоторых чипсетах Intel, sp5100_tco на некоторых платформах AMD). Чтобы проверить наличие загруженного модуля аппаратного сторожевого таймера, выполните такую команду:

$ lsmod | grep название_модуля

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

/etc/modules-load.d/watchdog.conf

название_модуля

# modprobe название_модуля

Укажите название_модуля, соответствующего вашему оборудованию.

Ссылки

• systemd-system.conf(5)
• Документация ядра
• systemd-boot (Русский)
• Пост в блоге Леннарта Поттеринга

Смотрите также

• Red Hat Performance Tuning Guide
• Linux Performance Measurements using vmstat