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

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