Настройка Debian 13. Одноразовый тюнинг и обслуживание системы

null@example.com (survordie) — Fri, 14 Aug 2026 11:45:52 +0000

Предыдущая часть находится тут.

Debian как и Мастдай нужно периодически обслуживать - обновлять систему, удалять ненужные программы, просматривать логи на предмет ошибок.

+ Обновление системы
+ Автоматическое обновление системы
Для ленивых предусмотрено автоматическое обновление Debian, которое по-умолчанию устанавливает критические обновления безопасности, что позволяет системе безопасно существовать без всякого вмешательства пользователя. Я не пользуюсь, но если настраивать бабушкам, то самое оно.
+ Минимальная установка - только важные обновления безопасности
Установим пакет:
sudo aptitude install unattended-upgrades
и настроим его на автоматический запуск:
sudo dpkg-reconfigure unattended-upgrades
в появившемся диалоговом окне будет предложено включить автоматическую установку обновлений. Нужно выбрать Да и на этом минимальная базовая настройка будет завершена.
При этом создаётся файл /etc/apt/apt.conf.d/20auto-upgrades, который включает автоматическое обновление списка пакетов и их установку.
Для того, чтобы автоматически удалять ненужные пакеты из кеша нужно отредактировать /etc/apt/apt.conf.d/20auto-upgrades:
sudo nano /etc/apt/apt.conf.d/20auto-upgrades
добавив параметр
APT::Periodic::AutocleanInterval "30";
где 30 - интервал очистки в днях.
+ Обновление из всех подключенных репозиториев
Предыдущий пункт по минимальной установке должен быть выполнен. В этой части лишь его донастройка.
Для этого нужно настроить список разрешённых источников обновлений в конфигурационном файле unattended-upgrades.
Редактируем главный файл, где определяются правила для автоматических обновлений:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
в файле найти секцию Unattended-Upgrade::Origins-Pattern. Она определяет, из каких
источников можно автоматически устанавливать обновления.
Чтобы разрешить обновления из всех подключённых репозиториев, нужно закомментировать/удалить
существующие строки и добавить правило "origin=*".
Будет выглядеть так:
// Automatically upgrade packages from these (origin:archive) pairs Unattended-Upgrade::Origins-Pattern { "origin=*"; };
Правило "origin=*" — это универсальное указание, которое говорит системе автоматически
обновлять пакеты из всех источников, независимо от их происхождения
Для того, чтобы убедиться, что автоматические обновления работают, нужно посмотреть логи (не ранее следующего дня после установки пакета):
sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log
+ Настройка таймеров
По умолчанию в Debian существуют два системных таймера, которые управляют автоматическим обновлением: один отвечает за обновление локального кеша репозиториев, другой — непосредственно за установку обновлений. Если автоматическое обновление не нужно, то их нужно отключить.
Сами службы запускаются таймерами, статус которых можно посмотреть командами:
systemctl status apt-daily.timer
и
systemctl status apt-daily-upgrade.timer
Если они существуют и активны Active: active (waiting), то отключаем их.
Отключение обновления локального репозитория по расписанию:
sudo systemctl disable --now apt-daily.timer
и отключение обновления системы по расписанию:
sudo systemctl disable --now apt-daily-upgrade.timer
Эти таймеры управляют запуском скриптов обновления. Их отключение гарантирует, что автоматические обновления не будут выполняться по расписанию.
На случай, если вдруг интересно содержимое этих таймеров(их расписание), то это можно сделать командой:
systemctl cat apt-daily.timer
Секция [Timer] будет выглядеть примерно так:
# /usr/lib/systemd/system/apt-daily.timer
[Unit]
Description=Daily apt download activities
[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true
[Install]
WantedBy=timers.target
Включить обратно:
sudo systemctl enable --now apt-daily.timer
и
sudo systemctl enable --now apt-daily-upgrade.timer
На случай, если автоматическое обновление устраивает, но нужно подкорректировать параметры запуска, нужно переопределить содержимое таймеров для apt-daily.timer и apt-daily-upgrade.timer
Переопределяем apt-daily.timer:
sudo systemctl edit apt-daily.timer
Начнётся создание файла /etc/systemd/system/apt-daily.timer.d/override.conf Нужно обратить внимание на строчку в файле (всё, что будет ниже этого комментария - применяться не будет):
### Edits below this comment will be discarded
Если до этого комментария не будет никаких изменений, то файл переопределения конфигурации не создастся.
Представим, что мы хотим обновить нашу систему в субботу вечером, чтобы в понедельник утром получить готовую и обновлённую систему, которую не предполагается автоматически обновлять до следующей субботы. Суббота - ну на случай если вдруг произойдёт чудо и система поломается после обновления. Тогда будет время(целое воскресенье) чтобы починить систему (шутка). :-D
Для этого введём НАД строкой ### Edits below this comment will be discarded следующий код:
[Timer]
OnCalendar=Sat *-*-* 18:00

Сохраняем файл и выходим.
То же самое проделываем для таймера apt-daily-upgrade.timer:
sudo systemctl edit apt-daily-upgrade.timer
Для того, чтобы проверить корректность этой строки, используется команда, которая нам покажет когда будет следующий запуск этого таймера:
systemd-analyze calendar "Sat *-*-* 18:00"
Для того, чтобы посмотреть список всех таймеров и время их срабатывания, нужно ввести команду:
systemctl list-timers --all
Для проверки реального времени следующего запуска таймера после применения изменений, нужно ввести команду:
systemctl list-timers apt-daily.timer
Для удаление переопределения сервиса нужно использовать команду sudo systemctl revert <имя-службы>
Например:
sudo systemctl revert apt-daily.timer
Сам сервис эта команда не отключает.
+ Ручное обновление системы
Система и программы, установленные через репозитории(основной и сторонние) обновляются одновременно.
Сначала обновляем локальный кеш:
sudo aptitude update
Затем делаем обновление системы. Нежно:
sudo aptitude safe-upgrade
+ Пример работы команды
На скрине видно, что обновляются пакеты из различных репозиториев.
VS Code из репозитория Микрософта
Opera GX из репозитория Оперы
Master PDF Editor из собственного репозитория
и три пакета из репозитория безопасности trixie-security. Это значит, что на эти пакеты были наложены патчи безопасности.
Если бы пакеты прилетели из репозитория trixie-updates, то это бы значило, что в пакет внесены изменения, не связанные с безопасностью, — например, исправления ошибок или обновления данных.
После успешного обновления запускаем команду очистки ненужных старых пакетов (удаление их с кеша, который хранится на диске):
sudo aptitude autoclean
+ Обновление сторонних программ
Если программа установлена не через систему пакетов и имеет символическую ссылку (которая обычно должна указывать на каталог /usr/local/bin), то сначала удаляем её(на примере ЯП Go):
```
sudo rm /usr/local/bin/go
```
а затем и сам каталог, в котором установлена программа (на примере того же Go):
```
sudo rm -rf /opt/go
```
Затем делаем установку более свежей версии согласно руководству по установке программы (для примера выше - Go)
+ Удаление конфигурационных файлов
Тут речь конечно же идёт о конфигурационных файлов пакетов, которые установлены через систему управления пакетов.
Сначала посмотрим, есть ли такие пакеты:
```
aptitude search '~c'
```
И если есть и они вам не нужны, то жестоко грохнем:
```
sudo aptitude purge '~c'
```
При этом нужно понимать, что убьются все конфигурационные файлы, пакеты для которых не установлены.
+ Удаление пакетов
Удаление пакета без удаления их конфигурационных файлов:
```
sudo aptitude remove <имя_пакета>
```
где имя пакета вводится без угловых скобок. Например sudo aptitude remove atril
Полное удаление пакета, включая конфигурационные файлы:
```
sudo aptitude purge <имя_пакета>
```
где имя пакета вводится без угловых скобок. Например sudo aptitude purge atril
+ Просмотр и удаление потеряшек
Потеряшками(orphaned) называют пакеты, ссылки на которые в текущих подключенных репозиториях не существует. Сюда же, разумеется, будут относится пакеты в формате .deb, которые были скачаны и установлены с сайтов разработчиков. Команда для получения списка "потеряшек":
```
aptitude search '~i !~M ~o'
```
Если они не нужны, то их можно удалить как обычные пакеты(описано выше)
+ Проверка зависимостей пакетов
Иногда бывает так, что в результате предыдущей команды по поиску потеряшек возникает сомнение, можно ли удалять пакет (есть ли ОТ него зависимости)? Для этого используется команда:
```
aptitude search '~i ~D <имя_пакета>'
```
если результат вывода пуст, то от этого пакета другие пакеты не зависят.
Почему пакет был установлен (кто нуждается в этом пакете):
```
aptitude why <имя_пакета>
```
в результате выведется кратчайшая цепочка всех пакетов(установленных и нет) которым нужен этот пакет.
Почему пакет не может быть установлен (с кем конфликтует) показывает команда:
```
aptitude why-not <имя_пакета>
```
+ Просмотр ошибок
Для просмотра ошибок используется команда journalctl с параметрами. Просмотр ошибок за текущую загрузку:
```
sudo journalctl -p 3 -xb 
```
Просмотр ошибок за предыдущую загрузку. В основном используется, если компьютер неожиданно перезагрузился, зависис и т.д.:
```
sudo journalctl -p 3 -xb -1
```
Т.к. логи со временем достаточно сильно забьют систему, то сначала посмотрим сколько места они занимают:
```
sudo journalctl --disk-usage
```
а затем и ограничим аппетиты журналов. Для этого подкорректируем настройки journalctl. Основные конфиги трогать не рекомендуется, а рекомендуется применять так называемый капельный (Drop-in) подход.
Создадим каталог, который будет хранить переопределение:
```
sudo mkdir -p /etc/systemd/journald.conf.d
```
Затем создадим конфигурационный файл, который будет переопределять необходимые нам настройки:
```
sudo nano /etc/systemd/journald.conf.d/99-persistent-debug.conf 
```
Вносим изменения
[Journal]
Storage=persistent
SyncIntervalSec=5s
SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=1month
RateLimitIntervalSec=0
RateLimitBurst=0

Перезапускаем службу:
```
sudo systemctl restart systemd-journald 
```
Проверим, что настройки применились:
```
systemd-analyze cat-config systemd/journald.conf
```
В выводе должны быть новые значения
+ Просмотр ошибок Xfce
Ошибки Xfce пишутся в файл ~/.xsession-errors. Теоретически, там ошибок быть не должно. Практически там всегда что-то есть. Поэтому смотрим специфические ошибки:
```
cat ~/.xsession-errors | grep -i -E 'error|crit|fail|warn|oom'
```
+ Долгая загрузка системы
Для того, чтобы определить причину долгой загрузки существует несколько утилит.
Общее время загрузки:
```
systemd-analyze time
```
Список служб, отсортированный по времени загрузки:
```
systemd-analyze blame
```
Наибольшее время задержки с разбиением по зависимым службам:
```
systemd-analyze critical-chain
```
Команда для низкоуровневой диагностики в реальном времени. dmesg показывает, что "видит" и о чём "думает" ядро с момента запуска системы:
```
sudo dmesg -H
```
+ Фиксация версии пакета
Иногда бывает нужно зафиксировать текущую версию пакета, чтобы она не обновлялась при использовании команды sudo aptitude safe-upgrade.
Для этого существует команда sudo apt-mark hold <имя_пакета>.
Например, зафиксируем пакет Mater PDF Editor в его текущей версии:
```
sudo apt-mark hold master-pdf-editor-5
```
Просмотр списка зафиксированных пакетов:
```
apt-mark showhold
```
Для того, чтобы исключить пакет из списка зафиксированных и позволить ему обновляться вместе с системой, нужно написать команду sudo apt-mark unhold <имя_пакета>. Например:
```
sudo apt-mark unhold master-pdf-editor-5 
```
+ Включение и отключение репозиториев для обновления
Иногда бывает нужно отключить обновление из некоторых репозиториев(в основном это нужно перед обновлением мажорной версии Debian) при использовании команды sudo aptitude update. Для этого в описание репозитория нужно добавить параметр Enabled: no.
На примере Double Commander:
```
sudo nano /etc/apt/sources.list.d/doublecmd-stable.sources
```
Types: deb
URIs: https://download.opensuse.org/repositor … Debian_13/
Suites: /
Components:
Signed-By: /usr/share/keyrings/double-archive-keyring.gpg
Enabled: no

В дальнейшем, если нужно будет включить репозиторий, то можно либо поставить параметр Enabled: yes либо вообще его удалить.
Посмотреть список имён файлов отключенных репозиториев, можно командой:
```
sudo grep -l "Enabled: no" /etc/apt/sources.list.d/*.sources
```
+ Удаление репозиториев
На случай, если отключение репозитория не устраивает, а хочется полностью удалить его описание из системы, то нужно удалить ключ и файл описания самого репозитория.
На примере того же Double Commander:
Удаляем ключ:
```
sudo rm /usr/share/keyrings/double-archive-keyring.gpg
```
Удаляем файл с описанием репозитория:
```
sudo rm /etc/apt/sources.list.d/doublecmd-stable.sources
```
Сами установленные пакеты при этом не удаляются из системы.
+ Просмотр загрузки видеокарты nvtop
Вместо кучи различных утилит для различных видеокарт (а-ля nvidia-smi или radeontop) можно использовать универсальную утилиту просмотре загрузки видеокарт и их памяти - nvtop. Она работает с GPU от NVIDIA, AMD и Intel.
Установка:
```
sudo aptitude install nvtop
```
Запуск:
```
nvtop
```
Выход из утилиты - нажать клавишу Q

Одноразовый тюнинг

+ Настройка ZSWAP ZRAM
Для начала немного теории, что такое ZSWAP/ZRAM.
Если RAM это ОЗУ, то ZRAM это динамически выделяемый кусок памяти из ОЗУ, куда данные (память приложений) выгружаются в сжатом виде. В среднем можно ожидать коэффициент сжатия около 2:1, но он может варьироваться. Т.е. каждые 10 мб данных из ОЗУ превращаются в 5Мб в ZRAM. Однако при этом идёт нагрузка на процессор. Из дополнительных плюсов то, что ресурс SSD расходуется медленнее, т.к. к нему происходит меньше обращений. Но это не самоцель.
На данный момент существует две частично перекрывающие друг друга технологии - ZSWAP и ZRAM. Общего у них одно - они обе умеют сжимать выгружаемые из ОЗУ данные.
Разница в том, что zswap не может существовать без физического файла/раздела подкачки. Если при запуске системы файл подкачки не будет найден, то zswap просто не включится, а в логах будут ошибки. zram вполне спокойно себе может существовать без файла/раздела подкачки.
Если zram используется вместе с дисковым swap (даже с меньшим приоритетом), при переполнении zram ядро может начать выгружать на диск активные страницы, оставляя в быстром zram давно неиспользуемые. Это явление называется LRU-инверсией и может резко замедлить систему. Поэтому при активном использовании дискового swap (особенно на малом ОЗУ) более безопасен zswap.
Так что же выбрать? Однозначного ответа нет, всё зависит от задач. А точнее от объёма ОЗУ в системе, насколько сильно она используется и количества ядер процессора. При наличии 16Гб+ ОЗУ выбирать zram и отключать swap-раздел. Остальное - в серой зоне и зависит исключительно от того, насколько нужен будет swap-раздел.
Если процессор слабый (2 ядра) и приложения постоянно требуют 150% от объёма ОЗУ и больше, то лучшим выбором будет zswap, чтобы не упала система от нехватки памяти.
Алгоритмы сжатия одни и те же:
lzo - самый слабый по сжатию алгоритм, но и самый быстрый. Используется по-умолчанию.
lz4 - сжимает быстрее, но и больше нагружает процессор. Рекомендуется для слабых машин с объёмом ОЗУ 4Гб.
zstd - современный стандарт. Рекомендуется для машин с 4+ ядрами и объёмом ОЗУ 8Гб+
+ Настройка zswap
Технология сжатия ненужных страниц в кеше перед выгрузкой их на диск реализована в ядре. Поэтому для её активации нужно передать ядру несколько параметров. zswap инициализируется раньше, чем загружаются модули алгоритмов сжатия. Поэтому нужно будет переключить алгоритм сжатия после загрузки с помощью настройки.
Редактируем конфигурационный файла /etc/default/grub:
sudo nano /etc/default/grub
находим строчку, начинающуюся с GRUB_CMDLINE_LINUX_DEFAULT= и дописываем в конец через пробел два параметра zswap.enabled=1 zswap.max_pool_percent=15. Получится что-то типа:
GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled=1 zswap.max_pool_percent=15"
где параметры указаны для 4Гб ОЗУ
zswap.enabled=1 — включает механизм.
zswap.max_pool_percent=15 — ограничивает максимальный размер кэша zswap до 15% от оперативной памяти (около ~600 МБ). Для 8Гб будет 20% и для 16Гб будет 25%
Применяем настройки к ядру:
sudo update-grub
Загружаем один из модулей сжатия, который будет нужен (для алгоритма сжатия по-умолчанию lzo ничего из нижеперечисленного делать не нужно!).
Для lz4 это команда:
echo "lz4" | sudo tee /etc/modules-load.d/lz4.conf
Для zstd это команда:
echo "zstd" | sudo tee /etc/modules-load.d/zstd.conf
Создаём сервис, который при загрузке будет переключать алгоритм zswap
sudo nano /etc/systemd/system/zswap.service
со следующим содержимым:
[Unit] Description=Set Zswap compressor After=systemd-modules-load.service local-fs.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/bash -c 'echo lz4 > /sys/module/zswap/parameters/compressor' [Install] WantedBy=multi-user.target
где, "echo lz4" активирует алгоритм lz4. Если нужен алгоритм zstd, то строчку
ExecStart=/bin/bash -c 'echo lz4 > /sys/module/zswap/parameters/compressor'
заменить на
ExecStart=/bin/bash -c 'echo zstd > /sys/module/zswap/parameters/compressor'
Добавляем сервис в автозагрузку
sudo systemctl enable --now zswap.service
и перегружаемся для применения настроек.
Проверяем что zswap активировался:
cat /sys/module/zswap/parameters/enabled
Проверяем, что zswap успешно загрузился:
sudo dmesg | grep zswap
Проверяем настройку алгоритма сжатия
cat /sys/module/zswap/parameters/compressor
Уменьшаем обращение к swap:
echo 'vm.swappiness=30' | sudo tee /etc/sysctl.d/99-swappiness.conf
+ Настройка zram
Фактически для начальной настройки достаточно двух параметров - это алгоритм сжатия, от которого зависит нагрузка на процессор и размер ZRAM. Размер ZRAM - это первоначальный (несжатый) объём из ОЗУ, который нужно переместить в ZRAM для того, чтобы ZRAM считался полностью заполненным (те самые 10Мб из примера выше). Дальше уже идёт тюнинг для гиков, который нам не нужен. Гибернация при этом работать не будет.
Для 2 ядерных процессоров используется алгоритм сжатия lz4, для остальных zstd.
Теперь примерные соответствия объёма ОЗУ и ZRAM:
16Гб - 12288Мб
32Гб - 16384Мб
64Гб+ - 24576Мб
Для 32 Гб и выше ZRAM служит скорее страховкой, если вдруг памяти станет не хватать.
Итак, ставим пакет с ZRAM:
sudo aptitude install systemd-zram-generator
Создаём конфиг для него:
sudo nano /etc/systemd/zram-generator.conf
со следующим содержимым:
[zram0] zram-size = 24576 compression-algorithm = zstd swap-priority = 100 fs-type = swap
Где параметры zram-size и compression-algorithm подставляем для своих значений из данных выше.
zram-size= 24576 - Задаёт размер ZRAM-устройства в мегабайтах (24 ГБ). Это первоначальный (несжатый) объём из ОЗУ, который нужно переместить в ZRAM для того, чтобы ZRAM считался полностью заполненным.
compression-algorithm = zstd - Выбирает алгоритм сжатия. zstd - это современный стандарт, который даёт отличный баланс между степенью сжатия и скоростью работы.lz4 - для маломощных машин.
Список поддерживаемых алгоритмов и текущий алгоритм можно посмотреть командой:
cat /sys/block/zram0/comp_algorithm
swap-priority = 100 - Устанавливает высокий приоритет для этого свопа. Это гарантирует, что система будет использовать ZRAM в первую очередь, а не дисковой файл подкачки, который можно отключить для ОЗУ 16Гб и больше.
fs-type = swap - Указывает, что устройство будет использоваться как пространство подкачки.
Заставляем systemd перечитать конфигурации, чтобы создать юниты:
sudo systemctl daemon-reload
Смотрим, что диск создался:
sudo zramctl
где:
DATA - это несжатые данные
COMPR - сжатые данные
TOTAL - Общий объём выделенной физической памяти для ZRAM (обычно чуть больше COMPR)
Проверяем, что он появился в списке свап-файлов:
sudo swapon --show
Проверка приоритетов при нескольких swap:
cat /proc/swaps
Убедиться, что приоритет ZRAM выше, чем у обычного файла подкачки (значение столбца Priority)
Проверяем как система с ZRAM будет себя вести под нагрузкой. Для этого используем утилиту stress:
stress --vm 1 --vm-bytes 128G --timeout 60s
где
--vm 1 - запускает один процесс, который будет заниматься выделением памяти
--vm-bytes 128G - указывает размер блока памяти, который процесс пытается выделить. У меня это 128Гб, а вы указывайте свой.
--timeout 60s - время, через которое процесс завершится
В то время, пока утилита stress работает, не должно быть никаких лагов и фризов с интерфейсом.
Отключаем все свопы(после перезагрузки создастся ZRAM):
sudo swapoff -a
Отключаем свап файл в /etc/fstab:
sudo nano /etc/fstab
Закомментировать или удалить строчку, начинающуюся на /swapfile
Удаляем сам своп-файл (если он в виде своп-файла):
sudo rm /swapfile
Или удаляем раздел с диска с помощью утилиты GParted
Удаляем файл /etc/initramfs-tools/conf.d/resume, который указывает initramfs, на каком устройстве подкачки (swap) сохранён образ оперативной памяти для гибернации:

sudo rm /etc/initramfs-tools/conf.d/resume
Снижаем обращение к своп-файлу:
echo 'vm.swappiness=1' | sudo tee /etc/sysctl.d/99-swappiness.conf
Перезагружаемся. Проверка командами, которые описаны выше.
+ Установка композитора Picom. Опционально
Стандартный композитор xfwm4 (он отвечает за тени и прозрачность) может создавать дополнительную нагрузку и задержку даже в полноэкранном режиме, хотя визуальные эффекты там не нужны. Если вы хотите сохранить их вне полноэкранного режима, можно установить сторонний композитор Picom, который умеет автоматически отключаться в полноэкранных приложениях. Если эффекты у вас отключены, то устанавливать Picom не обязательно.
Устанавливаем пакет picom:
```
sudo aptitude install picom
```
Отключаем встроенный композитинг xfwm4 (вместо команды можно просто снять галочку Диспетчер настроек->Диспетчер окон(дополнительно)->Эффекты->Включить эффекты):
```
xfconf-query -c xfwm4 -p /general/use_compositing -s false
```
Эффекты исчезнут сразу, перезагрузка не требуется: пропадут все тени, прозрачность и т.д.
Настраиваем Picom. Сначала создадим каталог, где будет размещаться конфигурационный файл picom.conf:
```
mkdir -p ~/.config/picom
```
Создаём файл конфигурации для picom:
```
nano ~/.config/picom/picom.conf
```
со следующим содержимым:
```
backend = "glx";
vsync = true;
unredir-if-possible = true;
```
где
backend = "glx"; — использовать OpenGL для ускорения (вместо xrandr)
vsync = true; — включить вертикальную синхронизацию для устранения разрывов изображения.
unredir-if-possible = true; — автоматически отключать Picom в полноэкранных приложениях (играх) для лучшей производительности.
Можно добавить к этому типовые настройки для теней и прозрачности:
```
shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;

inactive-opacity = 1.0;
frame-opacity = 1.0;

fading = true;
fade-in-step = 0.03;
fade-out-step = 0.03;
```
+ Вернуть всё как было
Удалить процесс picom:
killall picom
Включить Эффекты (композитинг):
xfconf-query -c xfwm4 -p /general/use_compositing -s true
Удалить пакет picom и конфигурационные файлы:
sudo aptitude purge picom

+ AMD

У процессора AMD есть так называемые "золотые ядра". Это ядра, которые производитель отобрал при тестировании кристалла как способные работать на наибольшей частоте при лучшем(меньшем) напряжении.
У Ryzen 5000 (Zen 3) таких ядер обычно два.
Linux использует эту информацию, чтобы планировщик задач чаще назначал однопоточные нагрузки именно на эти ядра. Всё происходит автоматически и обычно не требует вмешательства. Однако процессоры AMD поддерживают небольшой разгон и возможность снижения напряжения на отдельных ядрах, тем самым снижая температуру пакета в целом и повышая бурст. Я не буду тут рассматривать настройки PBO и Curve Optimizer, а просто покажу как узнать свои "золотые ядра".
Для этого нам понадобится скрипт amd-core-ranker.sh. К сожалению, он точно работает лишь для 8 ядерных процессоров.
Создаём файл:

nano amd-core-ranker.sh

со следующим содержимым:

#!/bin/bash

# A script to query, map, and display AMD preferred core rankings
# using the modern amd-pstate driver's sysfs interface.

# --- Prerequisites Check ---
if ! command -v lscpu &> /dev/null; then
    echo "Error: 'lscpu' command not found. Please install the 'util-linux' package."
    exit 1
fi

RANKING_FILE="amd_pstate_prefcore_ranking"
if [ ! -f "/sys/devices/system/cpu/cpu0/cpufreq/${RANKING_FILE}" ]; then
    echo "Error: AMD P-State ranking file not found."
    echo "This script is designed for systems using the amd-pstate driver"
    echo "with a kernel that exposes '/sys/.../cpufreq/${RANKING_FILE}'."
    exit 1
fi

# --- Data Collection ---

# Step 1: Create a mapping of [Logical CPU] -> Physical Core
declare -A logical_to_physical
while IFS=, read -r cpu core; do
    # Skip comment lines from lscpu's parseable output
    [[ "$cpu" =~ ^# ]] && continue
    if [[ -n "$cpu" && -n "$core" ]]; then
        logical_to_physical["$cpu"]="$core"
    fi
done < <(lscpu --parse=CPU,CORE)

# Check if the mapping was successful
if [ ${#logical_to_physical[@]} -eq 0 ]; then
    echo "Error: Failed to create logical-to-physical CPU map."
    echo "There might be an issue with the 'lscpu --parse' command on your system."
    exit 1
fi

# Step 2: Aggregate data per physical core
declare -A core_ranks
declare -A core_logicals
max_rank=0

for cpu_dir in /sys/devices/system/cpu/cpu[0-9]*; do
    logical_cpu_id=$(basename "$cpu_dir" | tr -d 'cpu')
    physical_core_id=${logical_to_physical[$logical_cpu_id]}

    # Ensure physical_core_id is not empty before proceeding
    if [ -z "$physical_core_id" ]; then continue; fi

    ranking_path="$cpu_dir/cpufreq/${RANKING_FILE}"
    if [ -f "$ranking_path" ]; then
        rank=$(cat "$ranking_path")

        # Store the rank for the physical core
        core_ranks["$physical_core_id"]=$rank

        # Keep track of the maximum rank found for tier calculation
        (( rank > max_rank )) && max_rank=$rank

        # Append the logical CPU to its physical core's list
        if [ -z "${core_logicals[$physical_core_id]}" ]; then
            core_logicals["$physical_core_id"]="$logical_cpu_id"
        else
            # Ensure logical CPUs are sorted numerically for consistent output
            core_logicals["$physical_core_id"]=$(echo -e "${core_logicals[$physical_core_id]}\n$logical_cpu_id" | sort -n | tr '\n' ',' | sed 's/,$//')
        fi
    fi
done

# --- Data Presentation ---

# Step 3: Print header
printf "%-6s %-12s %-12s %-6s %-10s %s\n" "Rank" "Phys. Core" "Logical CPUs" "CCD" "Value" "Quality"
printf "%-6s %-12s %-12s %-6s %-10s %s\n" "------" "------------" "------------" "------" "----------" "----------"

# Step 4: Create sorted output and print it
rank_counter=0
# Loop through physical core IDs, get their ranks, and sort by rank (descending)
# Then pipe to the final formatting stage
for core_id in "${!core_ranks[@]}"; do
    echo "${core_ranks[$core_id]} $core_id ${core_logicals[$core_id]}"
done | sort -k1 -nr | while read -r rank core logicals; do

    ((rank_counter++))

    # Determine CCD (assumes 16-core / 2-CCD consumer layout like 5950X/7950X)
    ccd="-"
    if (( core >= 0 && core <= 7 )); then ccd="0"; fi
    if (( core >= 8 && core <= 15 )); then ccd="1"; fi

    # Determine Quality Tier based on performance relative to the best core
    # Using integer arithmetic for portability
    quality="Standard"
    if (( max_rank > 0 )); then # Avoid division by zero
        if (( rank * 100 >= max_rank * 98 )); then
            quality="Gold Tier"
        elif (( rank * 100 >= max_rank * 95 )); then
            quality="Silver Tier"
        elif (( rank * 100 >= max_rank * 90 )); then
            quality="Bronze Tier"
        fi
    fi

    # Print the formatted line
    printf "%-6s %-12s %-12s %-6s %-10s %s\n" "#$rank_counter" "$core" "$logicals" "$ccd" "$rank" "$quality"
done

Делаем скрипт исполняемым:

chmod +x amd-core-ranker.sh

и запускаем:

./amd-core-ranker.sh

У меня получилось, что "золотые ядра" это 1 и 7 (у них наибольшее количество "попугаев" - 196):

Rank   Phys. Core   Logical CPUs CCD    Value      Quality
------ ------------ ------------ ------ ---------- ----------
#1     7            7,15         0      196        Gold Tier
#2     1            1,9          0      196        Gold Tier
#3     0            0,8          0      191        Silver Tier
#4     2            2,10         0      186        Bronze Tier
#5     5            5,13         0      181        Bronze Tier
#6     6            6,14         0      176        Standard
#7     3            3,11         0      171        Standard
#8     4            4,12         0      166        Standard

В дальнейшем, при настройке Curve Optimizer на "золотые ядра" обычно подают меньшее снижение напряжения (условно -20 против -25 для остальных).

+ Стресс тест системы
Для тестирования устойчивости системы и системы охлаждения, нужно запустить стресс тест. Но для начала нужно установить инструменты.
Установка утилиты тестирования:
```
sudo aptitude install stress-ng
```
Установка пакета для получения информации о CPU:
```
sudo aptitude install linux-cpupower
```
Перед тестированием запустить на разных вкладках следующие мониторы.
Просмотр ошибок WHEA в реальном времени:
```
sudo dmesg -w | grep -iE "mce|whea|hardware error|correctable|uncorrectable" 
```
Мониторинг частоты и мощности процессора в реальном времени:
```
sudo turbostat --quiet --show Core,CPU,Bzy_MHz,PkgWatt --interval 5 
```
Запуск мощного стресс теста (тоже на своей вкладке терминала):
```
stress-ng --cpu 0 --cpu-method matrixprod --cache 4 --cache-enable-all --vm 2 --vm-bytes 4G --timeout 30m --metrics-brief
```

Linux Forum — Настройка Debian 13. Одноразовый тюнинг и обслуживание системы

Настройка Debian 13. Одноразовый тюнинг и обслуживание системы