Ресурс SSD: сколько TBW уйдёт на вашу нагрузку

MAATRIX

Вы выбираете SSD для сервера с базой данных или логами и видите в характеристиках «TBW: 600» или «TBW: 3600» — но не понимаете, много это или мало именно для вашей нагрузки. Производитель даёт паспортное число, а сколько вы реально пишете на диск в сутки — не говорит. Разберём, как посчитать свою нагрузку и сопоставить её с ресурсом конкретной модели, а не гадать на глаз.

Что такое TBW и почему это не маркетинговая цифра

TBW — Terabytes Written, суммарный объём данных, который производитель гарантирует записать на диск за весь срок службы до того, как ячейки флеш-памяти начнут массово вырабатывать ресурс. Часто указывается вместе с DWPD (Drive Writes Per Day) — по сути та же характеристика, выраженная как «сколько раз в сутки можно перезаписать весь объём диска в течение гарантийного срока».

Здесь принципиальная разница с HDD. У жёсткого диска механический износ — подшипники, головки, двигатель — связан со временем работы и числом обращений, но не напрямую с объёмом записанных байт: диск, который просто крутится, тоже стареет. У SSD физика другая: ячейка флеш-памяти выдерживает ограниченное число циклов программирования и стирания. Каждая запись — реальный расход этого ресурса. Диск, на который почти не пишут, почти не изнашивается, сколько бы лет он ни проработал. Диск с интенсивной записью может выработать ресурс за пару лет даже будучи физически исправным во всех остальных смыслах.

Поэтому TBW — не абстракция для сравнения в магазине, а параметр, отвечающий на вопрос «сколько проживёт этот диск при МОЕЙ нагрузке». Для десктопа TBW почти никогда не станет узким местом — счёт записи идёт на гигабайты в день. Для сервера с базой данных, где WAL и логи пишутся постоянно, счёт идёт на десятки-сотни гигабайт в сутки — и тогда паспортный ресурс превращается из формальности в срок годности, который стоит посчитать заранее. Как физически стареет флеш-память на уровне ячеек — подробнее в статье про wear leveling.

Шаг 1: замерьте реальный объём записи

Прежде чем сравнивать что-либо с паспортным TBW, нужно знать не теоретическую, а фактическую нагрузку записи. Два рабочих способа, они хорошо перепроверяют друг друга.

Через iostat. Утилита iostat из пакета sysstat показывает объём записи по блочным устройствам. Разовый снимок бесполезен — нужна статистика за характерный период (обычные сутки с типичной нагрузкой, не ночь простоя и не пиковый батч).

apt install sysstat
# снять статистику по nvme0n1: интервал 60 сек, 60 повторов (час)
iostat -d -x -k 60 60 /dev/nvme0n1

Колонка kB_wrtn/s — килобайты записи в секунду за интервал. Быстрее, но грубее — сравнить счётчик записанных секторов в /proc/diskstats утром и через сутки, переведя разницу в байты (обычно 1 сектор = 512 байт, сверьте через blockdev --getss).

Через атрибут SMART. У SSD есть атрибут с суммарным объёмом записи за всю жизнь диска (называется по-разному: Total_LBAs_Written, Host_Writes_32MiB, у NVMe — Data Units Written). Зная это значение и дату включения диска в эксплуатацию, легко вывести средний темп записи в сутки:

smartctl -A /dev/sda | grep -i written
nvme smart-log /dev/nvme0n1 | grep -i "data units written"

Этот способ надёжнее разового iostat, потому что усредняет по всей истории диска, а не по одному дню, который может быть нетипичным. Как читать остальные SMART-атрибуты — в статье про мониторинг здоровья железа. Оба способа стоит сверить: если расходятся в разы — берите более осторожную (большую) оценку.

Шаг 2: экстраполируйте на срок службы

Дальше — простая арифметика, но именно на ней чаще всего ошибаются, беря число «с потолка». Допустим, замер показал среднесуточную запись 45 ГБ на раздел с базой. Планируемый срок эксплуатации — 5 лет.

45 ГБ/сутки × 365 × 5 лет ≈ 82 ТБ за весь срок

Это оценка суммарной записи за срок службы при сохранении текущего паттерна нагрузки. Важная оговорка: нагрузка редко бывает ровной — база растёт, трафик растёт. Если есть история роста за прошлые периоды — закладывайте такой же рост в прогноз. Без данных о тренде берите текущий темп как консервативную нижнюю границу.

Цифры в таблице — иллюстрация арифметики, подставляйте в неё именно свой замер из шага 1.

Шаг 3: сравните оценку с паспортным TBW модели

Теперь сопоставьте оценку записи за срок службы с паспортным TBW конкретного диска — оно всегда указано в спецификации модели, не берите его на глаз, у моделей одной линейки оно может отличаться в разы.

• Оценка заметно меньше TBW (в 2+ раза) — запас комфортный.
• Оценка близка к TBW (в пределах 20-30%) — повод насторожиться: рост нагрузки или ошибка в замере съедят запас.
• Оценка превышает TBW — с текущим диском и паттерном записи ресурс, скорее всего, выработается раньше конца планируемого срока.

В последнем случае есть два направления, не взаимоисключающих:

Взять модель с большим TBW. Серверные/корпоративные линейки SSD (обычно с DWPD 1, 3, 5+ против 0.3-0.5 у потребительских того же объёма) закладывают заметно больший ресурс за счёт более качественной флеш-памяти и большего резервирования (over-provisioning). Платите больше за гигабайт, но не меняете диск раньше срока. Сравнение классов SSD — в статье NVMe против SATA SSD на сервере.

Пересмотреть паттерн нагрузки. Часть записи может быть избыточной:

• Слишком подробное логирование (debug-уровень в проде вместо info, редкая ротация при небольшом объёме логов).
• Неоптимальные настройки СУБД — слишком частый fsync/checkpoint, избыточный write-ahead journaling.
• Временные файлы на том же диске, что и основные данные, хотя могли бы уйти на отдельный том.
• Активный swap на SSD при нехватке памяти — в этом случае правильнее добавить памяти, а не подстраивать ресурс диска под своп.

Снижение избыточной записи продлевает ресурс диска и часто попутно улучшает задержку на критичных операциях, потому что снижает конкуренцию за I/O.

Превышение TBW — это не выключатель, а статистика

Здесь важно сказать честно, без запугивания и без обманчивого спокойствия одновременно. Превышение паспортного TBW не означает мгновенный отказ диска в конкретный день. Обычно есть некоторый запас прочности сверх заявленного значения — производитель закладывает TBW консервативно, с расчётом на гарантийные обязательства, а не как точный предел разрушения ячеек. Диски нередко работают и после превышения заявленного ресурса.

Но это статистическая гарантия, а не инженерный расчёт вашего конкретного экземпляра. После превышения производитель уже ничего не гарантирует, и риск отказа растёт непредсказуемо — неизвестно, продержится ли именно ваш диск заметно дольше паспорта или откажет вскоре после превышения. Полагаться на недокументированный «запас сверх паспорта» как на плановый ресурс — рискованная практика.

Разумный подход — держать оценку своей нагрузки с запасом от паспортного лимита, а не впритык. Если по расчётам из шага 2 вы к концу срока эксплуатации упираетесь в 90% паспортного TBW — это повод пересмотреть модель или паттерн записи заранее, не дожидаясь фактического исчерпания запаса. И в любом случае TBW описывает только деградацию флеш-памяти, а не защищает от отказа контроллера или других аппаратных сбоев — даже надёжный по ресурсу SSD не отменяет бэкапы, об этом подробнее в статье миф: SSD не нужно бэкапить.

Два примера с реальным расчётом

Небольшой веб-проект. VPS с сайтом и логами nginx: замер через iostat даёт около 3-5 ГБ записи в день, в основном логи и кэш. За 5 лет это ~5,5-9 ТБ — практически любой современный SSD, даже потребительский, закрывает такую нагрузку с большим запасом.

Сервер с активной базой данных. PostgreSQL с частыми короткими транзакциями и активным WAL: замер по истории SMART за 4 месяца показал темп записи около 80 ГБ в сутки, за 5 лет это ~146 ТБ. Если рассматриваемый NVMe большого объёма имеет паспортный TBW в районе 150-200 ТБ (типично для потребительского сегмента) — запас минимальный. Разумнее либо взять модель с TBW от 600-1000+ ТБ (обычный порядок для серверных дисков), либо снизить частоту checkpoint.

Разница между случаями — в том, что нагрузка была измерена, а не предположена. Без замера легко и переплатить за избыточно надёжный диск под лёгкую нагрузку, и наоборот — поставить под интенсивную запись модель, ресурса которой не хватит и на треть срока.

Частые вопросы