- PVSM.RU - https://www.pvsm.ru -
С версии 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
Измерим производительности линейного чтения и записи на эти устройства:
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
— Запись:
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.
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 диск
Проверяем производительность:
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
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
Производительность случайной записи измерить не удалось.
И снова наблюдаем падение скорости линейной записи в два раза, как и в предыдущем тесте.
Автор: funditus
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/53889
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/210856/
Нажмите здесь для печати.