Обновить

Устойчивая запись NVMe после исчерпания SLC-кэша: где заканчивается burst

Для WAL и backup важна устойчивая запись NVMe после исчерпания SLC-кэша. Отличить исчерпание SLC-кэша NVMe от перегрева и сборки мусора можно только длительным замером. Размер кэша зависит от модели, прошивки, заполнения, температуры, over-provisioning и истории записи, поэтому чужие цифры вашему диску не подойдут.

Почему скорость записи NVMe падает через несколько минут?

Контроллер сначала пишет данные в быстрый pseudo-SLC cache. После его заполнения новые страницы идут прямо в TLC или QLC, и контроллер параллельно переносит туда же содержимое кэша. Похожий провал вызывает нагрев, поэтому причину устанавливают по рядам bandwidth и latency, температуре и данным SMART.

Почему паспортная скорость заканчивается раньше рабочей нагрузки

На пустом диске короткая запись целиком остаётся в кэше, а на заполненном динамический кэш сжимается, потому что контроллер отдаёт часть ячеек под обычное хранение. Исчерпание SLC-кэша NVMe определяют по bandwidth, p95/p99 latency и длительности спада вместе.

От host writes к NAND writes и garbage collection

FTL связывает адреса хоста с физическими страницами. Очищая блок, контроллер переносит валидные страницы, поэтому NAND writes могут превышать host writes. NVMe SMART показывает host writes, а NAND writes часто доступен только в журнале производителя. Их отношение и есть write amplification, но устойчивая скорость записи NVMe зависит ещё и от профиля нагрузки.

Как тестировать NVMe, не уничтожив производственные данные

Тест идёт на отдельном диске или файле: raw-запись стирает всё, что попадёт под неё. Для write amplification SSD нужны счётчики host writes и NAND writes.

Как безопасно измерить объём SLC-кэша?

Возьмите отдельный диск или файл, а перед запуском проверьте путь, serial и точки монтирования. Записывайте интервальные bandwidth, latency, температуру и SMART до устойчивого перелома. Объём записи к этому моменту считают оценкой кэша, если несколько повторов после одинаковой подготовки дают близкий результат.

fio-серия, которая проходит границу кэша

Размер кэша неизвестен, поэтому серию задают по времени. Длительность держат на time_based и runtime, size ограничивает область файла, а логи собирают bandwidth, IOPS и latency по интервалам. Перед каждым повтором выдержите одинаковую паузу и заново проведите ту же подготовку. Методика steady state записи TLC и QLC задаёт единые условия нагрузки и отчёта.

Как отличить окончание SLC от случайного колебания

Длительный тест записи fio показывает точку перелома, когда вместе меняются bandwidth и хвост latency, а объём близок в повторах. Отчёт включает fio JSON, SMART до и после, температуру, host и NAND writes, подготовку. Точка перелома получается диапазоном, а не одним числом.

Два фактора, которые маскируются под исчерпание кэша

На тепловой троттлинг указывает рост температуры или счётчика thermal warning. Garbage collection зависит от свободных блоков и прежних записей, поэтому повторите тест при заданном заполнении. Охлаждение и over-provisioning проверяйте по отдельности.

Какой профиль fio показывает устойчивую скорость?

1. Тест длится дольше burst.

2. Логи содержат bandwidth, IOPS и latency.

3. Подготовка одинакова во всех повторах.

Какая фаза приложения попадает в медленный режим NVMe

Граница кэша показывает, поместится ли рабочий burst. Для backup важна длинная последовательная запись, а у WAL steady state задают мелкие синхронные операции и p99 fsync. Крупноблочный bandwidth измеряет совсем другой режим.

Устойчивая скорость, p99 и ресурс вместо рекламного максимума

В карточке диска указывают заполнение, прошивку, охлаждение, steady-state диапазон и p99. Рабочий поток определяет запас, а TBW должен покрывать ожидаемый объём записи. После обновления прошивки тест повторяют.

Устойчивая запись NVMe после исчерпания SLC-кэша важнее рекламного максимума. Для выбора нужны p99 при рабочем заполнении и безопасный воспроизводимый тест. Перегрев и задержки на стороне хоста нужно исключить до замера.

Теги:
-1
Комментарии0

В Cloudflare сэкономили 100 ТБ оперативной памяти, оптимизировав кэш DNS‑резолвера 1.1.1.1

В Cloudflare рассказали об опыте, когда небольшая экономия памяти на одной структуре данных, будучи умноженной на сотни миллиардов экземпляров, превращается в десятки терабайт. Сетевые инженеры последовательно внесли пять сравнительно небольших изменений в виде патчей в представление записей кэша DNS-резолвера 1.1.1.1 и в итоге высвободили около 100 ТБ оперативной памяти на серверах IT-инфраструктуры.

В Cloudflare сэкономили 100 ТБ оперативной памяти, оптимизировав кэш DNS‑резолвера 1.1.1.1

Публикации