Создание снимка LXD ZFS замедляется как количество увеличений снимков
Ubuntu 18.04 LTS - LXD запуск Ubuntu с помощью обратной петли ZFS (приблизительно 400 МБ)
# lxc launch ubuntu:16.04 test -s ianzfspool
(У меня есть еще один неактивный контейнер мульти-ГБ использование того же ianzfspool.) У меня есть много пространства в пуле:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
ianzfspool 99.5G 13.7G 85.8G - 2% 13% 1.00x ONLINE -
Если я циклично выполняюсь, с помощью lxc для создания снимков неактивного тестового контейнера (400 МБ) первые создают за несколько секунд. Как количество lxc снимки растут (в настоящее время более чем 1 200), теперь они занимают минуты для создания. У меня есть сценарий, работающий в тестовом контейнере, который помещает текущую дату в файл в/tmp каждые несколько секунд, таким образом, у меня есть один файл, который изменяется в контейнере в каждом снимке; иначе контейнер главным образом неактивен. Первое lxc снимки используются о 25K; текущие (после того, как 1 200 снимков) используют 66K. (После того, как 2 470 снимков, каждый из них использует 115K и после 7 500 снимков, каждый из них использует 293K.)
#!/bin/sh -u
# Create snapshots of the Ubuntu test container.
count=0
while : ; do
count=$(( count + 1 ))
cp=$( printf "%05d" $count )
lxc snapshot test snap$cp
echo "$0: done $cp" >/tmp/icount.txt
done
Редактирование 1: Я в настоящее время готов приблизительно к 2 470 lxc снимки и каждый новый снимок занимают приблизительно четыре минуты для создания и использование о 115K. Если я звоню zfs snapshot взять снимок контейнера непосредственно, вместо использования lxc snapshot, снимок берет меньше, чем секунда, даже с 2 470 существующими снимками. Прямое zfs создайте снимки только использование 20K (вместо 115K). Выполнение zfs list занимает только секунду или два. Если я работаю lxc list (вместо zfs list), это в настоящее время принимает четыре минуты с 2 470 существующими снимками. Таким образом, создание снимка и перечисляющий замедление не с ZFS, это с LXD. Действительно, lxd сам процесс использовал 4 253 секунды ЦП и имеет VSIZE 3.9G до сих пор в этом эксперименте создания снимка.
Я приостановился lxc сценарий создания снимка и записал в цикл, создающий прямой zfs снимки, и это создало больше снимков за пять минут, чем lxc имеет за три дня. Я приостановил его приблизительно после 3 000 прямых снимков ZFS.
Я просто повторно выполнился lxc list и конечно это все еще только показывает 2,471 lxc снимки, но теперь это работало только через 40 секунд вместо четырех минут. Я просто создал другого lxc snapshot и только потребовалось 49 секунд вместо четырех минут. Что изменилось? Имеет создание набора прямых zfs снимки так или иначе ускорены lxc создание снимка и список? lxc снимки являются все еще путем медленнее для создания, чем прямой zfs снимки, но что-то улучшилось с lxc создание снимка (от четырех минут до 49 секунд).
Я позволяю ZFS создать снимки создание, продолжаются, пока 10,000 прямых снимков ZFS не были созданы. (Таким образом, теперь я имею 2,472 lxc снимки и 10 000 прямых zfs снимки этого тестового контейнера.) lxc list теперь занимает 90 секунд (вместо 40) и lxc snapshot занимает 100 секунд (вместо 49). Используя ZFS непосредственно все еще два порядка величины быстрее, чем движение через LXD.
Редактирование 2: После перезагрузки убыстрилось создание снимка LXD. Я в 7 470 снимках, созданных через мой lxc snapshot цикл и каждый снимок теперь занимают приблизительно 30 секунд для создания и имеют размер 293K. lxc list занимает 45 секунд. zfs list занимает 105 секунд и продолжает 17 507 линий вывода (который включает 10,000 прямых снимков ZFS). Выполнение zfs snapshot ianzfspool/containers/test@iansnap10001 непосредственно (не через LXD) занимает меньше чем половину секунды - еще намного быстрее, чем через LXD.
Где я могу найти документацию относительно того, почему создание снимка LXD замедляется, и как я мог бы ускорить вещи? (Если LXD со снимками ZFS были столь дешевыми, как я велся верить, я надеялся выполнить снимки каждые 5 минут и сохранить их приблизительно в течение недели, которая будет 2 016 снимками. Я считал, что снимки LVM являются потерей производительности, но ничто, что я считал, не сказало то же о LXD с ZFS. Я вижу, что мог обойти LXD и использовать снимки ZFS, но почему я должен сделать это? Действительно ли LXD является закрепляемым?)
lxd процесс на хосте использует много CPU и становится большим (это после 1 200 снимков):
PID VSTACK VSIZE RSIZE PSIZE VGROW RGROW SWAPSZ MEM CMD 1/8
10663 132K 3.7G 1.1G 0K 0K 0K 2580K 14% lxd
1 ответ
У меня нет опыта с lxd snapshot, таким образом, лучшее, которое я могу сделать, предположить о его реализации и сказать Вам больше деталей о снимках ZFS.
Снимки ZFS разработаны так, чтобы они не добавляли издержек к продолжающимся чтениям и записям. (Как Вы упомянули, снимки LVM действительно добавляют потерю производительности, в форме усиления записи.) Для достижения этого ZFS начинает внутреннюю операцию, названную a txg_sync который похож на пакетную запись всей недавней асинхронной iOS, и это происходит автоматически каждые 10 секунд, а также любое время изменения структуры файловой системы (такой как тогда, когда Вы берете снимок). Это заставляет набор iOS происходить, таким образом, в теории может вызвать замедление параллельных синхронных записей из-за перегрузки (хотя синхронизирующие записи должны получить приоритет). Однако кажется, что Вы почти ничего не записали в свою файловую систему (и по-видимому не намного больше к остальной части пула).
Мое предположение - то, что это - на самом деле чтения метаданных, которые становятся медленными. В теории, lxd snapshot мог просто взять снимок ZFS и продолжать идти, который должен взять константу (принятие постоянной загрузки IO) количество времени. Однако я предполагаю, что это также пытается перечислить все снимки во время той операции (эквивалентный zfs list), и это включает чтение целого набора метаданных для каждого снимка, который часто распространяется на всем протяжении пула и растет линейно с количеством снимков. Для проверки, если это так, Вы могли попытаться синхронизировать a zfs snapshot в файловой системе непосредственно и выполнении a zfs list -t all в файловой системе и ее снимках, и видят, какой берет путь путь дольше, чем другой (должен быть второй).
В сообществе ZFS это - что-то вроде известной проблемы, но трудно зафиксировать, потому что это включило бы изменение большого количества дисковых структур метаданных для улучшения, и хранение этого, много снимков довольно необычны. Если lxd попробованный тяжелее, чтобы не перечислять все снимки для выполнения его операции снимка я думаю, что это могло решить проблему.
Поочередно, Вы могли брать снимки каждые 5 минут, но затем удалять их относительно быстро и только сохранять (например), 5 м, 10 м, 15 м, 30 м, 1 ч, 2 ч, 3 ч, 6-е, 12-е, 24-е, и т.д. создают снимки. Это дает Вам высокое разрешение во время окна, когда наиболее вероятно, что Вы нуждались бы в нем и также не вызовете lxd snapshot замедлиться.