Improving performance (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
Improving performance
. Дата последней синхронизации: 1 июля 2025. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
Ускорение загрузки системы
Pacman/Советы и приёмы#Производительность
OpenSSH (Русский)#Увеличение скорости SSH
Openoffice#Speed up OpenOffice
Ноутбук
Preload
В этой статье представлена информация о базовой диагностике системы, относящейся к производительности, а также о шагах, которые могут быть предприняты для снижения потребления ресурсов или иным образом для оптимизации системы с целью улучшения производительности.
В разделе
Gaming#Improving performance
также есть дополнительные рекомендации для игр и снижения задержек.
Основы
Узнай свою систему
Лучший способ настроить систему — определить «узкие места», то есть подсистемы, которые снижают общую скорость работы. Знание характеристик системы поможет определить их, но также есть несколько основных симптомов.
Если компьютер начинает медленнее работать при одновременном запуске нескольких «больших» приложений (таких как LibreOffice и Firefox), то существует большая вероятность того, что не хватает оперативной памяти. Чтобы проверить объём свободной памяти, выполните эту команду и посмотрите столбец «available»:
$ free -h
Если время загрузки очень большое и если приложения запускаются медленно только при первом запуске, а потом работают нормально, то скорее всего виноват жёсткий диск. Его скорость может быть измерена с помощью команды
hdparm
:
# hdparm -t /dev/sd
X
Примечание
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
) от системы (
/
).
Примечание
Как и со всеми советами из данной статьи, измеряйте получаемое изменение производительности: без
short stroking
(использования лишь небольшой части объёма диска) разделение разделов улучшит время доступа лишь на несколько процентов, поскольку операции чтения/записи всё равно будут распределяться по всему диску при обычном использовании системы. Для сравнения, переход на SSD повысит производительность более чем на порядок.
Выбор и настройка файловых систем
Выбор лучшей файловой системы под особенности системы является очень важным, так как каждая файловая система имеет свои сильные стороны. В статье
Файловые системы
кратко рассматриваются наиболее популярные файловые системы. Вы можете также найти полезные статьи
здесь
.
Параметры монтирования
Различные параметры
*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
Изменение планировщика ввода-вывода
Примечание
Лучший выбор планировщика зависит как от устройства, так и от конкретной рабочей нагрузки. Кроме того, пропускная способность в МБ/с — не единственный показатель производительности: deadline или fairness ухудшают общую пропускную способность, но могут улучшить скорость реакции системы.
Тестирование производительности
может быть полезным для определения производительности каждого планировщика ввода-вывода.
Чтобы посмотреть список доступных планировщиков и текущий планировщик (в квадратных скобках):
$ 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
, чтобы применять их при загрузке системы.
Совет
GNOME
позволяет установить некоторые из этих параметров через приложение «Диски» и не требует создания правила udev.
Примечание
Некоторые функции могут не поддерживаться вашим жёстким диском — hdparm уведомит вас об этом. В таком случае просто пропустите настройку таких функций.
Уменьшение числа операций чтения/записи
Избегание ненужного доступа к медленным накопителям полезно для производительности, а также увеличивает срок службы устройств, хотя на современном оборудовании разница в ожидаемом сроке службы обычно незначительна.
Примечание
32ГБ SSD с посредственным 10-кратным коэффициентом усиления записи (write amplification factor), стандартным циклом записи/стирания 10000 и
записью 10ГБ данных в день
, будет иметь
ожидаемый срок службы 8 лет
. Это становится лучше с
более крупными SSD
и современными контроллерами с меньшим усилением записи. Посмотрите также
этот эксперимент на выносливость
при рассмотрении вопроса о том, действительно ли необходима какая-либо конкретная стратегия для ограничения записи на диск.
Отслеживание записи на диск
Пакет
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
AUR
. Для проверки корректности работы разогнанного процессора рекомендуется провести
стресс-тестирование
.
Изменение частоты процессора
Смотрите
Управление частотой процессора
.
Планировщик
Планировщик (CPU scheduler), используемый по умолчанию в mainline Linux, —
EEVDF
.
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
, предназначенный для автоматической настройки приоритета.
Важно
И
GameMode
, и
Ananicy CPP
меняют приоритеты процессов, так что одновременное их использование вряд ли является хорошей идеей.
[1]
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
) для проверки наличия уязвимостей.
Примечание
При использовании процессора Intel поколения 10 и новее или AMD Ryzen series 1000 и новее ускорение от отключения защиты будет лишь в пределах 5%, а не 25%, как в предыдущих поколениях. Смотрите
общий обзор на начало 2021 года
,
тест Rocket Lake
и
тест Alder Lake
Графика
Настройка 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
Примечание
На некоторых системах включение PCIe resizable BAR может привести к значительной потере производительности. Проведите тестирование, чтобы убедиться, что производительность действительно увеличивается.
CSM в настройках UEFI должен быть отключен.
Спецификация 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-киллера для уничтожения запущенных приложений может привести к потере несохранённой работы. Вам решать, набраться ли терпения и подождать в надежде, что приложения наконец-то освободят память, или как можно скорее вернуть в отзывчивое состояние систему, не отвечающую на запросы.
Иногда пользователь может предпочесть демон 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