Transmission убивает ваш HDD. И ещё четыре вещи, которые стоит исправить в homelab
Есть такая медитативная практика у владельцев домашних серверов — смотреть на моргающий светодиод жёсткого диска и думать: «Это нормально? Или он прямо сейчас умирает?»
Спойлер: скорее всего не умирает. Но и нормального в этом мало.
Я разбирался с этим на своём домашнем сервере и выяснил несколько вещей, которые, думаю, будут полезны всем, у кого дома крутится NAS, медиасервер или просто какой-нибудь самодельный зоопарк из контейнеров.
Чтобы понимать контекст — вот на чём всё это крутится:
- Процессор: Intel Core i3-8100 @ 3.60 GHz, 4 ядра
- Память: 16 GB RAM
- ОС: Proxmox VE 9.1 (ядро 6.17.2-pve)
| Устройство | Модель | Объём | Тип | Наработка |
|---|
/dev/sda | Toshiba HDWT740 | 4 TB | HDD, 5400 rpm | 32 115 часов (~3.7 года) |
/dev/sdb | Apacer AS350 | 512 GB | SSD | 8 731 час |
/dev/sdc | WD WD20EFPX | 2 TB | HDD, 5400 rpm | 8 624 часа (~1 год) |
SSD — это системный диск Proxmox, на нём же живут все виртуальные диски контейнеров в LVM. Оба HDD — для данных: Toshiba под медиатеку и торренты, WD собран в ZFS-пул под будущие задачи.
Контейнеры (LXC): 15 штук в работе, ещё 9 остановлены. Среди активных — Plex, Transmission, Samba, Gitea, мониторинг на Prometheus+Grafana, Uptime Kuma, собственный видеостриминг, несколько самописных сервисов.
Вот примерно так выглядит pct list:
$ VMID Status Name$ 100 running plex.lan$ 101 running caddy.lan$ 103 running samba.lan$ 108 running monitoring$ 112 running transmission$ 113 running video-streaming$ 114 running gittea$ 117 running uptime-kuma$ ...и ещё семь
Типичный homelab — начинался с одного контейнера, а теперь это маленький дата-центр на подоконнике.
Первым делом нужно понять, кто именно не даёт диску покоя. Устанавливаем iotop и смотрим:
$ apt install iotop$ iotop -o
Флаг -o показывает только процессы с ненулевой активностью — без него экран превращается в бесконечный список спящих демонов. Смотрите на колонки DISK READ и DISK WRITE.
У меня картина была примерно такая:
$ Total DISK READ: 7.79 M/s | Total DISK WRITE: 93.93 K/s$ 14897 be/4 transmission 7.79 M/s 0.00 B/s transmission-daemon$ 1149 be/4 root 0.00 B/s 35.22 K/s pmxcfs [cfs_loop]$ 19649 be/4 node 0.00 B/s 25.44 K/s node server/server.js
7 мегабайт в секунду. Постоянно. Виновник — Transmission.
Если у вас крутится торрент-клиент с кучей завершённых раздач — поздравляю, вы нашли главного убийцу своего диска.
Вот как это работает: когда пир запрашивает у вас блок данных из торрента, Transmission идёт читать этот блок с диска. Если у вас 30 активных раздач и 200 пиров — диск получает 200 случайных запросов в секунду из разных мест разных файлов. Для HDD это как пытаться одновременно читать книгу, газету и инструкцию к холодильнику — голова диска (буквально) мечется по всей поверхности блина.
У меня в Transmission было открыто одновременно больше 70 файловых дескрипторов — то есть десятки торрентов раздавались параллельно. iostat показывал r_await на уровне 243 мс при норме < 10 мс. Это значит, что диск не успевал обрабатывать запросы.
Лечится тремя настройками в settings.json (путь зависит от установки, обычно /var/lib/transmission-daemon/info/settings.json).
Сначала обязательно остановите Transmission, иначе он перезапишет ваши изменения при выходе.
$ systemctl stop transmission-daemon
Затем открываем конфиг и меняем параметры:
1234567
{
"cache-size-mb": 128,
"seed-queue-enabled": true,
"seed-queue-size": 5,
"peer-limit-global": 80,
"peer-limit-per-torrent": 20
}
cache-size-mb — это сколько RAM Transmission использует под кэш блоков. Дефолтные 4 МБ — это как пытаться кэшировать Netflix на дискете. Поставьте 64–256 МБ в зависимости от того, сколько у вас памяти. Часто запрашиваемые блоки будут отдаваться из RAM, не тревожа диск.
seed-queue-enabled + seed-queue-size — включает очередь раздачи. Вместо того чтобы раздавать все 47 скачанных сезонов одновременно, Transmission будет держать активными только 5. Остальные стоят в очереди — диск читает последовательно, а не хаотично.
peer-limit-global — ограничение на количество пиров. 200 пиров одновременно это много для домашнего диска.
Запускаем обратно:
$ systemctl start transmission-daemon
Если Transmission крутится в Docker или LXC, настройки можно поменять через RPC вообще без перезапуска — это уже отдельная история.
По умолчанию Linux записывает время последнего обращения к каждому файлу при каждом чтении. То есть когда Plex стримит фильм — он не только читает данные, но и пишет на диск «этот файл читали в 21:34:17». Для HDD с медиафайлами это бессмысленные лишние записи.
Смотрим, как смонтирован ваш диск с медиа:
$ mount | grep /mnt/media$ # /dev/sda2 on /mnt/media type ext4 (rw,relatime)
Открываем /etc/fstab и добавляем noatime:
12345
# Было:
UUID=ваш-uuid /mnt/media ext4 defaults 0 2
# Стало:
UUID=ваш-uuid /mnt/media ext4 noatime,defaults 0 2
Применяем без перезагрузки:
$ mount -o remount /mnt/media$ mount | grep /mnt/media$ # /dev/sda2 on /mnt/media type ext4 (rw,noatime) ← вот оно
Жёсткие диски умирают не мгновенно. Обычно они сначала долго намекают — растёт количество переназначенных секторов, появляются ошибки чтения, температура начинает скакать. Всё это видно через SMART.
Моя Toshiba наработала 32 115 часов — это почти 3.7 года непрерывной работы. По статистике Backblaze именно в этом возрасте у дисков начинает заметно расти вероятность отказа. Без мониторинга я бы узнал о проблеме только когда диск перестал бы монтироваться.
Сначала проверим здоровье дисков вручную:
$ apt install smartmontools$ smartctl -H /dev/sda
$ SMART overall-health self-assessment test result: PASSED
Хорошо. Но это снимок прямо сейчас. Нам нужен постоянный мониторинг.
smartd — это демон, который следит за дисками в фоне и шлёт алерты. Он уже установлен вместе с smartmontools, просто настроен слабовато по умолчанию.
Открываем /etc/smartd.conf, убираем дефолтный DEVICESCAN и пишем конкретику:
123456789101112
# -a мониторить всё
# -o on автономная проверка каждые 4 часа
# -S on автосохранение атрибутов
# -s ... расписание: короткий тест каждую ночь в 02:00,
# длинный тест раз в неделю в 03:00
# -W 4,45,50 температурные пороги (изменение/инфо/критично)
# -C 197 алерт если появились Pending Sectors
# -U 198 алерт если появились Offline Uncorrectable
# -m root писать алерты в /var/mail/root
/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -W 4,45,50 -R 5 -C 197 -U 198 -m root -M daily
/dev/sdc -a -o on -S on -s (S/../.././02|L/../../7/04) -W 4,45,50 -R 5 -C 197 -U 198 -m root -M daily
Два диска — разные дни для длинного теста, чтобы не нагружали систему одновременно.
Перезапускаем и проверяем:
$ systemctl restart smartmontools$ systemctl status smartmontools
Посмотреть расписание тестов:
$ smartd --quit=showtests$ # Device: /dev/sda, will do test 1 of type S at Thu Jun 11 02:00:00$ # Device: /dev/sda, will do test 1 of type L at Sat Jun 13 03:00:00
Короткий тест (S) занимает пару минут. Длинный (L) — несколько часов, полное сканирование поверхности. Запускайте его ночью.
Письма летят в /var/mail/root. Читать их можно командой mail — но давайте честно, никто так не делает. Если хотите получать алерты на реальную почту или в Telegram — настройте msmtp:
$ apt install msmtp msmtp-mta
И пропишите SMTP в /etc/msmtprc — это уже отдельная тема, но гугл знает.
Если у вас есть ZFS-пул (а на Proxmox это не редкость), включите lz4-компрессию — особенно если пул ещё не заполнен:
$ zfs set compression=lz4 ваш_пул$ zfs get compression ваш_пул$ # NAME PROPERTY VALUE SOURCE$ # data compression lz4 local
lz4 работает практически без нагрузки на CPU, но заметно снижает количество записей на диск. На несжимаемых данных (видео, уже сжатые архивы) эффект минимальный, зато на всём остальном — логах, базах данных, конфигах — прирост ощутимый.
iotop -o — посмотрите, кто реально грузит диск прямо сейчас- Если есть Transmission — поднять
cache-size-mb до 128+, включить seed-queue noatime в fstab для разделов с медиаsmartctl -H /dev/sda — проверить здоровье всех HDD- Настроить
smartd с расписанием тестов и алертами smartctl -A /dev/sda — посмотреть Power_On_Hours. Больше 30 000 часов? Время думать о бэкапе.- Если есть ZFS — включить
compression=lz4
HDD не вечны, но с правильными настройками они живут заметно дольше и, что важно, умирают предсказуемо — а не внезапно в пятницу вечером.