Кэши, режимы нагрузки и ловушка среднего, или Почему storage-бенчмарки врут
<img src="https://habrastorage.org/getpro/habr/upload_files/2c2/21c/518/2c221c5183421915cc81851c5d776e95.png" /><p>Представьте, разработчики добавили прозрачное шифрование в файловую систему, собрали ядро и прогнали Fio — пропускная способность не изменилась. Однако после раскатки на продакшен производительность резко упала. Дело не в том, что бенчмарк ошибся: он честно измерил предел быстродействия жесткого диска, а накладные расходы на шифрование остались скрыты за дисковыми задержками. Так и возникает одна из самых типичных ошибок storage-бенчмаркинга. </p><p>Хранение до сих пор кажется многим инженерам простой подсистемой: файловая система, блочное устройство, метрика throughput. На практике это одна из самых коварных частей стека — с иерархией памяти в 4–8 порядков разницы между самой быстрой и самой медленной операцией, слоями виртуализации (LVM, программные RAID, NFS) и переключениями контекста между ядром и user-space.</p><p>Чтобы разобраться, как корректно измерять производительность систем хранения, обратимся к<a href="https://www.usenix.org/conference/fast26/presentation/zadok"> докладу</a> Эреза Цадока, профессора Университета Стони-Брук, возглавляющего Лабораторию файловых систем и хранения данных.</p><p>Все подробности — под катом.</p> <a href="https://habr.com/ru/articles/1077526/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1077526#habracut">Читать далее</a>