Продуктивність файлових систем Loopback


10

Хто-небудь робив якісь тести на ефективність / тестування на файлові системи з циклічною підтримкою Linux? Який ваш досвід був поки що. Чи є якась погіршення продуктивності? Як щодо надійності?

http://freshmeat.net/articles/virtual-filesystem-building-a-linux-filesystem-from-an-mediate-file


Запустити bonnie ++ на рідному диску та на зворотному диску, слід досить просто, щоб порівняти продуктивність.
ceving

Відповіді:


11

Я зробив трохи бенчмаркінгу з операціями запису в циклічному пристрої. Ось висновок:

  • Якщо ви синхронізуєтесь після кожного запису, тоді пристрій циклічного зворотного зв’язку працює значно гірше (майже вдвічі повільніше).
  • Якщо ви дозволите дисковому кешу планувальнику вводу-виводу виконувати свою роботу, то навряд чи є різниця між використанням пристрою зворотного зв'язку та прямим доступом до диска.

Результати порівняння

По-перше, я запустив орієнтир на циклічному пристрої в tmpfs 8 Гб і на пристрої для зворотного зв'язку в цьому пристрої для зворотного циклу ( з синхронізацією після кожної операції запису ):

ext4 в tmpfs:

Measured speed: 557, 567, 563, 558, 560, 559, 556, 556, 554, 557
Average speed : 558.7 MB/s  (min 554  max 560)

ext4 в extf в tmpfs:

Measured speed: 296, 298, 295, 295, 299, 297, 294, 295, 296, 296
Average speed : 296.1 MB/s  (min 294  max 299)

Зрозуміло, є деяка різниця в продуктивності при використанні пристроїв зворотного зв'язку з синхронізацією при записі.
Потім я повторив той же тест на своєму HDD.
ext4 (HDD, 1000 Мб, 3 рази):

Measured speed: 24.1, 23.6, 23.0
Average speed : 23.5 MB/s  (min 23.0  max 24.1)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 12.9, 13.0, 12.7
Average speed : 12.8 MB/s  (min 12.7  max 13.0)

Той самий орієнтир на HDD, тепер без синхронізації після кожного запису ( time (dd if=/dev/zero bs=1M count=1000 of=file; sync)вимірюється як <size>/ <time in seconds>).
ext4 (HDD, 1000 МБ):

Measured speed: 84.3, 86.1, 83.9, 86.1, 87.7
Average speed : 85.6 MB/s  (min 84.3  max 87.7)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 89.9, 97.2, 82.9, 84.0, 82.7
Average speed : 87.3 MB/s  (min 82.7  max 97.2)

(дивно, що показник зворотного циклу виглядає краще, ніж тест із необробленим диском, імовірно, через менший розмір пристрою зворотного звороту, тому менше часу витрачається на фактичну синхронізацію на диск)

Налаштування еталону

По-перше, я створив файлову систему із зворотним циклом 8G у моєму / tmp (tmpfs):

truncate /tmp/file -s 8G
mkfs.ext4 /tmp/file
sudo mount /tmp/file /mnt/
sudo chown $USER /mnt/

Потім я встановив базову лінію, заповнивши змонтований файл циклу даними:

$ dd if=/dev/zero bs=1M of=/mnt/bigfile oflag=sync
dd: error writing '/mnt/bigfile': No space left on device
7492+0 records in
7491+0 records out
7855763456 bytes (7.9 GB) copied, 14.0959 s, 557 MB/s

Після цього я створив ще один пристрій зворотного зв'язку в попередньому пристрої циклу:

mkdir /tmp/mountpoint
mkfs.ext4 /mnt/bigfile
sudo mount /mnt/bigfile /tmp/mountpoint
sudo chown $USER /tmp/mountpoint

І запустив тест знову, десять разів:

$ dd if=/dev/zero bs=1M of=/tmp/mountpoint/file oflag=sync
...
7171379200 bytes (7.2 GB) copied, 27.0111 s, 265 MB/s

а потім я відключив тестовий файл і видалив його:

sudo umount /tmp/mountpoint
sudo umount /mnt

(аналогічно для тесту на жорсткому диску, за винятком того, що я також додав, count=1000щоб тест не заповнив весь мій диск)
(і для тесту, який не записує синхронізацію, я запустив присвоєний час ddі syncоперацію)


0

У мене не було проблем. Це все було непомітно. Кеш файлової системи та планувальник вводу-виводу в Linux достатньо розумні, що вона не повинна робити помітної різниці між запитом на диск безпосередньо і запитом розділу файлу на диску.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.