Improving performance (Русский) - ArchWiki

Jump to content

# Improving performance (Русский)

7 languages

- English
- Español
- Français
- 日本語
- Polski
- Português
- 中文（简体）

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Improving performance. Дата последней синхронизации: 28 января 2024. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ссылки по теме

- Ускорение загрузки системы
- Pacman/Советы и приёмы#Производительность
- OpenSSH (Русский)#Увеличение скорости SSH
- Openoffice#Speed up OpenOffice
- Ноутбук
- Preload

В этой статье представлена информация о базовой диагностике системы, относящейся к производительности, а также о шагах, которые могут быть предприняты для снижения потребления ресурсов или иным образом для оптимизации системы с целью улучшения производительности. В разделе 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 является хорошим выбором. Однако стандартное ядро тоже может быть настроено для повышения производительности, как показано далее в статье.

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

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

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

### Несколько аппаратных путей

Внутренний аппаратный путь (internal hardware path) описывает способ подключения устройства через материнскую плату. Существуют различные способы подключения через материнскую плату: NIC, PCIe, Firewire, Raid Card, USB и т. д. Распределяя устройства хранения по разным точкам подключения, вы можете избежать появления узких мест. Причина в том, что каждый «путь входа» в материнскую плату «похож на канал», и у этих каналов существует предел пропускной способности. Хорошая новость в том, что на материнской плате обычно несколько каналов, которые можно использовать.

В качестве конкретного примера можно привести ситуацию, когда у вас есть 2 USB-порта на передней панели вашего компьютера и 4 USB-порта на задней панели, и вам нужно подключить 4 диска: вероятно, будет быстрее всего поставить 2 спереди и 2 сзади, чем 3 сзади и 1 спереди. Это связано с тем, что обычно передние порты обрабатываются отдельным от задних корневым концентратором (хабом), что означает возможность отправки вдвое большего количества данных с использованием обоих концентраторов.

Следующие команды помогут определить различные пути в вашем компьютере.

    USB Device Tree

    $ lsusb -t

    PCI Device Tree

    $ lspci -tv

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

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

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

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

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

#### Расположение на 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)[устаревшая ссылка 2024-12-15 ⓘ] основан на коде CFQ и содержит некоторые улучшения. Он не предоставляет диск каждому процессу на фиксированный отрезок времени, но назначает процессу «бюджет», измеряемый в количестве секторов, и использует эвристики. Это относительно сложный планировщик, он может быть более адаптирован для HDD и медленных SSD, поскольку его высокие накладные расходы на операцию, особенно если они связаны с медленным процессором, могут замедлять работу быстрых устройств. Цель BFQ в персональных системах состоит в том, чтобы при интерактивных задачах запоминающее устройство реагировало практически так же, как если бы оно простаивало. В своей конфигурации по умолчанию он ориентирован на обеспечение минимальной задержки, а не на достижение максимальной пропускной способности, что порой может сильно ускорить запуск приложений на HDD.

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

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

Хотя некоторые из ранних алгоритмов уже списаны, официальное ядро Linux поддерживает ряд планировщиков ввода-вывода, которые можно разделить на две категории:

- Планировщики с несколькими очередями доступны по умолчанию. Multi-Queue Block I/O Queuing Mechanism (blk-mq) отображает запросы ввода-вывода в несколько очередей, задачи распределяются по потокам и, следовательно, ядрам процессора. В рамках этого фреймворка доступны следующие планировщики:
  - None, где не применяется алгоритм организации очередей.
  - mq-deadline, адаптация планировщика deadline (смотрите ниже) к многопоточности.
  - Kyber
  - BFQ
- Планировщики с одной очередью являются наследием:
  - NOOP — это простейший планировщик, он вставляет все входящие запросы ввода-вывода в простую очередь FIFO и реализует объединение запросов. В этом алгоритме нет переупорядочивания запроса на основе номера сектора. Поэтому его можно использовать, если упорядочивание выполняется на другом уровне, например, на уровне устройства, или если это не имеет значения, например для SSD.
  - Deadline
  - CFQ

  Примечание: Планировщики с одной очередью были удалены в Linux 5.0.

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

Примечание: Лучший выбор планировщика зависит как от устройства, так и от конкретной рабочей нагрузки. Кроме того, пропускная способность в МБ/с — не единственный показатель производительности: 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.

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

Смотрите статью для соответствующей файловой системы, например Ext4#Improving performance и XFS (Русский)#Производительность.

#### Подкачка

Смотрите Swap (Русский)#Производительность.

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

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

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

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

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

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

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

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

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

## Процессор

### Оверклокинг

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

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

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

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

### Планировщик

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

- MuQSS — Планировщик MuQSS (родившийся из "Brain Fuck Scheduler") призван улучшить отзывчивость системы для настольных компьютеров и других рабочих нагрузок. Доступен с набором патчей `-ck` разработанным Con Kolivas.

  Unofficial user repositories/Repo-ck || linux-ckAUR

- PDS — Планировщик PDS расшифровывается как "планировщик множественных очередей на основе приоритетов и дедлайнов Skiplist", который является производным от бывшего планировщика BFS Кона Коливаса с поддержкой очереди переменного выполнения (VRQ), но при этом отличается от текущего планировщика MuQSS.

  https://cchalpha.blogspot.com/ || linux-pdsAUR[ссылка недействительна: package not found]

- BMQ — Планировщик BMQ "BitMap Queue" был создан на основе имеющегося опыта разработки PDS и вдохновлён планировщиком из Zircon — ядра, на котором работает Fuchsia OS от Google. Доступен с набором патчей от CachyOS.

  https://cchalpha.blogspot.com/ || linux-cachyos-bmqAUR[ссылка недействительна: package not found]

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

  https://cchalpha.blogspot.com/ || linux-prjcAUR

- TT — Цель планировщика Task Type (TT) — определить типы задач на основе их поведения и управлять планированием на основе их типов.

  https://github.com/hamadmarri/TT-CPU-Scheduler || linux-ttAUR[ссылка недействительна: package not found]

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

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

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

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

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

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

#### Ananicy

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

#### cgroups

Смотрите cgroups.

#### Cpulimit

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

    $ cpulimit -l 50 -p 5081

### irqbalance

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

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

Важно: Не применяйте этот параметр без понимания уязвимостей, которые он открывает. Более подробную информацию смотрите здесь и здесь.

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

    mitigations=off

Описание всех опций, которые он переключает, доступно на kernel.org. Вы можете использовать spectre-meltdown-checkerAUR или 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) — Записывает опции в стандартный файл drirc.

  https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf

- DRIconf — Апплет конфигурации для Direct Rendering Infrastructure. Позволяет настраивать параметры производительности и визуального качества OpenGL на уровне драйвера, экрана и/или приложения.

  https://dri.freedesktop.org/wiki/DriConf/ || driconfAUR[ссылка недействительна: package not found]

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

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

### Оверклокинг

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

Смотрите AMDGPU#Overclocking или NVIDIA/Советы и приёмы#Включение разгона.

### Включение PCI resizable BAR

Примечание:

- На некоторых системах включение PCI resizable BAR может привести к значительной потере производительности. Проведите тестирование, чтобы убедиться, что производительность действительно увеличивается.
- CSM в настройках UEFI должен быть отключен.

Спецификация PCI позволяет использовать базовые адресные регистры (Base Address Registers, BAR'ы) большего размера для предоставления доступа к памяти PCI-устройств контроллеру PCI. Доступ ко всей видеопамяти повышает производительность, а также позволяет задействовать оптимизации в графическом драйвере. Комбинация Resizable BAR, Above 4G Decoding и оптимизаций в драйвере — это то, что AMD называет AMD Smart Access Memory[устаревшая ссылка 2024-07-30 ⓘ], которая изначально стала доступна на материнских платах с набором микросхем 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) и требования к хранилищу небольшие, можно разместить корневую файловую систему в оперативной памяти, сделав её оверлеем поверх реального корня, хранящегося на диске. Это может сильно повысить производительность ценой ограничения доступного для записи места. Смотрите liverootAUR.

### zram или zswap

Похожие преимущества (с похожими затратами) можно получить с использованием zswap или zram. Они в целом похожи по назначению, но работают по-разному: zswap работает как сжатый кэш ОЗУ и не требует (и не допускает) обширной конфигурации в пространстве пользователя, в то время как zram — это модуль ядра, который позволяет создать сжатое блочное устройство в памяти и использовать его для любых целей. 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 || oomdAUR

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

  https://github.com/hakavlad/nohang || nohang-gitAUR

- low-memory-monitor — GNOME developer's effort that aims to provides better communication to userspace applications to indicate the low memory state, besides that it could be configured to trigger the kernel OOM-killer. Based on PSI, requires Linux 5.2+.

  https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR

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

  https://gitlab.freedesktop.org/benzea/uresourced || uresourcedAUR

## Сеть

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

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

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

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

Многим пользователям эта функция нужна из-за критически важной роли их системы (например, серверов) или из-за отсутствия возможности сброса питания (например, встроенных устройств). Таким образом, эта функция требуется для нормальной работы в некоторых ситуациях. С другой стороны, обычным пользователям (например, на настольных компьютерах и ноутбуках) эта функция не нужна, и они могут её отключить.

Чтобы отключить сторожевые таймеры (как программные, так и аппаратные), добавьте `nowatchdog` к параметрам загрузки.

Параметр загрузки `nowatchdog` может не работать для аппаратного сторожевого таймера Intel TCO [1]. В этом случае можно отключить модуль ядра для TCO, добавив параметр ядра `modprobe.blacklist=iTCO_wdt`.

При использовании процессора AMD Ryzen проверьте наличие `sp5100-tco` в журнале. Это аппаратный сторожевой таймер внутри чипсетов серии AMD 700. Для его отключения:

    /etc/modprobe.d/disable-sp5100-watchdog.conf

    blacklist sp5100_tco

Или используйте параметр ядра `modprobe.blacklist=sp5100_tco`.

Для проверки изменений выполните `cat /proc/sys/kernel/watchdog` или `wdctl`.

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

Для более подробной информации смотрите [2], [3], [4] и [5].

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

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

Categories:

- Hardware (Русский)
- System administration (Русский)

Hidden categories:

- Pages with dead links
- Pages with broken package links