Add documentation
This commit is contained in:
Vitaliy Filippov
@@ -0,0 +1,108 @@
|
||||
[Documentation](../../README.md#documentation) → Performance → Example Comparison with Ceph
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](comparison1.ru.md)
|
||||
|
||||
# Example Comparison with Ceph
|
||||
|
||||
- [Test environment](#test-environment)
|
||||
- [Raw drive performance](#raw-drive-performance)
|
||||
- [2 replicas](#2-replicas)
|
||||
- [Ceph 15.2.4 (Bluestore)](#ceph-15-2-4-bluestore)
|
||||
- [Vitastor 0.4.0 (native)](#vitastor-0-4-0-native)
|
||||
- [Vitastor 0.4.0 (NBD)](#vitastor-0-4-0-nbd)
|
||||
- [EC/XOR 2+1](#ec/xor-2-1)
|
||||
- [Ceph 15.2.4](#ceph-15-2-4)
|
||||
- [Vitastor 0.4.0](#vitastor-0-4-0)
|
||||
|
||||
## Test environment
|
||||
|
||||
Hardware configuration: 4 nodes, each with:
|
||||
- 6x SATA SSD Intel D3-S4510 3.84 TB
|
||||
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
|
||||
- 384 GB RAM
|
||||
- 1x 25 GbE network interface (Mellanox ConnectX-4 LX), connected to a Juniper QFX5200 switch
|
||||
|
||||
CPU powersaving was disabled. Both Vitastor and Ceph were configured with 2 OSDs per 1 SSD.
|
||||
|
||||
All of the results below apply to 4 KB blocks and random access (unless indicated otherwise).
|
||||
|
||||
T8Q64 tests were conducted over 8 400GB RBD images from all hosts (every host was running 2 instances of fio).
|
||||
This is because Ceph has performance penalties related to running multiple clients over a single RBD image.
|
||||
|
||||
cephx_sign_messages was set to false during tests, RocksDB and Bluestore settings were left at defaults.
|
||||
|
||||
T8Q64 read test was conducted over 1 larger inode (3.2T) from all hosts (every host was running 2 instances of fio).
|
||||
Vitastor has no performance penalties related to running multiple clients over a single inode.
|
||||
If conducted from one node with all primary OSDs moved to other nodes the result was slightly lower (689000 iops),
|
||||
this is because all operations resulted in network roundtrips between the client and the primary OSD.
|
||||
When fio was colocated with OSDs (like in Ceph benchmarks above), 1/4 of the read workload actually
|
||||
used the loopback network.
|
||||
|
||||
Vitastor was configured with: `--disable_data_fsync true --immediate_commit all --flusher_count 8
|
||||
--disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
|
||||
--journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
|
||||
--journal_size 16777216`.
|
||||
|
||||
## Raw drive performance
|
||||
|
||||
- T1Q1 write ~27000 iops (~0.037ms latency)
|
||||
- T1Q1 read ~9800 iops (~0.101ms latency)
|
||||
- T1Q32 write ~60000 iops
|
||||
- T1Q32 read ~81700 iops
|
||||
|
||||
## 2 replicas
|
||||
|
||||
### Ceph 15.2.4 (Bluestore)
|
||||
|
||||
- T1Q1 write ~1000 iops (~1ms latency)
|
||||
- T1Q1 read ~1750 iops (~0.57ms latency)
|
||||
- T8Q64 write ~100000 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
- T8Q64 read ~480000 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
|
||||
In fact, not that bad for Ceph. These servers are an example of well-balanced Ceph nodes.
|
||||
However, CPU usage and I/O latency were through the roof, as usual.
|
||||
|
||||
### Vitastor 0.4.0 (native)
|
||||
|
||||
- T1Q1 write: 7087 iops (0.14ms latency)
|
||||
- T1Q1 read: 6838 iops (0.145ms latency)
|
||||
- T2Q64 write: 162000 iops, total CPU usage by OSDs about 3 virtual cores on each node
|
||||
- T8Q64 read: 895000 iops, total CPU usage by OSDs about 4 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 2800 MB/s
|
||||
- Linear read (4M T1Q32): 1500 MB/s
|
||||
|
||||
### Vitastor 0.4.0 (NBD)
|
||||
|
||||
NBD is currently required to mount Vitastor via kernel, but it imposes additional overhead
|
||||
due to additional copying between the kernel and userspace. This mostly hurts linear
|
||||
bandwidth, not iops.
|
||||
|
||||
Vitastor with single-threaded NBD on the same hardware:
|
||||
- T1Q1 write: 6000 iops (0.166ms latency)
|
||||
- T1Q1 read: 5518 iops (0.18ms latency)
|
||||
- T1Q128 write: 94400 iops
|
||||
- T1Q128 read: 103000 iops
|
||||
- Linear write (4M T1Q128): 1266 MB/s (compared to 2800 MB/s via fio)
|
||||
- Linear read (4M T1Q128): 975 MB/s (compared to 1500 MB/s via fio)
|
||||
|
||||
## EC/XOR 2+1
|
||||
|
||||
### Ceph 15.2.4
|
||||
|
||||
- T1Q1 write: 730 iops (~1.37ms latency)
|
||||
- T1Q1 read: 1500 iops with cold cache (~0.66ms latency), 2300 iops after 2 minute metadata cache warmup (~0.435ms latency)
|
||||
- T4Q128 write (4 RBD images): 45300 iops, total CPU usage by OSDs about 30 virtual cores on each node
|
||||
- T8Q64 read (4 RBD images): 278600 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 1950 MB/s before preallocation, 2500 MB/s after preallocation
|
||||
- Linear read (4M T1Q32): 2400 MB/s
|
||||
|
||||
### Vitastor 0.4.0
|
||||
|
||||
- T1Q1 write: 2808 iops (~0.355ms latency)
|
||||
- T1Q1 read: 6190 iops (~0.16ms latency)
|
||||
- T2Q64 write: 85500 iops, total CPU usage by OSDs about 3.4 virtual cores on each node
|
||||
- T8Q64 read: 812000 iops, total CPU usage by OSDs about 4.7 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 3200 MB/s
|
||||
- Linear read (4M T1Q32): 1800 MB/s
|
||||
@@ -0,0 +1,113 @@
|
||||
[Документация](../../README-ru.md#документация) → Производительность → Пример сравнения с Ceph
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](comparison1.en.md)
|
||||
|
||||
# Пример сравнения с Ceph
|
||||
|
||||
- [Описание стенда](#описание-стенда)
|
||||
- [Производительность голых дисков](#производительность-голых-дисков)
|
||||
- [2 реплики](#2-реплики)
|
||||
- [Ceph 15.2.4 (Bluestore)](#ceph-15-2-4-bluestore)
|
||||
- [Vitastor 0.4.0 (нативный драйвер fio)](#vitastor-0-4-0-нативный-драйвер-fio)
|
||||
- [Vitastor 0.4.0 (NBD)](#vitastor-0-4-0-nbd)
|
||||
- [EC/XOR 2+1](#ec/xor-2-1)
|
||||
- [Ceph 15.2.4](#ceph-15-2-4)
|
||||
- [Vitastor 0.4.0](#vitastor-0-4-0)
|
||||
|
||||
## Описание стенда
|
||||
|
||||
Железо: 4 сервера, в каждом:
|
||||
- 6x SATA SSD Intel D3-4510 3.84 TB
|
||||
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
|
||||
- 384 GB RAM
|
||||
- 1x 25 GbE сетевая карта (Mellanox ConnectX-4 LX), подключённая к свитчу Juniper QFX5200
|
||||
|
||||
Экономия энергии CPU отключена. В тестах и Vitastor, и Ceph развёрнуто по 2 OSD на 1 SSD.
|
||||
|
||||
Все результаты ниже относятся к случайной нагрузке 4 КБ блоками (если явно не указано обратное).
|
||||
|
||||
Тесты в 8 потоков проводились на 8 400GB RBD образах со всех хостов (с каждого хоста запускалось 2 процесса fio).
|
||||
Это нужно потому, что в Ceph несколько RBD-клиентов, пишущих в 1 образ, очень сильно замедляются.
|
||||
|
||||
Настройки RocksDB и Bluestore в Ceph не менялись, единственным изменением было отключение cephx_sign_messages.
|
||||
|
||||
Тест на чтение в 8 потоков проводился на 1 большом образе (3.2 ТБ) со всех хостов (опять же, по 2 fio с каждого).
|
||||
В Vitastor никакой разницы между 1 образом и 8-ю нет. Естественно, примерно 1/4 запросов чтения
|
||||
в такой конфигурации, как и в тестах Ceph выше, обслуживалась с локальной машины. Если проводить
|
||||
тест так, чтобы все операции всегда обращались к первичным OSD по сети - тест сильнее упирался
|
||||
в сеть и результат составлял примерно 689000 iops.
|
||||
|
||||
Настройки Vitastor: `--disable_data_fsync true --immediate_commit all --flusher_count 8
|
||||
--disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
|
||||
--journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
|
||||
--journal_size 16777216`.
|
||||
|
||||
## Производительность голых дисков
|
||||
|
||||
- T1Q1 запись ~27000 iops (задержка ~0.037ms)
|
||||
- T1Q1 чтение ~9800 iops (задержка ~0.101ms)
|
||||
- T1Q32 запись ~60000 iops
|
||||
- T1Q32 чтение ~81700 iops
|
||||
|
||||
## 2 реплики
|
||||
|
||||
### Ceph 15.2.4 (Bluestore)
|
||||
|
||||
- T1Q1 запись ~1000 iops (задержка ~1ms)
|
||||
- T1Q1 чтение ~1750 iops (задержка ~0.57ms)
|
||||
- T8Q64 запись ~100000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
|
||||
- T8Q64 чтение ~480000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
|
||||
|
||||
Если не учитывать как обычно запредельное потребление CPU (40 ядер), не так уж и плохо для Ceph.
|
||||
Данные серверы - как раз хороший пример сбалансированных Ceph-нод - 6 SATA SSD как раз
|
||||
утилизируют 25-гигабитную сеть, а без 2 мощных процессоров Ceph-у бы не хватило ядер,
|
||||
чтобы выдать пристойный результат.
|
||||
|
||||
### Vitastor 0.4.0 (нативный драйвер fio)
|
||||
|
||||
- T1Q1 запись: 7087 iops (задержка 0.14ms)
|
||||
- T1Q1 чтение: 6838 iops (задержка 0.145ms)
|
||||
- T2Q64 запись: 162000 iops, потребление CPU - 3 ядра на каждом сервере
|
||||
- T8Q64 чтение: 895000 iops, потребление CPU - 4 ядра на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 2800 МБ/с
|
||||
- Линейное чтение (4M T1Q32): 1500 МБ/с
|
||||
|
||||
### Vitastor 0.4.0 (NBD)
|
||||
|
||||
NBD расшифровывается как "сетевое блочное устройство", но на самом деле оно также
|
||||
работает просто как аналог FUSE для блочных устройств, то есть, представляет собой
|
||||
"блочное устройство в пространстве пользователя".
|
||||
|
||||
NBD - на данный момент единственный способ монтировать Vitastor ядром Linux. Его
|
||||
производительность немного хуже из-за дополнительных операций копирований данных
|
||||
между ядром и пространством пользователя, что, правда, в основном затрагивает линейное
|
||||
чтение/запись, а не случайный доступ.
|
||||
|
||||
- T1Q1 запись: 6000 iops (задержка 0.166ms)
|
||||
- T1Q1 чтение: 5518 iops (задержка 0.18ms)
|
||||
- T1Q128 запись: 94400 iops
|
||||
- T1Q128 чтение: 103000 iops
|
||||
- Линейная запись (4M T1Q128): 1266 МБ/с (в сравнении с 2800 МБ/с через fio)
|
||||
- Линейное чтение (4M T1Q128): 975 МБ/с (в сравнении с 1500 МБ/с через fio)
|
||||
|
||||
## EC/XOR 2+1
|
||||
|
||||
### Ceph 15.2.4
|
||||
|
||||
- T1Q1 запись: 730 iops (задержка ~1.37ms latency)
|
||||
- T1Q1 чтение: 1500 iops с холодным кэшем метаданных (задержка ~0.66ms), 2300 iops через 2 минуты прогрева (задержка ~0.435ms)
|
||||
- T4Q128 запись (4 RBD images): 45300 iops, потребление CPU - 30 ядер на каждом сервере
|
||||
- T8Q64 чтение (4 RBD images): 278600 iops, потребление CPU - 40 ядер на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 1950 МБ/с в пустой образ, 2500 МБ/с в заполненный образ
|
||||
- Линейное чтение (4M T1Q32): 2400 МБ/с
|
||||
|
||||
### Vitastor 0.4.0
|
||||
|
||||
- T1Q1 запись: 2808 iops (задержка ~0.355ms)
|
||||
- T1Q1 чтение: 6190 iops (задержка ~0.16ms)
|
||||
- T2Q64 запись: 85500 iops, потребление CPU - 3.4 ядра на каждом сервере
|
||||
- T8Q64 чтение: 812000 iops, потребление CPU - 4.7 ядра на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 3200 МБ/с
|
||||
- Линейное чтение (4M T1Q32): 1800 МБ/с
|
||||
@@ -0,0 +1,49 @@
|
||||
[Documentation](../../README.md#documentation) → Performance → Vitastor's Theoretical Maximum Performance
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](theoretical.ru.md)
|
||||
|
||||
# Vitastor's Theoretical Maximum Performance
|
||||
|
||||
Replicated setups:
|
||||
- Single-threaded (T1Q1) read latency: 1 network roundtrip + 1 disk read.
|
||||
- Single-threaded write+fsync latency:
|
||||
- With immediate commit: 2 network roundtrips + 1 disk write.
|
||||
- With lazy commit: 4 network roundtrips + 1 disk write + 1 disk flush.
|
||||
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
|
||||
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops / number of replicas / write amplification)).
|
||||
|
||||
EC/XOR setups:
|
||||
- Single-threaded (T1Q1) read latency: 1.5 network roundtrips + 1 disk read.
|
||||
- Single-threaded write+fsync latency:
|
||||
- With immediate commit: 3.5 network roundtrips + 1 disk read + 2 disk writes.
|
||||
- With lazy commit: 5.5 network roundtrips + 1 disk read + 2 disk writes + 2 disk fsyncs.
|
||||
- 0.5 in actually (k-1)/k which means that an additional roundtrip doesn't happen when
|
||||
the read sub-operation can be served locally.
|
||||
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
|
||||
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops * number of data drives / (number of data + parity drives) / write amplification)).
|
||||
In fact, you should put disk write iops under the condition of ~10% reads / ~90% writes in this formula.
|
||||
|
||||
Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
|
||||
1. Journal block write
|
||||
2. Journal data write
|
||||
3. Metadata block write
|
||||
4. Another journal block write for EC/XOR setups
|
||||
5. Data block write
|
||||
|
||||
If you manage to get an SSD which handles 512 byte blocks well (Optane?) you may
|
||||
lower 1, 3 and 4 to 512 bytes (1/8 of data size) and get WA as low as 2.375.
|
||||
|
||||
Lazy fsync also reduces WA for parallel workloads because journal blocks are only
|
||||
written when they fill up or fsync is requested.
|
||||
|
||||
## In Practice
|
||||
|
||||
In practice, using tests from [Understanding Performance](understanding.en.md)
|
||||
and good server-grade SSD/NVMe drives, you should head for:
|
||||
- At least 5000 T1Q1 replicated read and write iops (maximum 0.2ms latency)
|
||||
- At least ~80k parallel read iops or ~30k write iops per 1 core (1 OSD)
|
||||
- Disk-speed or wire-speed linear reads and writes, whichever is the bottleneck in your case
|
||||
|
||||
Lower results may mean that you have bad drives, bad network or some kind of misconfiguration.
|
||||
@@ -0,0 +1,41 @@
|
||||
[Документация](../../README-ru.md#документация) → Производительность → Теоретическая максимальная производительность Vitastor
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](theoretical.en.md)
|
||||
|
||||
# Теоретическая максимальная производительность Vitastor
|
||||
|
||||
При использовании репликации:
|
||||
- Задержка чтения в 1 поток (T1Q1): 1 сетевой RTT + 1 чтение с диска.
|
||||
- Запись+fsync в 1 поток:
|
||||
- С мгновенным сбросом: 2 RTT + 1 запись.
|
||||
- С отложенным ("ленивым") сбросом: 4 RTT + 1 запись + 1 fsync.
|
||||
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
|
||||
- Параллельная запись: сумма IOPS всех дисков / число реплик / WA либо производительность сети, если в сеть упрётся раньше.
|
||||
|
||||
При использовании кодов коррекции ошибок (EC):
|
||||
- Задержка чтения в 1 поток (T1Q1): 1.5 RTT + 1 чтение.
|
||||
- Запись+fsync в 1 поток:
|
||||
- С мгновенным сбросом: 3.5 RTT + 1 чтение + 2 записи.
|
||||
- С отложенным ("ленивым") сбросом: 5.5 RTT + 1 чтение + 2 записи + 2 fsync.
|
||||
- Под 0.5 на самом деле подразумевается (k-1)/k, где k - число дисков данных,
|
||||
что означает, что дополнительное обращение по сети не нужно, когда операция
|
||||
чтения обслуживается локально.
|
||||
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
|
||||
- Параллельная запись: сумма IOPS всех дисков / общее число дисков данных и чётности / WA либо производительность сети, если в сеть упрётся раньше.
|
||||
Примечание: IOPS дисков в данном случае надо брать в смешанном режиме чтения/записи в пропорции, аналогичной формулам выше.
|
||||
|
||||
WA (мультипликатор записи) для 4 КБ блоков в Vitastor обычно составляет 3-5:
|
||||
1. Запись метаданных в журнал
|
||||
2. Запись блока данных в журнал
|
||||
3. Запись метаданных в БД
|
||||
4. Ещё одна запись метаданных в журнал при использовании EC
|
||||
5. Запись блока данных на диск данных
|
||||
|
||||
Если вы найдёте SSD, хорошо работающий с 512-байтными блоками данных (Optane?),
|
||||
то 1, 3 и 4 можно снизить до 512 байт (1/8 от размера данных) и получить WA всего 2.375.
|
||||
|
||||
Кроме того, WA снижается при использовании отложенного/ленивого сброса при параллельной
|
||||
нагрузке, т.к. блоки журнала записываются на диск только когда они заполняются или явным
|
||||
образом запрашивается fsync.
|
||||
@@ -0,0 +1,57 @@
|
||||
[Documentation](../../README.md#documentation) → Performance → Understanding Storage Performance
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](understanding.ru.md)
|
||||
|
||||
# Understanding Storage Performance
|
||||
|
||||
The most important thing for fast storage is latency, not parallel iops.
|
||||
|
||||
The best possible latency is achieved with one thread and queue depth of 1 which basically means
|
||||
"client load as low as possible". In this case IOPS = 1/latency, and this number doesn't
|
||||
scale with number of servers, drives, server processes or threads and so on.
|
||||
Single-threaded IOPS and latency numbers only depend on *how fast a single daemon is*.
|
||||
|
||||
Why is it important? It's important because some of the applications *can't* use
|
||||
queue depth greater than 1 because their task isn't parallelizable. A notable example
|
||||
is any ACID DBMS because all of them write their WALs sequentially with fsync()s.
|
||||
|
||||
fsync, by the way, is another important thing often missing in benchmarks. The point is
|
||||
that drives have cache buffers and don't guarantee that your data is actually persisted
|
||||
until you call fsync() which is translated to a FLUSH CACHE command by the OS.
|
||||
|
||||
Desktop SSDs are very fast without fsync - NVMes, for example, can process ~80000 write
|
||||
operations per second with queue depth of 1 without fsync - but they're really slow with
|
||||
fsync because they have to actually write data to flash chips when you call fsync. Typical
|
||||
number is around 1000-2000 iops with fsync.
|
||||
|
||||
Server SSDs often have supercapacitors that act as a built-in UPS and allow the drive
|
||||
to flush its DRAM cache to the persistent flash storage when a power loss occurs.
|
||||
This makes them perform equally well with and without fsync. This feature is called
|
||||
"Advanced Power Loss Protection" by Intel; other vendors either call it similarly
|
||||
or directly as "Full Capacitor-Based Power Loss Protection".
|
||||
|
||||
All software-defined storages that I currently know are slow in terms of latency.
|
||||
Notable examples are Ceph and internal SDSes used by cloud providers like Amazon, Google,
|
||||
Yandex and so on. They're all slow and can only reach ~0.3ms read and ~0.6ms 4 KB write latency
|
||||
with best-in-slot hardware.
|
||||
|
||||
And that's in the SSD era when you can buy an SSD that has ~0.04ms latency for 100 $.
|
||||
|
||||
## fio commands
|
||||
|
||||
I use the following 6 commands with small variations to benchmark block storage:
|
||||
|
||||
- Linear write (results in MB/s):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX`
|
||||
- Linear read (results in MB/s):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX`
|
||||
- Random write latency (T1Q1, this hurts storages the most) (results in iops or milliseconds of latency):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX`
|
||||
- Random read latency (T1Q1) (results in iops or milliseconds of latency):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX`
|
||||
- Parallel write iops (use numjobs=4 if a single CPU core is insufficient to saturate the load) (results only in 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`
|
||||
- Parallel read iops (use numjobs if a single CPU core is insufficient to saturate the load) (results only in 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`
|
||||
@@ -0,0 +1,65 @@
|
||||
[Документация](../../README-ru.md#документация) → Производительность → Понимание сути производительности систем хранения
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](understanding.en.md)
|
||||
|
||||
# Понимание сути производительности систем хранения
|
||||
|
||||
Вкратце: для быстрой хранилки задержки важнее, чем пиковые 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`
|
||||
|
||||
Почему нужно тестировать именно так - см. [тут](https://yourcmc.ru/wiki/Производительность_Ceph#.D0.9B.D0.B8.D1.80.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.BE.D0.B5_.D0.BE.D1.82.D1.81.D1.82.D1.83.D0.BF.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5).
|
||||
Reference in New Issue
Block a user