meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
wiki:nas:xigmanas:performance_tuning [2026/08/06 08:20] mchuswiki:nas:xigmanas:performance_tuning [2026/08/07 05:46] (current) mchus
Line 72: Line 72:
 Объём: ориентир "2× RAM" для legacy-железа; если нужен kernel core dump — своп не меньше объёма RAM. Объём: ориентир "2× RAM" для legacy-железа; если нужен kernel core dump — своп не меньше объёма RAM.
  
 +
 +===== ZFS: latency vs throughput =====
 +
 +На слабом CPU/дисках приоритет — короче худший случай задержки отклика, а не пиковая пропускная способность. Актуально при потоке мелких операций записи (много мелких файлов разом).
 +
 +^ Параметр ^ Дефолт ^ Значение ^ Требует ребута ^ Причина ^
 +| vfs.zfs.txg.timeout | 5с | 1с | Нет (live sysctl) | Короче окно накопления транзакционной группы — короче потенциальный стопор на её фиксации |
 +| vfs.zfs.dirty_data_max_percent | 10% от RAM | 5% | Да — read-only tunable, только через loader.conf | Меньше данных копится в памяти перед принудительным сбросом на диск |
 +| vfs.zfs.vdev.async_write_max_active | 10 | 3 | Нет (live sysctl) | Глубина очереди записи на vdev — на старых дисках без развитого NCQ большая очередь удлиняет отклик для операций, ожидающих за длинной очередью |
 +| vfs.zfs.vdev.sync_write_max_active | 10 | 3 | Нет (live sysctl) | То же для синхронных записей |
 +
 +<code>
 +# loader.conf / sysctl.conf
 +vfs.zfs.txg.timeout=1
 +vfs.zfs.dirty_data_max_percent=5
 +vfs.zfs.vdev.async_write_max_active=3
 +vfs.zfs.vdev.sync_write_max_active=3
 +</code>
 +
 +**arc_min — не трогать.** Может казаться логичным зафиксировать минимальный размер ARC, чтобы не проседал под нагрузкой, но на машине с и так туго рассчитанной памятью это забирает у ARC возможность сжаться и отдать память другим процессам именно тогда, когда она нужнее всего (при пиковой нагрузке). Оставлять `arc_min` неактивным — ARC пусть сам решает, когда сжаться.
 +
 +===== vnode-лимит при большом числе мелких файлов =====
 +
 +`kern.maxvnodes` — верхняя граница живых vnode в системе. Если по дереву датасета проходит live filesystem watcher (см. статью про тюнинг Syncthing — секция про fsWatcher/kqueue) или просто идёт операция над деревом с сотнями тысяч мелких файлов/директорий, число vnode может подступить к лимиту — система начинает агрессивно вытеснять vnode, что способно сериализовать файловые операции по всей системе, а не только у процесса-триггера.
 +
 +Диагностика: `sysctl kern.maxvnodes vfs.numvnodes` — если `numvnodes` устойчиво держится близко к `maxvnodes` во время нагрузки, лимит тесен. Поднять его — не панацея (каждый vnode — расход памяти ядра), но если основная причина нагрузки на дерево устранена на уровне приложения (например, отключением live-watcher), поднимать лимит обычно не требуется.
  
 ===== Проверка: конфиг ≠ реальность ===== ===== Проверка: конфиг ≠ реальность =====
Line 98: Line 124:
 0 6  * * * root for d in ada0 ada1 ada2 ada3; do /usr/local/sbin/ataidle -A 127 /dev/$d; done 0 6  * * * root for d in ada0 ada1 ada2 ada3; do /usr/local/sbin/ataidle -A 127 /dev/$d; done
 </code> </code>
 +
 +===== Cron: подводные камни =====
 +
 +  * Задачи с интервалом вида `@300` (в отличие от задач с фиксированным временем `H:M`) отсчитываются **от момента старта демона cron**, а не от часов. После `service cron restart` расписание таких задач сдвигается — первый цикл наступит не сразу, а через полный интервал от рестарта.
 +  * Пустой узел `<job/>` в секции `//cron` конфига (пустая заготовка, которая может остаться в XML после операций через GUI) ломает страницу `System → Advanced → Cron`, как только реальных задач становится больше одной — список задач и кнопка добавления перестают отображаться. Лечится удалением пустого узла (`xml ed -d "//cron/job[not(*)]"`), сами задачи в `/etc/crontab` при этом продолжают работать штатно — ломается только рендер GUI.
 +  * После правки `config.xml` через `xmlstarlet` — обязательна верификация чтением значения обратно из файла **и** из живого `/etc/crontab`/`sysctl`, exit-код команды правки не гарантирует, что изменение реально применилось.
  
 ===== Параметры, оставленные без изменений ===== ===== Параметры, оставленные без изменений =====
Line 105: Line 137:
 | HDD standby timer | задаётся в **минутах**, не в секундах | при частом фоновом обращении к дискам (мониторинг раз в несколько минут) порог простоя физически не достигается | | HDD standby timer | задаётся в **минутах**, не в секундах | при частом фоновом обращении к дискам (мониторинг раз в несколько минут) порог простоя физически не достигается |
 | Power Mode CPU | adaptive | не проседает на всплесках нагрузки (в отличие от minimum), не расходует лишнее (в отличие от maximum) | | Power Mode CPU | adaptive | не проседает на всплесках нагрузки (в отличие от minimum), не расходует лишнее (в отличие от maximum) |
-