Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=linux_ios...) тестирование производительности трёх планировщиков ввода/вывода для Linux - CFQ (используется по умолчанию), Noop с реализацией модели FIFO и Deadline. Тестирование проводилось как при использовании жесткого диска, так и для SSD-накопителя.
- В тестах FS-Mark планировщики показали примерно одинаковые результаты.
- В тесте BlogBench, оценивающем производительность записи, Noop и Deadline оказались почти в два раза быстрее CFQ на SSD-накопителе, но немного отстали от него на жестком диске.- В тесте CompileBench, оценивающем скорость сборки, лучшие результаты на SSD-накопителе показал CFQ, который обогнал Noop и Deadline примерно на 25%. На жестком диске с небольшим отрывом победил Deadline, на втором месте CFQ и на третьем Noop;
- В тесте IOzone на SSD с незначительным отрывом лидирует CFQ, а на жестком диске Noop;
- В тесте Threaded I/O Teste разница в показателях незначительная.URL: http://www.phoronix.com/scan.php?page=article&item=linux_ios...
Новость: https://www.opennet.ru/opennews/art.shtml?num=33832
Я вот даже смотреть небуду, угадаю цифры не глядя!По алгоритму Фроников - одна цифра с опережением,
одна цифра с отставанием, остальные в пределах 2%-погрешности.
не угадал
Очень даже угадал.
Хотя б доперло в этот раз, что не надо на виртуалках тестировать.
> Хотя б доперло в этот раз, что не надо на виртуалках тестировать.Точно? Может, у него просто образы на соответствующих носителях лежали, а работало это, как обычно, в vbox под виндой?
А на обычных дисках был включен AHCI на контроллере, потому как вроде если используется аппаратная очередь cfq показывает не очень хорошие результаты по сравнению с тем же noop
Если диск и чипсет поддерживают NCQ, то noop всех рвет.
без bfq не интересный тест
добавьте заведомо +1% к максимально имеющимся и спите спокойно. Думаете что найдут и откроют "новую галактику" без вас... ;) А на практике(у каждого) бутылочное горлышко будет все равно в другом месте
> без bfq не интересный тестНу придумайте что-нибудь сами. Это же фороникс, все равно достоверности никакой :)
> Ну придумайте что-нибудь сами. Это же фороникс, все равно достоверности никакой :)А давайте наоборот: вы сделаете кучу тестов, а мы их обосрем, без предоставления других, которые лучше.
> А давайте наоборот: вы сделаете кучу тестов, а мы их обосрем, без предоставления других, которые лучше.Пожалуйста: армя^Wтеплое лучше мягкого.
Обсирайте.
Чтото непонятна цель тестирования. Тут как бы и без тестов понятно что десктоп CFQ и сервер deadline. Но даже тут между ними разница формальна, проявляется она лишь деталях и с производительностью в тестах никак не связана.
> Но даже тут между ними разница формальна, проявляется она лишь деталях и с производительностью в тестах никак не связана.Мы-то это понимаем, а студент-недоучка по имени phoronix - нет.
> Мы-то это понимаем, а студент-недоучка по имени phoronix - нет.Ну так сделайте ваши тесты. Что, очкуете что другие анонимы их обосрут не хуже форониксовых? :)
> Ну так сделайте ваши тесты. Что, очкуете что другие анонимы их обосрут не хуже форониксовых? :)Научно сравнить теплое с мягким - не ахти какой труд. И обосрут его заслуженно.
Фороникс, опять-таки, этого не понимает.
>и без тестов понятно что десктоп CFQ и сервер deadline.Обоснуйте преимущества deadline не сервере.
> Обоснуйте преимущества deadline не сервере.Зависит от сервера. Если там всего один демон с диском работает - преимущества deadline очевидны, имхо.
> Чтото непонятна цель тестирования. Тут как бы и без тестов понятно что
> десктоп CFQ и сервер deadline. Но даже тут между ними разница
> формальна, проявляется она лишь деталях и с производительностью в тестах никак
> не связана.Да и совсем нет.
CFQ -- для серверов где много одновременно работающих с диском программ (однозначно не десктоп)
DEADLINE -- десктоп (не SSD) или сервера BD где с диском работает только одна программа.
NOOP -- любые машины на SSD, любые виртуализированные сервера и десктопы.Конечно существуют смешанные конфигурации, тогда всё немного сложнее.
>[оверквотинг удален]
>> десктоп CFQ и сервер deadline. Но даже тут между ними разница
>> формальна, проявляется она лишь деталях и с производительностью в тестах никак
>> не связана.
> Да и совсем нет.
> CFQ -- для серверов где много одновременно работающих с диском программ (однозначно
> не десктоп)
> DEADLINE -- десктоп (не SSD) или сервера BD где с диском работает
> только одна программа.
> NOOP -- любые машины на SSD, любые виртуализированные сервера и десктопы.
> Конечно существуют смешанные конфигурации, тогда всё немного сложнее.доктор, доктор, у меня жёсткие диски, но они сата, на южнике которого есть АХСИ. Какой планировщик мне использовать? таки ссдишный нооп или цфкью?
> Конечно существуют смешанные конфигурации, тогда всё немного сложнее.Гы :)
echo "2048" > /sys/block/sdb/queue/read_ahead_kb
echo "2048" > /sys/block/sdc/queue/read_ahead_kb
echo "2048" > /sys/block/sdb/queue/nr_requests
echo "2048" > /sys/block/sdc/queue/nr_requestsblockdev --setra 16384 /dev/sda
blockdev --setra 32768 /dev/sdb
blockdev --setra 32768 /dev/sdcecho "1" > /sys/block/sda/queue/rotational;
echo "1" > /sys/block/sda/queue/rq_affinity
echo "1" > /sys/block/sdb/queue/rq_affinity
echo "1" > /sys/block/sdc/queue/rq_affinityecho "noop" > /sys/block/sda/queue/scheduler
echo "deadline" > /sys/block/sdb/queue/scheduler
echo "cfq" > /sys/block/sdc/queue/scheduler
Интересно, что с приходом SSD упрощаются алгоритмы планирования дисковых операций, так как не нужно принимать во внимание механические задержки разной длительности и рассчитывать на их основе очередь команд. Для этих случаев на первое место выходят алгоритмы кэширования файловых систем и распределения свободной оперативной памяти, так как SSD по скорости и задержкам (относится больше к технологиям SLC и MRAM) становится в какой-то мере частью пространства памяти, а не внешней системы хранения. "Бутылочное горлышко" SATA интерфейса при наличии достаточно большого объёма ОЗУ при работе с часто используемыми данными перестаёт оказывать влияние на эффективность использования не только SSD, но и HDD, а значит разработка новых алгоритмов планировщиков ввода/вывода под большим вопросом.
> "Бутылочное горлышко" SATA интерфейсаЕсли не секрет, в чем проявляется бутылочное горлышко?
sata-2 - до 3 Гбит/с (300 МБайт/с).
sata-3 - до 6 Гбит/с (600 МБайт/с).Этого с головой хватает для десктопов и серверов начального уровня.
А для более серьёзных серверов есть другие технологии.
> Если не секрет, в чем проявляется бутылочное горлышко?
> sata-2 - до 3 Гбит/с (300 МБайт/с).
> sata-3 - до 6 Гбит/с (600 МБайт/с).В том что этот болванчик как ни странно прав. Флеш - это чипы памяти. Как минимум на чтение доступ там произвольный. И 600 Мбайт/сек там совсем не предел мечтания для идиота. Особенно с современным навернутым контроллером который делает interleaving на кучу чипов. Как бы 600Мб/сек это скорость работы памяти характерная для времен первых атлонов. Не больно то и дофига.
> Этого с головой хватает для десктопов и серверов начального уровня.
> А для более серьёзных серверов есть другие технологии.Ну да, ssd @ pcie по конским ценам, например одна из них. При том конская цена и pci-e все-таки намекают что крутым парням sata иногда может натурально не хватить :)
чё чушь несёшь. Во-первых, весь этот гемор уходит в сам SSD девайс и сама логика планирования стала на порядки сложнее. А для приложения всё это выливается в вообще в непредсказуемость задержек IO.И, кстати, дисбалланс для random IO и линейного никуда не делася.
> И, кстати, дисбалланс для random IO и линейного никуда не делася.У флеша seek time намного лучше. В плане чтения - 100%, потому что никакие головы передвигать не надо, а передавать адреса по шинам - быстро. С записью - могут быть приколы, основанные на том что флеш крупноблочная память с брейнфакерскими правилами записи. Контроллер SSD конечно пытается это спрятать, но физику процесса то не обманешь: некоторые типы нагрузок при записи будут куда как более удобны чем некоторые другие.
> Интересно, что с приходом SSD упрощаются алгоритмы планирования дисковых операций, так
> как не нужно принимать во внимание механические задержки разной длительностиЗато неплохо бы принимать во внимание кучу иных факторов.
> "Бутылочное горлышко" SATA интерфейса при наличии достаточно большого объёма ОЗУ
Да, конечно. Если сделать рамдиск - он тормозить не будет, независимо от скорости sata. Правда, у него есть недостаток: он энергозависимый и не переживает ребут :)
ээ, не понял про компиляцию. у меня все 4 ядра обычно заняты на 100%, то есть даже на хдд отстаёт проц, а не ио. значит все планировщики должны быть равны, или пофиг