О производительности Thin Provision в LVM2

С версии RHEL 6.4 в LVM2 включена поддержка thin provision. На русский я бы перевёл это как «тонкое резервирование», хотя перевод неточен и совершенно не согласуется с реальностью, поэтому далее наравне с русским будет использоваться английское написание.

Thin provisioning — это создание логических томов, которые изначально используют немного места и «растут» по мере записи в них данных. В ZFS это реализовано давно по самой философии этой ФС. В VMware это используется в каждом продукте. Дошло дело до LVM2, широко применяемом в Linux в наши дни. Также одним из основных нововведений является thin snapshots, когда для снэпшотов нет необходимости резервировать место заранее, а он «растёт» вместе с изменёнными данными. Также разрешаются и поощряются вложенные снэпшоты (снэпшоты снэпшотов c любой глубиной), при этом заявляется об отсутствии при этом падения производительности. О нескольких нюансах использования будет рассказано в статье.

Для стабильной работы thin provision в LVM2 требуется ядро 3.4. В Red Hat бэкпортировано и работает на их «классическом» 2.6.32.
В близкой мне Debian Wheezy thin provisioning недоступен ввиду отсутствия ключа при компиляции lvm2 --with-thin=internal и других сложностей. При необходимости, для целей теста, можно скомпилировать этот пакет из исходников.

Меня больше интересовали не снэпшоты, а производительность «тонких логических томов» (Thin Logical Volume) для использовании на серверах. Для нетерпеливых скажу сразу — падение производительности наблюдается, и существенное. Подробности ниже.

На одном и том же сервере с CentOS 6.4 2.6.32-279.2.1.el6.x86_64 на RAID1 сделанном при помощь mdadm, создаём «пул тонкого резервирования» (thin pool):

lvcreate -L 50G -T /dev/VG/thin_pool

и обычный логический том (LV):

lvcreate -L 50G /dev/VG/thick_vol

Измерим производительности линейного чтения и записи на эти устройства:

Thin pool:

Запись:

dd if=/dev/zero of=/dev/mapper/VG-thin_pool  bs=1M count=1000 oflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.9126 s, 65.9 MB/s

Чтение:

dd if=/dev/mapper/VG-thin_pool of=/dev/null bs=1M count=1000 iflag=direct             
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.19247 s, 250 MB/s

LV:

— Запись:

FIO: Запись: iodepth=2, bw=943120 B/s, iops=230, avg=8645.48 usec

# dd if=/dev/zero of=/dev/VG/thick_vol  bs=1M count=1000 oflag=direct 
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.8432 s, 66.2 MB/s

— Чтение:

FIO: Чтение: iodepth=2, bw=775490 B/s, iops=189, avg=10536.95 usec

# dd if=/dev/VG/thick_vol of=/dev/null bs=1M count=1000 iflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.04925 s, 259 MB/s

Как видно производительность при этом не различается для LV и thin pool.

Создаём thin volume (тонкий логический том) в thin pool

lvcreate -V 100G -T -n thin_vol /dev/mapper/VG-thin_pool

Проверяем производительность:

Запись:

FIO: Запись: iodepth=2, bw=1100.5KB/s, iops=275, avg=7241.55 usec

dd if=/dev/zero of=/dev/mapper/VG-thin_vol  bs=1M count=1000 oflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 38.7505 s, 27.1 MB/s

Чтение:

FIO: Чтение: iodepth=256, bw=86100KB/s, iops=21524, avg=11860.53 usec

dd if=/dev/mapper/VG-thin_vol of=/dev/null bs=1M count=1000 iflag=direct     
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.45363 s, 235 MB/s

Очень хорошо заметно, что линейная запись на thin volume производится в 2 раза медленнее, чем на обычный LV (27.1 MB/s против 66.2 MB/s). При этом скорость случайной записи даже возрастает, а для случайного чтения вообще не удалось замерить реальную производительность — показывает только уровень чтения из кеша, при этом сброс кеша не помог.

Падение производительности линейной записи настораживает и есть вероятность, что это связано с наличием RAID1 от mdadm, поэтому пришлось протестировать на другой машине, также посмотрим на производительность на уровне файловой системы. Виртуальная машина VMware Workstation Debian Wheezy 7.3 3.10-0.bpo.3-amd64 SSD диск.

Проверяем производительность:

LV:

Запись:

dd if=/dev/zero of=/delete.img bs=1M count=1000 oflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.49623 s, 300 MB/s

Чтение:

FIO: Чтение: iodepth=384, bw=158839KB/s, iops=39709, avg= 9.64 msec

dd if=/delete.img of=/dev/null bs=1M count=1000 iflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 2.31352 s, 453 MB/s

Thin LV:

Запись:

dd if=/dev/zero of=/mnt/thin/delete.img bs=1M count=1000 oflag=direct    
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 7.15546 s, 147 MB/s

Чтение:

FIO: Чтение: iodepth=384, bw=176574KB/s, iops=44143, avg=8675.36 usec

dd if=/mnt/thin/delete.img of=/dev/null bs=1M count=1000 iflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 2.33435 s, 449 MB/s

Производительность случайной записи измерить не удалось.
И снова наблюдаем падение скорости линейной записи в два раза, как и в предыдущем тесте. Возможно это связано с нюансами виртуальной машины.

UPDATE: Произвёл ещё одно тестирование на «чистом» сервере без RAID и вирт.машин. Падение производительности линейной записи не наблюдается! Прошу прощения уважаемой аудитории за введение в заблуждение в связи с однобокостью тестирования в первые два теста. В результате считаю необходимо тестировать производительность для каждого конкретного случая.

ИТОГИ:

1. При использовании thin volume в каждом конкретном случае необходимо производить тестирование производительности линейной записи, так как, к примеру, для RAID 1 с mdadm и вирт.машин VMware происходит падение скорости линейной записи на него в 2 раза по сравнению с «классическим» LV;
2. При этом у случайной записи на thin volume такого падения не замечено и скорость на том же уровне, что я для LV;
3. На Debian использовать в продакшне пока не буду ввиду отсутствия в стандартных репозиториях;