6.3 KiB
Документация → Производительность → Понимание сути производительности систем хранения
Понимание сути производительности систем хранения
Вкратце: для быстрой хранилки задержки важнее, чем пиковые iops-ы.
Лучшая возможная задержка достигается при тестировании в 1 поток с глубиной очереди 1, что приблизительно означает минимально нагруженное состояние кластера. В данном случае IOPS = 1/задержка. Ни числом серверов, ни дисков, ни серверных процессов/потоков задержка не масштабируется... Она зависит только от того, насколько быстро один серверный процесс (и клиент) обрабатывают одну операцию.
Почему задержки важны? Потому, что некоторые приложения не могут использовать глубину очереди больше 1, ибо их задача не параллелизуется. Важный пример - это все СУБД с поддержкой консистентности (ACID), потому что все они обеспечивают её через журналирование, а журналы пишутся последовательно и с fsync() после каждой операции.
fsync, кстати - это ещё одна очень важная вещь, про которую почти всегда забывают в тестах. Смысл в том, что все современные диски имеют кэши/буферы записи и не гарантируют, что данные реально физически записываются на носитель до того, как вы делаете fsync(), который транслируется в команду сброса кэша операционной системой.
Дешёвые SSD для настольных ПК и ноутбуков очень быстрые без fsync - NVMe диски, например, могут обработать порядка 80000 операций записи в секунду с глубиной очереди 1 без fsync. Однако с fsync, когда они реально вынуждены писать каждый блок данных во флеш-память, они выжимают лишь 1000-2000 операций записи в секунду (число практически постоянное для всех моделей SSD).
Серверные SSD часто имеют суперконденсаторы, работающие как встроенный источник бесперебойного питания и дающие дискам успеть сбросить их DRAM-кэш в постоянную флеш-память при отключении питания. Благодаря этому диски с чистой совестью игнорируют fsync, так как точно знают, что данные из кэша доедут до постоянной памяти.
Все наиболее известные программные СХД, например, Ceph и внутренние СХД, используемые такими облачными провайдерами, как Amazon, Google, Яндекс, медленные в смысле задержки. В лучшем случае они дают задержки от 0.3мс на чтение и 0.6мс на запись 4 КБ блоками даже при условии использования наилучшего возможного железа.
И это в эпоху SSD, когда вы можете пойти на рынок и купить там SSD, задержка которого на чтение будет 0.1мс, а на запись - 0.04мс, за 100$ или даже дешевле.
Команды fio
Когда мне нужно быстро протестировать производительность блочного устройства, я использую следующие 6 команд, с небольшими вариациями:
- Линейная запись (результаты в МБ/с):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX - Линейное чтение (результаты в МБ/с):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX - Запись в 1 поток (T1Q1) (результаты в iops или миллисекундах задержки):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX - Чтение в 1 поток (T1Q1) (результаты в iops или миллисекундах задержки):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX - Параллельная запись (numjobs=4 использовать, когда 1 ядро CPU не может насытить диск) (результаты только в iops):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX - Параллельное чтение (numjobs - аналогично) (результаты только в iops):
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX
Почему нужно тестировать именно так - см. тут.