Различия

Показаны различия между двумя версиями страницы.

--- nvme-linux-smart-health [2026/02/27 00:48] – admin
+++ nvme-linux-smart-health [2026/02/27 01:04] (текущий) – admin
@@ Строка 139: / Строка 139: @@
 ====NVMe error log: быстрый способ понять «что именно болит»====
-Даже когда critical_warning ещё нулевой, в error log могут появляться записи. Снимок error log:
+Даже когда **critical_warning** ещё нулевой, в error log могут появляться записи. Снимок error log:
 <code bash>
 nvme error-log /dev/nvme0
 </code>
 Если хотите увидеть больше записей:
@@ Строка 148: / Строка 150: @@
 nvme error-log /dev/nvme0 -e 256
 </code>
 На что смотреть в первую очередь:
@@ Строка 154: / Строка 157: @@
 * появление ошибок после обновления ядра или изменения прошивки/BIOS.
-> Если error log растёт, но media_errors остаётся нулём — это ещё не приговор. Но это повод проверить термальный режим, стабильность PCIe, версию прошивки и…
+> Если error log растёт, но **media_errors** остаётся нулём — это ещё не приговор. Но это повод проверить термальный режим, стабильность PCIe, версию прошивки и паттерн нагрузки.
+====Self‑test для NVMe: когда он полезен и как запускать====
+Многие NVMe поддерживают self‑test. Наличие и поведение зависят от модели и платформы, поэтому проверяйте результат и влияние на производительность в тестовом окне.
+Просмотр self‑test log:
+<code bash>
+nvme self-test-log /dev/nvme0
+</code>
+Запуск короткого теста (если поддерживается):
+<code bash>
+nvme device-self-test /dev/nvme0 --self-test-code=1
+</code>
+Запуск расширенного теста:
+<code bash>
+nvme device-self-test /dev/nvme0 --self-test-code=2
+</code>
+====Температура и троттлинг: скрытая причина «странных тормозов»====
+NVMe чувствительны к перегреву: при достижении порогов контроллер включает thermal throttling, и вы получаете всплески latency даже без явных ошибок чтения/записи.
+Базовая проверка — снова SMART/health:
+<code bash>
+nvme smart-log /dev/nvme0
+</code>
+Если температура регулярно высокая:
+* на «железе» проверьте airflow, радиатор и расположение рядом с горячими компонентами;
+* оцените, не ухудшился ли обдув после обслуживания/замены комплектующих;
+* в виртуальной среде зафиксируйте симптомы и планируйте миграцию нагрузки до того, как начнутся таймауты.
+====Практический чек‑лист алертов: что мониторить постоянно====
+Если нужна простая схема «без переусложнения», для каждого NVMe диска обычно достаточно следующих условий:
+* **critical_warning ≠ 0** — критический алерт;
+* **media_errors** растёт — критический алерт;
+* **available_spare ≤ available_spare_threshold** — критический алерт;
+* **percentage_used** — warning на вашем пороге (часто 80–90), critical при 100+;
+* **Температура** — warning/critical по порогам, которые соответствуют вашей модели и условиям (перегрев — всегда расследование);
+* **num_err_log_entries** растёт — warning, далее сверяйте с kernel log и latency.
+=====Сбор метрик одной командой (удобно для cron)=====
+Чтобы ловить тренды, полезно хранить историю. Простейший подход — регулярный снимок SMART/health в файл/лог (раз в 5–15 минут, по ситуации):
+<code bash>
+date -Is; nvme smart-log /dev/nvme0; echo
+</code>
+Альтернатива через smartmontools:
+<code bash>
+date -Is; smartctl -a /dev/nvme0; echo
+</code>
+Дальше можно парсить конкретные строки (grep/awk) или подключить агент мониторинга, который собирает метрики структурированно.
+====Типовые сценарии и быстрые решения====
+=====Сценарий 1: critical warning появился внезапно=====
+* Сразу снимите **nvme smart-log** и **nvme error-log**.
+* Проверьте, не включился ли read‑only режим (бит 3 в **critical_warning** или сообщения в kernel log).
+* Проверьте актуальность бэкапов и план миграции.
+* Если есть RAID/репликация — инициируйте замену диска без ожидания «вторичных» симптомов.
+=====Сценарий 2: растут media errors, но сервис «не падает»=====
+* Считайте это деградацией и практическим *predictive failure*.
+* Снимите динамику: значение сейчас и повторно через 1–2 часа (или быстрее под нагрузкой).
+* Проверьте ФС по вашим регламентам, но помните: ФС не «вылечит» носитель.
+* Планируйте замену/миграцию данных.
+=====Сценарий 3: тормоза и timeouts, но media errors = 0=====
+* Проверьте температуру и косвенные признаки троттлинга.
+* Проверьте kernel log на AER/PCIe ошибки.
+* Снимите **nvme error-log** и посмотрите динамику **num_err_log_entries**.
+* Если доступно в рамках change‑процесса — обновите прошивку/ядро и повторите наблюдение.
+====Частые вопросы====
+=====Можно ли полностью доверять percentage_used?=====
+Это хороший индикатор направления и тренда, но не абсолютная гарантия. У разных моделей отличаются алгоритмы оценки ресурса. Используйте **percentage_used** для планирования замен и прогнозирования, но не как единственный критерий «диск точно жив/точно мёртв».
+=====Нормально ли, что num_err_log_entries не ноль?=====
+Иногда да: единичные записи могли появиться из‑за редких событий (например, reset при инициализации). Ненормально — когда счётчик стабильно растёт, особенно вместе с timeout в ядре, деградацией latency или ненулевым **critical_warning**.
+=====Чем полезен nvme-cli, если уже есть smartctl?=====
+**smartctl** удобен для унификации, но **nvme-cli** чаще даёт более «нативный» доступ к NVMe‑логам и диагностике (error log, self‑test log, идентификаторы контроллера/namespace). Для расследований это обычно быстрее и информативнее.
+====Итог====
+Базовый мониторинг NVMe в Linux строится вокруг SMART/health (**nvme smart-log**), счётчиков **media_errors** и **critical_warning**, плюс корреляции с kernel log. Храните историю, следите за трендами и не игнорируйте ранние сигналы: NVMe может долго выглядеть «почти нормально», а затем быстро перейти в состояние, где восстановление становится дороже.