[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Скорость чтения с диска <последовательно одним процессом> VS <параллельно несколькими>



Штатных утилит делающих подобное не нашёл, ткните, наверняка проглядел.
Не поленился написать данный тест. Первая версия и результат её работы
на моей системе выложены, ссылки внизу.

О тесте: программа рекурсивно сканирует указанный каталог и составляет
список обычных файлов, затем делит этот список на N частей. Далее
программа создаёт N клонов с помощью fork(), каждый из которых читает
файлы из своей части списка. По окончанию работы каждого клона выводится
его статистика. 

Кому интересно можете провести тест на свой страх и риск на своём
железе, результат сравним.

1. По результату: при моих параметрах тестирования чтение
<последовательно одним процессом> быстрее, но не намного.

2. Параметры тестирования:
- каталог:                           /usr/src
- ФС:                                ext3 (Всего: 9,2G; Занято: 6,8G)
- файлов в списке:                   254794
- подкаталогов:                      23003
- максимальные уровень вложенности:  12 (maxrec)
- проц:                              C2D ~2GHz
- память:                            1Гб (около 300Мб свободно/кэш)
- контроллер:                        Intel® ICH10
- винт:                              WDC WD5000AAKS-00YGA0
http://www.xard.ru/post/11716/default.asp

Беглое гугление показало, не факт что NCQ включён и работает:
http://blog.kovyrin.net/2006/08/11/turn-on-ncq-on-ich-linux/lang/ru/
Кто-нибудь в курсе статуса NCQ в Debian?

# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   5886 MB in  2.00 seconds = 2945.75 MB/sec
 Timing buffered disk reads:  238 MB in  3.04 seconds =  78.40 MB/sec

#uname -a 
Linux casper 2.6.24-etchnhalf.1-686 #1 SMP Fri Dec 26 04:10:16 UTC 2008
i686 GNU/Linux

остальное в pdf.

3. Точность:
- программа тупо делит список на равное количество записей, размеры
файлов не учитываются, поэтому одним клонам достаётся больше чем другим,
они работают дольше и остаток времени работают с меньшим числом
конкурентов, что на мой взгляд увеличивает общую скорость. Во вложенных
результатах в тесте с 4-мя потоками 4-му досталась половина всего
объёма. Это особенности распределения файлов по моему /usr/src.
- для каждого числа потоков было проведено 3 эксперимента, учитывались
средние значения.
- в программе учитывается только время на чтение файлов по списку, и не
учитывается время на его создание и другие операции.
- не понятно работал ли NCQ.
- перед тестами я не сбрасывал кэш ФС, на объёме ~1.3 Гб он не
эффективен, это видно из тестов.
- на мой взгляд данный тест производит нагрузку похожую на ту, что
создаёт apache2 при соизмеримых количествах клиентов (потоков) и
запросов.


http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf

-- 
Покотиленко Костик <casper@meteor.dp.ua>


Reply to: