|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Guchenko 2:5020/400 03 Dec 2007 14:59:15
To : All
Subject : Исследование производительности UFS
--------------------------------------------------------------------------------
Конфигурация тестового сервера:
* FreeBSD 6.2-20070912-SNAP
* AMD Athlon(tm) 64 Processor 3500+
* real memory = 3756916736 (3582 MB)
Hа сервере по крону раз в 5 минут запускается некое приложение, которое
обновляет/пересоздает на диске большое количество мелких файлов (порядка
40 тысяч). Размеры файлов от 0 до 250 KB. Файлы записываются на файловую
систему UFS2 обычного SATA диска (adN, 80 GB). Кроме описываемого
приложения к этому диску больше никто не обращается. Hет никаких зеркал
или страйпов. Hа сервере также работает демон, который раз в 5 минут
считывает показания счетчика записанных на диск байтов (через библиотеку
devstat). Эти данные передаются в мониторинг, который рисует на графике
hdd write transfer rate - среднюю скорость записи на диск в байтах в
секунду. Там же рисуется hdd busy rate - среднее количество времени в
процентах, которое диск был занят какими-нибудь операциями.
Я создавал через newfs файловые системы UFS с различными размерами блока
(параметр -b) и фрагмента (параметр -f) и в течение нескольких часов
наблюдал за производительностью работы с диском через мониторинг. Soft
updates всегда были включены, оптимизация всегда по времени, версия UFS
всегда 2. Hапомню, что man newfs рекомендует задавать размер фрагмента,
равный 1/8 от размера блока. Я пробовал задавать другие соотношения -
становилось хуже.
При минимальных размерах блока (4096) и фрагмента (512) на диск пишется
в среднем 1,1 MB/s. При этом busy rate диска составляет порядка 54%. И
один цикл работы приложения занимает в среднем 204 секунды. При плавном
увеличении размера блока и фрагмента (с сохранением соотношения 1/8)
характеристики записи улучшаются: загрузка диска уменьшается, время
работы одного цикла приложения уменьшается, но количество записываемых
на диск байтов увеличивается. После достижения некоторого оптимума
дальнейшее увеличение размера блока и фрагмента приводит к ухудшению
характеристик. Hиже я выписал все измеренные значения:
newfs -U -b 4096 -f 512
work time: 204 s, busy rate: 54%, write rate: 1.12 MB/s
newfs -U -b 8192 -f 1024
work time: 172 s, busy rate: 42%, write rate: 1.50 MB/s
newfs -U -b 16384 -f 2048
work time: 155 s, busy rate: 35%, write rate: 1.77 MB/s
newfs -U -b 32768 -f 4096
work time: 148 s, busy rate: 32%, write rate: 3.00 MB/s
newfs -U -b 65536 -f 8192
work time: 157 s, busy rate: 34%, write rate: 4.21 MB/s
Hаконец последний случай, где размер блока и фрагмента оба равны 65536:
newfs -U -b 65536 - f 65536
work time: 192 s, busy rate: 44%, write rate: 9.10 MB/s
Мне непонятно одно. Почему при увеличении размера фрагмента многократно
увеличивается объем данных, записываемых на диск? При минимальном
размере фрагмента (512 байт) запись на диск происходит со средней
скоростью 1.12 MB/s. Т.е. за один цикл работы приложения должно
записаться порядка 1.12 MB/s * 300 s = 336 MB. Если же размер фрагмента
равен 65536 байт, то запись идет со средней скоростью 9.10 MB/s, т.е. за
один цикл работы приложения записывается порядка 9.10 MB/s * 300 s =
2730 MB. Почти в 9 раз больше! Полезные данные те же самые, их объем и
структура не менялись. Откуда берутся лишние 2,4 гига?
Кстати, при размере фрагмента 65536 байт диск становится очень
чувствительным к параллельным процессам, а система активно свопится (это
при 3,5 мегабайтах памяти!). Стоит запустить параллельно скрипт,
создающий на этом же диске около 1000 мелких файлов, busy rate
подпрыгивает с 44% до 85%, write rate с 9.10 MB/s до 13.00 MB/s, а время
работы приложения увеличивается с 192 секунд до 315. При маленьких
размерах фрагмента таких резких скачков незаметно. Видимо сказывается
как раз огромный объем информации, который пишется на диск. У меня есть
предположение, что возможно система всегда записывает фрагмент на диск
целиком, независимо от того, сколько фактически байт в нем занято. Так
ли это и какой в этом смысл?
--
Best regards, Vadim.
--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
