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

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

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

Для стабильной работы 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 создаём «пул тонкого резервирования» (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). При этом скорость случайной записи даже возрастает, а для случайного чтения вообще не удалось замерить реальную производительность — показывает только уровень чтения из кеша, при этом сброс кеша не помог.

Падение производительности линейной записи настораживает, поэтому пришлось протестировать на другой машине, также посмотрим на производительность на уровне файловой системы. 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

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

ИТОГИ:

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

Автор: funditus

Источник