Назад | Перейти на главную страницу

низкая производительность с vmdk, установленным как устройство петли, даже после преобразования в raw

Редактировать 13/12/12 - На данном этапе, похоже, это связано с размерами блоков Western Digital (и, возможно, другими) Advanced Format 4K.

Эта ссылка частично описывает проблему, однако диск, который у меня есть, сообщает о 512 логических и 4096 физических блоках (в отличие от 512/512).

http://johannes-bauer.com/linux/wdc/?menuid=3

Я продолжу тестирование, и если когда-нибудь найду решение, обязательно опубликую его.

У меня есть требование записывать большие объемы данных на диск vmdk, расположенный на диске USB3, подключенном к серверу Debian Linux. Я создаю сопоставления разделов с помощью kpartx, а затем монтирую созданные устройства цикла, например.

USB-диск / dev / sdb4 смонтирован в / mnt / backup.

> kpartx -av /mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk
add map loop2p1 (254:3): 0 273042 linear /dev/loop2 63
add map loop2p2 (254:4): 0 16787925 linear /dev/loop2 273105
add map loop2p3 (254:5): 0 8401995 linear /dev/loop2 17061030
add map loop2p4 (254:6): 0 184219648 linear /dev/loop2 25495552
add map loop2p5 : 0 227328 linear 254:6 2048
add map loop2p6 : 0 15998976 linear 254:6 231424
add map loop2p7 : 0 3059712 linear 254:6 16232448
add map loop2p8 : 0 2942976 linear 254:6 19294208
add map loop2p9 : 0 161978368 linear 254:6 22239232

Затем монтирую один из разделов.

> mkdir /mnt/loop2p2
> mount /dev/mapper/loop2p2 /mnt/loop2p2

И запустите тестовую запись данных в точку монтирования, также известную как второй раздел в vmdk.

> dd if=/dev/zero of=/mnt/loop2p2/zerofile.tst bs=1k count=1700000
1700000+0 records in
1700000+0 records out
1740800000 bytes (1.7 GB) copied, 135.871 s, 12.8 MB/s

Тест самого диска USB3 проходит нормально.

> dd if=/dev/zero of=/mnt/backup/zerofile.tst bs=1k count=1700000
1700000+0 records in
1700000+0 records out
1740800000 bytes (1.7 GB) copied, 19.5485 s, 89.1 MB/s

Для сравнения я создал файл необработанного изображения и провел тот же тест.

> qemu-img create -f raw /mnt/backup/raw.img 4G

После создания раздела ext3 на raw.img я смонтировал его и провел тест.

> kpartx -av /mnt/backup/raw.img
add map loop2p1 (254:3): 0 8386560 linear /dev/loop2 2048
> mkdir /mnt/loop2p1
> mount /dev/mapper/loop2p1 /mnt/loop2p1
> dd if=/dev/zero of=/mnt/loop2p1/zerofile.tst bs=1k count=1700000
1700000+0 records in
1700000+0 records out
1740800000 bytes (1.7 GB) copied, 23.3126 s, 74.7 MB/s

Хороший результат! немного медленнее, чем прямая запись на диск, но этого следовало ожидать.

Тогда я решил преобразовать vmdk в необработанное изображение, используя qemu-img в качестве другого сравнения.

> qemu-img convert /mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk -O raw /mnt/backup/3MSYDDP01/3MSYDDP01_3.raw

> kpartx -av /mnt/backup/3MSYDDP01/3MSYDDP01_3.raw
add map loop2p1 (254:3): 0 273042 linear /dev/loop2 63
add map loop2p2 (254:4): 0 16787925 linear /dev/loop2 273105
add map loop2p3 (254:5): 0 8401995 linear /dev/loop2 17061030
add map loop2p4 (254:6): 0 184219648 linear /dev/loop2 25495552
add map loop2p5 : 0 227328 linear 254:6 2048
add map loop2p6 : 0 15998976 linear 254:6 231424
add map loop2p7 : 0 3059712 linear 254:6 16232448
add map loop2p8 : 0 2942976 linear 254:6 19294208
add map loop2p9 : 0 161978368 linear 254:6 22239232
> mount /dev/mapper/loop2p2 /mnt/loop2p2
dd if=/dev/zero of=/mnt/loop2p2/zerofile.tst bs=1k count=1700000
1700000+0 records in
1700000+0 records out
1740800000 bytes (1.7 GB) copied, 129.653 s, 13.4 MB/s

Низкая производительность и с преобразованным диском.

Fdisk каждого диска выглядит следующим образом:

> fdisk -l /dev/sdb
Note: sector size is 4096 (not 512)

Disk /dev/sdb: 3000.6 GB, 3000558944256 bytes
255 heads, 63 sectors/track, 45599 cylinders, total 732558336 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000246c6

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1             256      131327      524288   83  Linux
/dev/sdb2          131328     2228479     8388608   83  Linux
/dev/sdb3         2228480     2490623     1048576   82  Linux swap / Solaris
/dev/sdb4         2490624   732558335  2920270848   83  Linux

raw.img

> fdisk -l /mnt/backup/raw.img

Disk /mnt/backup/raw.img: 4294 MB, 4294967296 bytes
43 heads, 32 sectors/track, 6096 cylinders, total 8388608 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd48075ee

              Device Boot      Start         End      Blocks   Id  System
/mnt/backup/raw.img1            2048     8388607     4193280   83  Linux

3MSYDDP01_3-flat.vmdk

> fdisk -l /mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk

Disk /mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005cbed

                                      Device Boot      Start         End      Blocks   Id  System
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk1   *          63      273104      136521   83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk2          273105    17061029     8393962+  83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk3        17061030    25463024     4200997+  82  Linux swap / Solaris
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk4        25495552   209715199    92109824    5  Extended
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk5        25497600    25724927      113664   83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk6        25726976    41725951     7999488   83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk7        41728000    44787711     1529856   83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk8        44789760    47732735     1471488   83  Linux
/mnt/backup/3MSYDDP01/3MSYDDP01_3-flat.vmdk9        47734784   209713151    80989184   83  Linux

Изменить: размер блока разделов в vmdk:

> dumpe2fs /dev/mapper/loop2p1 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               1024
> dumpe2fs /dev/mapper/loop2p2 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               4096
> dumpe2fs /dev/mapper/loop2p5 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               1024
> dumpe2fs /dev/mapper/loop2p6 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               4096
> dumpe2fs /dev/mapper/loop2p7 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               4096
> dumpe2fs /dev/mapper/loop2p8 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               4096
> dumpe2fs /dev/mapper/loop2p9 | grep -i 'block size'
dumpe2fs 1.42.5 (29-Jul-2012)
Block size:               4096

/ dev / mapper / loop2p3 - это подкачка.

/ dev / mapper / loop2p4 - это расширенный раздел.

Может ли повлиять размер сектора USB-диска? Если да, то почему необработанное изображение подойдет? Я посмотрю на тестирование с USB-диском с размером сектора 512, но это займет время, поскольку мне нужно скопировать данные, отформатировать и скопировать обратно.

Не создавайте резервную копию всей виртуальной машины. В зависимости от приложения вы должны иметь возможность выполнять репликацию на уровне приложения. Также простое заполнение файла VMDK через rsync - это не то же самое, что резервное копирование виртуальной машины. Существуют нематериальные активы, такие как используемые заблокированные файлы, базы данных (если применимо) и файлы конфигурации, которые, возможно, потребуется скопировать отдельно.

В целом это плохая идея, и она, вероятно, не предоставит план восстановления, которого ожидают ваши работодатели. Кроме того, в производство не входят внешние USB-накопители.