LXF111:DrBrown2
|
|
|
Содержание |
Поджарый или раздутый?
- Bonnie++ Управляемый способ измерить производительность файловой системы.
Вы когда-нибудь задумывались над тем, как настройки файловых систем влияют на их производительность? Будет ли быстрее создать их непосредственно в разделе или на логических дисках? Насколько возрастает нагрузка на ресурсы, если файловая система предоставляется хост-ОС в виртуальной среде? Медленнее ли USB-брелки и сетевые устройства хранения данных, чем локальные диски? Стоит ли размещать файл журнала ext3 на отдельном устройстве?
Чтобы ответить на подобные вопросы, нужен способ измерения производительности файловой системы. Одно из решений проблемы – Bonnie++. Эту утилиту написал Рассел Кокер [Russell Coker] (см. http://www.coker.com.au/bonnie++); она основана на другой программе, которая называется (угадайте, как?) Bonnie и написана Тимом Греем [Tim Gray]. Хотя бинарные файлы Bonnie++ есть в репозиториях большинства дистрибутивов Linux, можно легко скомпилировать их из исходников. Загрузите tar-архив по ссылке на странице Рассела Кокера. Мы скачали файл bonnie++-1.03d.tgz в подходящий каталог. Собрать программу не составило труда:
$ wget http://www.coker.com.au/bonnie++/bonnie++-1.03d.tgz $ tar xzf bonnie++-1.03d.tgz $ cd bonnie++-1.03d $ make
Как пользоваться Bonnie++
На man-странице перечислены некоторые опции настройки параметров тестирования. В частности, -d позволяет указать каталог, для которого будут выполняться все действия; понятно, что нужно указать каталог внутри точки монтирования файловой системы, характеристики которой нужно получить. Также можно задать пользователя, от имени которого будут производиться тесты, и общее количество циклов, которые будут выполнены. Вот пример запуска:
$ bonnie++ -m ‘USB IDE’ -d /media/disk -n 1:1024:0:10 > bonnie.out Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start ‘em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done.
Опции команды, которые я в нем использовал, перечислены ниже:
- -m: Указать текстовую метку для данного набора результатов. По умолчанию – имя машины.
- -d: Указать тестируемый каталог
- -n: Указать (a) использовать набор из 1024 файлов для теста по созданию файла, (b) использовать максимальный размер файла 1024 байт, (c) использовать минимальный размер файла 0 байт, и (d) распределить эти файлы по 10 каталогам.
Bonnie++ измеряет производительность трех типов операций: скорости чтения и записи, число обращений к диску в секунду и число операций с метаданными (таких как создание и удаление файла) в секунду. Так как использование файловой системы сильно зависит от компьютера, измерения одного параметра недостаточно. Например, для почтового сервера самый важный параметр – скорость работы с файловыми метаданными. Лучше всего она представлена в параметрах «последовательное создание» (‘sequential create’) и «случайное создание» (‘random create’). С другой стороны, для потокового медиасервера, который в основном читает большие файлы большими порциями, более всего важен параметр «последовательное чтение блоками» (‘sequential input/block’).
Результаты выводятся в стандартный вывод. Они состоят из общей статистики в текстовом формате, за которой следует одна строка данных, разделенных запятой (CSV-формат), которые можно импортировать в электронную таблицу для сравнения данных двух тестов. Также есть простой фильтр bon_csv2html, который преобразует результаты CSV в HTML. В таблице ниже показан результат объединения результатов двух отдельных тестов и передачи тех двух строк в bon_csv2html.
Вывод Bonnie++ в формате HTML. Результаты, помеченные ‘++++’, получены для операций, выполнявшихся так быстро, что Bonnie не смогла вычислить осмысленный результат.
Не забудьте Тима Тоди
В соответствии со старым девизом Perl TIMTOWTDI (There Is More Than One Way To Do It – есть не один способ сделать это), имеются и другие средства для снятия характеристик файловых систем. Например, Postmark – утилита, которая имитирует загрузку файловой системы, создаваемую файловым сервером. Изначально она была в NetApps, а сейчас, похоже, не разрабатывается, хотя и есть в репозиториях некоторых дистрибутивов. Еще одна утилита – Dbench от разработчика Samba Эндрю Триджелла [Andrew Tridgell], см. http://samba.org/ftp/tridge/dbench/README.
Совет дня
Пользуясь какой-нибудь графической утилитой настройки, вы наверняка задумывались: какие же файлы на самом деле изменяются? Вот маленький трюк, который поможет это выяснить. Для начала откройте командную строку и введите:
$ touch /tmp/now
Теперь запустите графическую утилиту и сделайте все необходимое. Затем вернитесь в командную строку и наберите:
find /etc -newer /tmp/now
Эта команда покажет, какие файлы в каталоге /etc были изменены с момента запуска команды touch. Но расширить поиск на всю файловую систему не так просто, потому что будут найдены несколько сотен записей из каталогов /proc и /sys, которые нам не нужны. Попробуйте такую команду:
# find / -newer /tmp/now | grep -v ‘^/proc’ | grep -v ‘^/sys’
Даже после фильтрации командой grep, наверное, останется несколько файлов, измененных другими процессами, но сообразить, что это такое, обычно достаточно просто.
