Обнаружил снижение производительности (скорости записи) на LVM2 Logical Volume, при подключенном snapshot. Измеренная скорость записи на Logical Volume, падает в 10 раз, если существует активный snapshot этого Logical Volume.##########
### тестовый сервер HP Proliant 320s, контроллер P400, 9 x 1TB SATA в RAID6, кэш в контроллере на запись включен, Centos 5.4 x86_64
############# Создаем LV
[root@server5 ~]# lvcreate -L10G -n lv1 /dev/VolGroup01
Logical volume "lv1" created### Заполняем LV нулями и смотрим скорость
[root@server5 ~]# dd if=/dev/zero of=/dev/VolGroup01/lv1 bs=1M
dd: запись `/dev/VolGroup01/lv1': На устройстве кончилось место
скопировано 10737418240 байт (11 GB), 57,5659 секунд, 187 MB/s### Создаем снапшот. С этого момента у тома lv1 есть ОДИН снапшот.
[root@server5 ~]# lvcreate -s -L10G -n snap_lv1 /dev/VolGroup01/lv1
Logical volume "snap_lv1" created### Cнова заполняем нулями том-оригинал lv1
### (имитируем запись обновленных блоков данных в Logical VOlume)
### разница с первым заполнением нулями в том, что теперь у тома есть снапшот
[root@server5 ~]# dd if=/dev/zero of=/dev/VolGroup01/lv1 bs=1M count=5000
скопировано 5242880000 байт (5,2 GB), 936,033 секунд, 5,6 MB/sИтак, имеем скорость заполнения нулями тома оригинала - 187 MB/s, а при подключенном снапшоте - 5,6 МБайт/сек. Разница значительная, и откуда она берётся?
##########
### HP Proliant DL380, P400 512Mb, кэш в контроллере на запись включен, 7 SAS дисков в RAID5, и вот что получилось:
##########
без снапшота 10737418240 bytes (11 GB) copied, 90.4289 seconds, 119 MB/s
с снапшотом: окончания заполнения нулями LV1 не дождался.##########
### Попробовал на обычном системнике:
############# У тома lv1 нет снапшотов:
dd if=/dev/zero of=/dev/vg_server1/lv1
скопировано 5368709120 байт (5,4 GB), 440,062 секунд, 12,2 MB/s### у тома lv1 есть ОДИН снапшот:
dd if=/dev/zero of=/dev/vg_server1/lv1
скопировано 1738539008 байт (1,7 GB), 396,974 секунд, 4,4 MB/s-----------------------
Итак, что имеем:
При наличие у LVM2 Logical Volume снапшота:
1) скорость записи на Logical Volume падает в разы, иногда на порядок; фактически такие скорости записи неприемлемы для нормальной работы сервера;
2) по время записи в Logical Volume, в процессах висит процесс ядра [kcopyd], в таком же количестве, сколько у тома есть снапшотов
3) утилизация ОС поднимается до значений 8-9 попугаев (измерено в top и uptime), ответа от утилиты lvm можно ждать часами, всем остальным процессам на сервере становится очень печально;А теперь вопрос:
- нормально ли такое положение дел с снапшотами, кто уже сталкивался с подобным практически?
- если кто-то попробует воспроизвести данную ситуацию - то воспроизводима ли она на других ОС и версиях LVM2 ?
проблема известна :)вот, например, описание:
http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-.../или вот:
http://www.nikhef.nl/~dennisvd/lvmcrap.htmlобесчают исправить, но пока не исправили, насколько мне известно.
>А теперь вопрос:
>- нормально ли такое положение дел с снапшотами, кто уже сталкивался с
>подобным практически?
>- если кто-то попробует воспроизвести данную ситуацию - то воспроизводима ли она
>на других ОС и версиях LVM2 ?Да, проблема известная. Мы используем LVM-снапшоты только для бэкапов и ночью, когда активного ввода-вывода, особенно на запись, нет, или если сервер не сильно прогружен по диску, тогда в любое время.
Снапшоты вполне успешно используются, например, для бэкапа OVZ-контейнеров. Да, конечно, ночью iowait возрастает, но все остается в рамках разумного.
На самом деле пользоваться можно, но для баз данных, дергающих дисковую 7/24/365 во много потоков, все равно лучше DAS/SAN для HA да и производительности....
У кого под рукой хороший FreeBSD сервер, и тема интересует - можете подтвердить - есть ли значительное ухудшение производительности ФС при наличии снапшотов? (уже не LVM снапшотов)
>У кого под рукой хороший FreeBSD сервер, и тема интересует - можете
>подтвердить - есть ли значительное ухудшение производительности ФС при наличии снапшотов?
>(уже не LVM снапшотов)В BTRFS снапшоты, вроде как, ОК и LVM глядя на это думает исправиться.
Про UFS - лучш откройте новую ветку.
http://lwn.net/Articles/358940/Doing snapshots at the device mapper/LVM layer involves making a lot more copies of the relevant data. Chris ran an experiment where he created a 400MB file, created a bunch of snapshots, then overwrote the file. Btrfs is able to just write the new version, while allowing all of the snapshots to share the old copy. LVM, instead, copies the data once for each snapshot. So this test, which ran in less than two seconds on Btrfs, took about ten minutes with LVM.
>Да, проблема известная. Мы используем LVM-снапшоты только для бэкапов и ночью, когда
>активного ввода-вывода, особенно на запись, нет, или если сервер не сильно
>прогружен по диску, тогда в любое время.
>
>Снапшоты вполне успешно используются, например, для бэкапа OVZ-контейнеров. Да, конечно, ночью iowait
>возрастает, но все остается в рамках разумного.
>
>На самом деле пользоваться можно, но для баз данных, дергающих дисковую 7/24/365
>во много потоков, все равно лучше DAS/SAN для HA да и
>производительности....Собственно, секрет в том, что бы после окончания бэкапов на удаленный хост удалить снапшот, а не "хранить его на всякий случай", и тогда все будет хорошо :)
Ну или хранить на тестовой машине, которую Вы мучаете для создания, например, кикстарта, где плевать на производительность.Если нужно именно хранение снапшотов для нагруженной дисковой, имхо, ничего лучше СХД еще не сделали.
Снапшот может хранится не "на всякий случай", а например для предоставления клиентам Windows XP в виде Shadow Copy с помощью Samba и vfs_object = shadow_copyПри таком использовании снапшот может быть даже не один, а штук десять. Соответственно производительность Logical Volume-оригинала упадёт в десятки раз.
В интернетах много примеров совместного использования Samba vfs shadow_copy и LVM snapshot, вот даже на офсайте самбы:
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/V...
http://www.wlug.org.nz/SambaShadowCopyHowtoИнтересно, авторы примеров пробовали их на рабочих системах, либо ограничились хранением директории с домашними фотографиями ? :)
>[оверквотинг удален]
>При таком использовании снапшот может быть даже не один, а штук десять.
>Соответственно производительность Logical Volume-оригинала упадёт в десятки раз.
>
>В интернетах много примеров совместного использования Samba vfs shadow_copy и LVM snapshot,
>вот даже на офсайте самбы:
>http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/V...
>http://www.wlug.org.nz/SambaShadowCopyHowto
>
>Интересно, авторы примеров пробовали их на рабочих системах, либо ограничились хранением директории
>с домашними фотографиями ? :)Я так и подумала, что Вы имеете ввиду именно аналог Shadow Copy на виндовых файлопомойках, но... Так ли она реально нужна? Все равно пользовательские файлы нужно бэкапить на независимый носитель, это аксиома, и бэкапить регулярно, иначе может случиться нечто очень плохое.
И подозреваю, что мощный контроллер с батарейкой и кэшем под гигабайт решит проблемы производительности и LVM-снапшотов (конечно, это бюджет, но SOHO сегменту, которому это недоступно, и бэкапов хватит)
> аналог Shadow Copy на виндовых файлопомойках, но... Так ли она реально нужна?Нужна. Все пользовательские файлы несомненно, бэкапятся на резервный сервер и на ленту, но, пользователям нужна возможность самостоятельно восстановить файлы до состояния "день назад", "неделю назад", и "месяц назад". На Windows 2003 server это настраивается легко, причем без заметной потери производительности (Volume Shadow Copy). Пользователи (фирма на контракте) - ОЧЕНЬ РАДЫ реализованной возможности:). хотелось бы такого-же и на Linux :) отсюда и поднял тему.
> И подозреваю, что мощный контроллер с батарейкой и кэшем под гигабайт решит проблемы производительности и LVM-снапшотов
Я тестировал на HP Proliant DL380G5 с 10k SAS-дисками, с RAID-контроллером P400, с кэшем 512 Мб, - и в такой конфигурации проблемы не легче, по сравнению с обычным ПК.
>[оверквотинг удален]
>"неделю назад", и "месяц назад". На Windows 2003 server это настраивается
>легко, причем без заметной потери производительности (Volume Shadow Copy). Пользователи (фирма
>на контракте) - ОЧЕНЬ РАДЫ реализованной возможности:). хотелось бы такого-же и
>на Linux :) отсюда и поднял тему.
>
>> И подозреваю, что мощный контроллер с батарейкой и кэшем под гигабайт решит проблемы производительности и LVM-снапшотов
>
>Я тестировал на HP Proliant DL380G5 с 10k SAS-дисками, с RAID-контроллером P400,
>с кэшем 512 Мб, - и в такой конфигурации проблемы не
>легче, по сравнению с обычным ПК.Наверное, решением Ваших проблем станет ZFS и (Open)Solaris, на фре я бы его еще побоялась юзать(сейчас прибегут фревые красноглазики, их как бы не больше, чем красноглазиков линуксовых, и начнут рассказывать, сколько месяцев у них все работает хорошо, но, по-моему, все-таки прошло слишком мало времени после релиза, что бы это где-то использовать)
И да, можно у народа с нагруженными файлопомойками на фряхе, можно спросить про UFS снапшоты, но в ней журналы появились только-только (еще не слышала, что бы кто-то их использовал), а файлопомойку использовать без журнала лично мне страшно...
У Вас не выявилось корреляции от используемой файловой системы? Мой опыт говорит мне, что XFS и Samba для файлопомоек самое производительное решение, но, может быть, не все от lvm зависит?
> И да, можно у народа с нагруженными файлопомойками на фряхе, можно спросить
> про UFS снапшоты, но в ней журналы появились только-только (еще не
> слышала, что бы кто-то их использовал), а файлопомойку использовать без журнала
> лично мне страшно...А почему вы боитесь использовать CoW-файловые системы (сюда относятся ZFS и UFS2 с включенным Soft Updates)? Они по факту своего существавания и работы не нуждаются в журнале транзакций.
> У Вас не выявилось корреляции от используемой файловой системы? Мой опыт говорит
> мне, что XFS и Samba для файлопомоек самое производительное решение, но,
> может быть, не все от lvm зависит?Samba тормознее NFS раза в три, если не больше.