И хостовая, и гостевая ОС - Debian 8 amd64. Гость - это необработанный образ диска, хранящийся в /srv/machines/web.img. У хоста есть сценарий резервного копирования, запланированный каждую ночь в 1:55. Вот мой сценарий резервного копирования:
#!/bin/bash
BACKDIR='/srv/backups'
BACKFILENAME='web.img'
# Let's rotate the backups and delete the oldest one
for i in `seq 8 -1 0` ; do
if [ -f "$BACKDIR"/"$BACKFILENAME"-$i ] ; then
mv "$BACKDIR"/"$BACKFILENAME"-$i "$BACKDIR"/"$BACKFILENAME"-$(($i + 1))
fi
done
rm -f "$BACKDIR"/"$BACKFILENAME"-9
# Hold guest writes in a temp COW file
virsh snapshot-create-as --domain web bsnap --diskspec vda,file=/srv/machines/bsnap.qcow2 --disk-only --atomic --quiesce
# Make backup of the guest RAW image
cp -a /srv/machines/"$BACKFILENAME" "$BACKDIR"/"$BACKFILENAME"-0
# commit guest writes to the usual RAW file
virsh blockcommit web vda --active --verbose --pivot
График ожидания ввода-вывода ЦП Zabbix показывает, что резервное копирование занимает около 1 часа. Каждую ночь в течение этого периода времени, но в разное время, я получаю сообщения ядра (не уверен, что они действительно есть) в гостевой виртуальной машине, например:
Jul 4 02:13:59 web kernel: [83400.216115] INFO: task jbd2/dm-0-8:200 blocked for more than 120 seconds.
Jul 4 02:13:59 web kernel: [83400.216485] Not tainted 3.16.0-4-amd64 #1
Jul 4 02:13:59 web kernel: [83400.216817] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 4 02:13:59 web kernel: [83400.217427] jbd2/dm-0-8 D ffff880efef1dac8 0 200 2 0x00000000
Jul 4 02:13:59 web kernel: [83400.217433] ffff880efef1d670 0000000000000046 0000000000012f00 ffff880efef87fd8
Jul 4 02:13:59 web kernel: [83400.217437] 0000000000012f00 ffff880efef1d670 ffff880f3fcb37b0 ffff880f3ff7a5e8
Jul 4 02:13:59 web kernel: [83400.217441] 0000000000000002 ffffffff811d7620 ffff880efef87c80 ffff8800bbba8b98
Jul 4 02:13:59 web kernel: [83400.217444] Call Trace:
Jul 4 02:13:59 web kernel: [83400.217454] [<ffffffff811d7620>] ? generic_block_bmap+0x50/0x50
Jul 4 02:13:59 web kernel: [83400.217460] [<ffffffff815114a9>] ? io_schedule+0x99/0x120
Jul 4 02:13:59 web kernel: [83400.217464] [<ffffffff811d762a>] ? sleep_on_buffer+0xa/0x10
Jul 4 02:13:59 web kernel: [83400.217468] [<ffffffff8151182c>] ? __wait_on_bit+0x5c/0x90
Jul 4 02:13:59 web kernel: [83400.217471] [<ffffffff811d7620>] ? generic_block_bmap+0x50/0x50
Jul 4 02:13:59 web kernel: [83400.217474] [<ffffffff815118d7>] ? out_of_line_wait_on_bit+0x77/0x90
Jul 4 02:13:59 web kernel: [83400.217480] [<ffffffff810a7e90>] ? autoremove_wake_function+0x30/0x30
Jul 4 02:13:59 web kernel: [83400.217498] [<ffffffffa00c542e>] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
Jul 4 02:13:59 web kernel: [83400.217507] [<ffffffff810a2f21>] ? pick_next_task_fair+0x6e1/0x820
Jul 4 02:13:59 web kernel: [83400.217514] [<ffffffffa00c8be2>] ? kjournald2+0xb2/0x240 [jbd2]
Jul 4 02:13:59 web kernel: [83400.217518] [<ffffffff810a7e60>] ? prepare_to_wait_event+0xf0/0xf0
Jul 4 02:13:59 web kernel: [83400.217524] [<ffffffffa00c8b30>] ? commit_timeout+0x10/0x10 [jbd2]
Jul 4 02:13:59 web kernel: [83400.217530] [<ffffffff8108809d>] ? kthread+0xbd/0xe0
Jul 4 02:13:59 web kernel: [83400.217534] [<ffffffff81087fe0>] ? kthread_create_on_node+0x180/0x180
Jul 4 02:13:59 web kernel: [83400.217539] [<ffffffff81514958>] ? ret_from_fork+0x58/0x90
Jul 4 02:13:59 web kernel: [83400.217543] [<ffffffff81087fe0>] ? kthread_create_on_node+0x180/0x180
Как следствие, убивается какой-то случайный процесс (прошлой ночью был механизм базы данных ...). Я недостаточно опытен, чтобы расшифровать то, что на самом деле произошло с гостевым ядром, но это 120 seconds с участием jbd2 в той же строке заставляет меня подозревать, что виноват какой-то тайм-аут файловой системы. Теперь, предполагая, что мой подозреваемый идет в правильном направлении, я полагаю, что сценарий резервного копирования хоста сильно влияет на производительность ввода-вывода в гостевой системе.
Обратите внимание, что хост-машина имеет 256 ГБ оперативной памяти, гостевой образ имеет размер 180 ГБ и почти весь гостевой образ хранится в ОЗУ (vmtouch показывает цифры от 90 до 98% кэшированного). Я не могу сказать о временном файле COW, но, даже если бы он хранился на диске, мне кажется, что 120 секунд - это слишком много, чтобы его можно было оправдать программными дисками SATA уровня RAID1 6 ГБ / с. Более того, журналы ОС хоста не показывают ничего, что могло бы заставить меня подозревать проблемы с производительностью дискового ввода-вывода. В то время нагрузка на сервер - это только то, что делает сценарий резервного копирования и ничего больше.
Есть ли в моем сценарии резервного копирования что-нибудь, что может вызвать такие проблемы?