funditus Jan 30 2014 at 17:01

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

4 min

16K

High performance*

+12

Comments 19

amarao Jan 30 2014 at 19:39

Чтобы капитально напрячь всё, нужно:

1) Отключить read-ahead и write-cache устройств:
hdparm -A0 /dev/sdx
hdparm -W0 /dev/sdx

2) Использовать флаг dsync для dd и fdatasync=1 для fio.

Результаты могут оказаться сильно другие.

miragenn Jan 30 2014 at 19:59

А что если запустить тест линейной записи еще раз? Насколько я знаю, в QCOW2 формате дисков линейная запись тоже сильно тормозит, если при ней файл диска расширяется.

funditus Jan 31 2014 at 09:13

Тест линейной записи и чтения запускался несколько раз подряд. Цифры были одного порядка.

dyasny Jan 31 2014 at 09:43

так оно и дальше будет расширяться. Интересно расширить до максимума, и посмотреть будет ли тогда производительность лучше.

funditus Jan 31 2014 at 09:47

Записывал 10 Гбайт. По идее должен был расшириться. Потом сразу туда же записывал 1 Гбайт. Результат тот же.

dyasny Jan 31 2014 at 09:57

туда же, это указывая для начала записи тот же оффсет?

funditus Jan 31 2014 at 10:19

Немного не так написал. Первый раз скорость ниже ввиду thin provisioning-а, а далее стабильно низкая — в 2 раза ниже.
Вот первый раз запись 10 Гбайт:

dd if=/dev/zero of=/dev/mapper/VG-thin_vol  bs=1M count=10000 oflag=direct

10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 758.853 s, 13.8 MB/s

Последующие записи в 1 Гбайт сразу же:

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, 42.1063 s, 24.9 MB/s

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, 39.9542 s, 26.2 MB/s

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, 36.1144 s, 29.0 MB/s

А теперь тут же, но на «классический» LV:

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

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

dyasny Jan 31 2014 at 10:29

честно говоря я не лазил в потроха последних наработок LVM, и я не знаю как там реализовано расширение тома. Если так же как в QEMU для QCOW2, то шаг расширения — 4к, что очень мало, и при каждом io будет отрабатывать lvresize. само собой, оверхед будет ужасный.

Когда мы делали реализацию qcow2 на raw lv, мы сразу же уперлись в этот потолок и решили все очень простым образом — шаг роста LV стал 512Мб, что при современных объемах дисков не критично, зато lvresize стал вызываться достаточно редко, не влияя на производительность.

что касается оффсетов, то опять же, я не знаю наверняка куда в thin LV будет писаться данный тест, так как это уже не просто набор блоков, а набор блоков плюс метадата. В принципе, файловая система это тоже блоки и метадата которая их организует и адресует, и если делать dd в файл на ФС, то писаться будет не с нулевого блока, а с того куда укажет метадата как доступный для нового файла. Как бы и тут не оказалось что то похожее, я потому и спрашивал указывался ли оффсет.

dyasny Jan 31 2014 at 08:48

интересно что на это сказали мейнтейнеры LVM — ведь падение скорости в два раза в отличие от заявленного это изрядный баг, возможно даже блокер. Можно ссылку на багрепорт?

funditus Jan 31 2014 at 09:16

Багрепорт не открывал, так как была цель внедрить для своих целей на серверах.

dyasny Jan 31 2014 at 09:44

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

funditus Jan 31 2014 at 09:48

Это вопрос философии.

-1

dyasny Jan 31 2014 at 10:00

это вопрос элементарного уважения к труду разработчиков. Критиковать легко, и даже нужно, и никто даже не просит исправлять ошибки за разработчиков. Но как минимум сообщить о проблеме нужно, иначе как ее исправят? Мейнтейнеры LVM хабр не читают, они читают свои багрепорты.

kachini Jan 31 2014 at 09:43

— при _первой_ записи на ThP том вполне ожидаема просадка производительности. Что с повторной записью? Она быстрее? (должна-быть по идее)
Имхо на ThP нет смысла мерять скорость первой записи, тк это ожидаемо медленнее.
— вы исплользуете размер блока 1MB, с последовательной записью/чтением. Какую нагрузку вы эмулируете данным способом?
Бэкап и восстановление?

Например, если вы хотите эмулировать базу данных, то надо делать тест c random и блок 8KB, если web, то что-то еще.

ps. производительность измеренная «dd», частый кошмар служб поддержки.

dyasny Jan 31 2014 at 09:45

вот вот, именно для этого есть целая куча программ типа bonnie++

funditus Jan 31 2014 at 09:55

— Выше написал. Повторюсь. Записывал 10 Гбайт. По идее должен был том расшириться. Об этом задумывался. Потом сразу туда же записывал 1 Гбайт. Результат тот же — скорость падает.
— Размер блока 1 Мбайт из ~~жизни~~ опыта. Для линейной записи/чтении dd выдаёт максимальную скорость при размере блока 1 или 2 Мбайта. Можно и больше, но по опыту скорость особо не возрастает при этом. При уменьшении — да, падает. Была цель получить максимальную скорость линейного чтения и записи, чтобы понять, можно ли использовать thin LV для контейнера с бэкапами (ну… такая задумка).
— Для эмуляции записи БД я использовал тест с fio, который не показал падения при этом производительности.

kachini Jan 31 2014 at 10:05

ok, я тож про бэкапы подумал.
Но скорость ввода-вывода редко меряют в MB/s.
Обычно, это все-таки iops и время отклика.

lovecraft Jan 31 2014 at 09:57

https://www.kernel.org/doc/Documentation/device-mapper/thin-provisioning.txt

Status
======

These targets are very much still in the EXPERIMENTAL state. Please
do not yet rely on them in production. But do experiment and offer us
feedback. Different use cases will have different performance
characteristics, for example due to fragmentation of the data volume.

If you find this software is not performing as expected please mail
dm-devel@redhat.com with details and we'll try our best to improve
things for you.

dyasny Jan 31 2014 at 10:01

я как раз выше об этом писал :)

Show the best of all time