Percentage Used SSD уехал за год: найти write amplification, не купить диск наугад

Короткий ответ

SSD умирает от записей, не от «лет в стойке». Снимите nvme smart-log / SMART wear, переведите Total Data Written в TB и сравните с TBW в datasheet. Если за год съели ресурс, который сулили на пять — ищите write amplification: sync=always на ZFS, база с redo на том же NVMe, snapshots+CoW, отсутствие TRIM/unmap, RAID 5 на SSD, поиск Windows на системном томе, thin без discard. Снизьте лишнюю запись, замену планируйте до 100% used и режима read-only.

Не лечится «дефрагментацией SSD» и не лечится выключением SMART.

Симптомы и как отличить

Типичная картина:

• TrueNAS: SSD в пуле tank wear 40% за 8 месяцев;
• Windows SQL01: C: на NVMe, percentage_used 70%, база на том же диске;
• RAID-контроллер Predictive на SSD при низком Media Wearout.

Возможные причины

1. Журнал СУБД + fsync на каждом коммите на том же SSD, что данные.
2. ZFS sync=always или slog на том же устройстве, что data.
3. Снимки, клоны, репликация — каждое изменение пишет новые блоки.
4. Нет TRIM: гость Windows на iSCSI/VHDX без unmap, Linux без fstrim.
5. RAID 5/6 на SSD: parity write penalty.
6. Swap, systemd journal, контейнеры overlay на том же NVMe.
7. Antivirus full scan с перезаписью, Windows Search на файловом шаре.
8. Перезапись «почти полного» диска (мало свободных блоков для GC).

Диагностика

1. Цифры износа

nvme smart-log /dev/nvme0n1
smartctl -a /dev/disk/by-id/nvme-eui.0000000000000001

Запишите data_units_written (обычно ×512×1000 байт — смотрите NVMe spec в man nvme), percentage_used, available_spare. Дата ввода в эксплуатацию.

Windows:

Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List

Поля Wear, WriteLatency, ReadLatency — ориентир, не замена nvme-cli.

2. Кто пишет сейчас

Ubuntu:

iostat -dx 5 6
pidstat -d 5 6

TrueNAS: Reporting → Disk, плюс zpool iostat tank 5. Dataset с высоким write.

Windows:

Get-Counter '\PhysicalDisk(*)\Disk Writes/sec'

Resource Monitor → Disk: sqlservr, vssvc, searchindexer.

3. ZFS

zfs get sync,logbias,compression,recordsize tank
zfs get sync tank/sql
zpool status tank

sync=always на широком dataset — красный флаг. SLOG на том же NVMe, что data, удваивает удары.

4. TRIM / unmap

lsblk -D
systemctl status fstrim.timer

Windows NTFS: fsutil behavior query DisableDeleteNotify (0 = TRIM включён). iSCSI: unmap на томе и поддержка target (TrueNAS zvol).

5. RAID

Hardware RAID 5 на SSD: каждая запись приложения = несколько записей NAND. Для логов — RAID 1/10. Смотрите vd0 уровень.

Решение

Сценарий A. Лишний sync / slog

На Ubuntu ZFS: верните sync=standard там, где нет требования синхронной семантики. Вынесите slog на отдельный PLP-накопитель или уберите slog, если он на том же SSD. Не путайте с sync=disabled на учёте — это уже про потерю последних транзакций при power loss.

Сценарий B. Нет discard

Включите fstrim.timer на файловых томах SSD. Для thin/iSCSI — unmap в госте и на target. Это снижает GC, не «чинит» уже сожжённый TBW.

Сценарий C. Всё пишет в один NVMe

Разнесите: OS, slog/journal, data. SQL log на отдельный RAID 1 SSD. Снимки с retention, не «каждые 5 минут навсегда» — см. снимки как источник CoW-записи.

Сценарий D. Износ уже 80%+

Замена диска по процедуре RAID/ZFS до read-only firmware. Backup. Не ждите 100%.

Сценарий E. RAID 5 SSD под случайную запись

Плановая миграция на RAID 10. Это ёмкость vs жизнь дисков.

Отдельно посчитайте запись гипервизора: каждый snapshot VM, CBT reset и antivirus «полный диск» бьют в guest и затем в SSD под vd0 или zvol. На SQL01 включённый Query Store плюс бесконечный TRACE в файл на том же NVMe, что data, даёт характерный график: ровный высокий write без роста размера БД. Это write amp приложения, не «плохой Samsung».

Проверьте, нет ли двойного журналирования: ZFS sync=always и СУБД с synchronous_commit и RAID write-through без BBU. Три слоя fsync превращают 100 МБ полезной записи в кратный поток NAND. Снимите один слой осознанно, не все сразу в пятницу.

Для RAID-контроллера на SSD выключите patrol read с агрессивным расписанием на том же окне, что backup: patrol — это чтение, но на некоторых прошивках сопровождается verify-записью. Документируйте DWPD купленной модели в таблице дисков стойки, иначе через год никто не вспомнит, что стоял «архивный» QLC.

Как проверить, что проблема устранена

Неделя: data_units_written прирост упал соразмерно простойке лишнего writer. percentage_used не прыгает на 1% в сутки. iostat пишет меньше на этом device. TRIM: lsblk -D DISC-GRAN не нули, fstrim проходит без I/O error.

Если не помогло

• Write amp высокий при пустом диске: firmware, заполните не 100%, проверьте queue/scheduler.
• Гости на NAS iSCSI без unmap: чините initiator, не только TrueNAS.
• QLC «архивный» SSD под VM — смените класс диска, оптимизация ПО не догонит физику.
• Контроллер RAID кэширует и пишет большими полосами — иногда лучше, иногда parity хуже; мерите.

Профилактика

• Enterprise DWPD под журнал.
• Compression lz4 на ZFS (меньше байт на диск).
• Мониторинг percentage_used и host_bytes_written.
• Не складывать backup job и прод-БД на один потребительский NVMe.
• Свободные 10–20% на SSD для GC.
• Power-loss protection, если диск в RAID write-back.

FAQ

TBW в datasheet 600 ТБ, мы записали 200 за год. Это быстро?

Для 1 DWPD 2 ТБ диска 200 ТБ/год — норма. Для 0.3 DWPD клиентского — уже жёстко. Сравнивайте с классом, не с соседом.

Compression увеличивает износ?

Обычно снижает: меньше физических байт. Исключение — уже сжатые данные (видео) плюс CPU.

Стоит ли отключить снимки ради SSD?

Retention урезать — да, если CoW пишет терабайты в день. Полностью выключить — только осознав rollback.

RAID-контроллер Write Back бережёт SSD?

BBU кэш схлопывает мелкие записи — часто да. Без батареи WT + мелкий fsync — наоборот, хуже.

Можно ли сделать over-provisioning вручную?

Неразмеченный хвост на «голом» SSD иногда помогает GC. На члене RAID/ZFS не режьте VD «на глаз» в проде без плана миграции.