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

[amarao]

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

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

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

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

[funditus]

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

[dyasny]

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

[funditus]

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

[dyasny]

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

[funditus]

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

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

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

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

[dyasny]

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

[funditus]

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

[dyasny]

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

[funditus]

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

[dyasny]

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

[kachini]

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

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

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

[dyasny]

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

[funditus]

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

[kachini]

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

[lovecraft]

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
[e-mail] with details and we'll try our best to improve
things for you.

[dyasny]

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