Re: Скорость чтения с диска <последовательно одним процессом> VS <параллельно несколькими>
В Птн, 20/03/2009 в 12:02 +0200, Покотиленко Костик пишет:
> Штатных утилит делающих подобное не нашёл, ткните, наверняка проглядел.
> Не поленился написать данный тест. Первая версия и результат её работы
> на моей системе выложены, ссылки внизу.
>
> О тесте: программа рекурсивно сканирует указанный каталог и составляет
> список обычных файлов, затем делит этот список на 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: