<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Оценка производительности планировщиков ввода/вывода в Linux</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html</link>
    <description>Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&amp;item=linux_iosched_2012&amp;num=1) тестирование производительности трёх планировщиков ввода/вывода для Linux - CFQ (используется по умолчанию), Noop с реализацией модели FIFO и Deadline. Тестирование проводилось как при использовании жесткого диска, так и для SSD-накопителя. &lt;br&gt;&lt;br&gt;&lt;br&gt;-  В тестах FS-Mark планировщики показали примерно одинаковые результаты. &lt;br&gt;-  В тесте BlogBench, оценивающем производительность записи,  Noop и Deadline оказались почти в два раза быстрее CFQ на SSD-накопителе, но немного отстали от него на жестком диске.&lt;br&gt;&lt;br&gt;-  В тесте CompileBench, оценивающем скорость сборки, лучшие результаты на SSD-накопителе показал CFQ, который обогнал  Noop и Deadline примерно на 25&#037;. На жестком диске с небольшим отрывом победил Deadline, на втором месте CFQ и на третьем Noop;&lt;br&gt;-  В тесте IOzone на SSD с незначительным отрывом лидирует CFQ, а на жестком диске Noop;&lt;br&gt;-  В тесте Threaded I/O Teste разница в показателях незначительная.&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;URL: ht</description>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (pavlinux)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#28</link>
    <pubDate>Wed, 23 May 2012 23:29:06 GMT</pubDate>
    <description>&amp;gt; Конечно существуют смешанные конфигурации, тогда всё немного сложнее.&lt;br&gt;&lt;br&gt;Гы :)&lt;br&gt;&lt;br&gt;&#091;code&#093;&lt;br&gt;echo &quot;2048&quot; &amp;gt; /sys/block/sdb/queue/read_ahead_kb&lt;br&gt;echo &quot;2048&quot; &amp;gt; /sys/block/sdc/queue/read_ahead_kb&lt;br&gt;echo &quot;2048&quot; &amp;gt; /sys/block/sdb/queue/nr_requests &lt;br&gt;echo &quot;2048&quot; &amp;gt; /sys/block/sdc/queue/nr_requests &lt;br&gt;&lt;br&gt;blockdev --setra 16384 /dev/sda&lt;br&gt;blockdev --setra 32768 /dev/sdb&lt;br&gt;blockdev --setra 32768 /dev/sdc&lt;br&gt;&lt;br&gt;echo &quot;1&quot; &amp;gt;  /sys/block/sda/queue/rotational;&lt;br&gt;&lt;br&gt;echo &quot;1&quot; &amp;gt; /sys/block/sda/queue/rq_affinity&lt;br&gt;echo &quot;1&quot; &amp;gt; /sys/block/sdb/queue/rq_affinity&lt;br&gt;echo &quot;1&quot; &amp;gt; /sys/block/sdc/queue/rq_affinity&lt;br&gt;&lt;br&gt;echo &quot;noop&quot;     &amp;gt; /sys/block/sda/queue/scheduler&lt;br&gt;echo &quot;deadline&quot; &amp;gt; /sys/block/sdb/queue/scheduler&lt;br&gt;echo &quot;cfq&quot;      &amp;gt; /sys/block/sdc/queue/scheduler&lt;br&gt;&#091;code&#093;&lt;br&gt;&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#27</link>
    <pubDate>Tue, 15 May 2012 07:20:34 GMT</pubDate>
    <description>&amp;gt;&#091;оверквотинг удален&#093;&lt;br&gt;&amp;gt;&amp;gt; десктоп CFQ и сервер deadline. Но даже тут между ними разница &lt;br&gt;&amp;gt;&amp;gt; формальна, проявляется она лишь деталях и с производительностью в тестах никак &lt;br&gt;&amp;gt;&amp;gt; не связана.&lt;br&gt;&amp;gt; Да и совсем нет.&lt;br&gt;&amp;gt; CFQ -- для серверов где много одновременно работающих с диском программ (однозначно &lt;br&gt;&amp;gt; не десктоп) &lt;br&gt;&amp;gt; DEADLINE -- десктоп (не SSD) или сервера BD где с диском работает &lt;br&gt;&amp;gt; только одна программа.&lt;br&gt;&amp;gt; NOOP -- любые машины на SSD, любые виртуализированные сервера и десктопы.&lt;br&gt;&amp;gt; Конечно существуют смешанные конфигурации, тогда всё немного сложнее.&lt;br&gt;&lt;br&gt;доктор, доктор, у меня жёсткие диски, но они сата, на южнике которого есть АХСИ. Какой планировщик мне использовать? таки ссдишный нооп или цфкью?&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#26</link>
    <pubDate>Tue, 15 May 2012 07:13:24 GMT</pubDate>
    <description>ээ, не понял про компиляцию. у меня все 4 ядра обычно заняты на 100&#037;, то есть даже на хдд отстаёт проц, а не ио. значит все планировщики должны быть равны, или пофиг&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#25</link>
    <pubDate>Mon, 14 May 2012 19:46:51 GMT</pubDate>
    <description>&amp;gt; Обоснуйте преимущества deadline не сервере.&lt;br&gt;&lt;br&gt;Зависит от сервера. Если там всего один демон с диском работает - преимущества deadline очевидны, имхо.&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#24</link>
    <pubDate>Mon, 14 May 2012 11:25:43 GMT</pubDate>
    <description>&amp;gt; Ну так сделайте ваши тесты. Что, очкуете что другие анонимы их обосрут не хуже форониксовых? :) &lt;br&gt;&lt;br&gt;Научно сравнить теплое с мягким - не ахти какой труд. И обосрут его заслуженно.&lt;br&gt;Фороникс, опять-таки, этого не понимает.&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#23</link>
    <pubDate>Mon, 14 May 2012 11:24:18 GMT</pubDate>
    <description>&amp;gt; А давайте наоборот: вы сделаете кучу тестов, а мы их обосрем, без предоставления других, которые лучше.&lt;br&gt;&lt;br&gt;Пожалуйста: армя^Wтеплое лучше мягкого.&lt;br&gt;Обсирайте.&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#22</link>
    <pubDate>Mon, 14 May 2012 09:29:59 GMT</pubDate>
    <description>Если диск и чипсет поддерживают NCQ, то noop всех рвет.&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#21</link>
    <pubDate>Mon, 14 May 2012 08:51:32 GMT</pubDate>
    <description>&amp;gt; Если не секрет, в чем проявляется бутылочное горлышко?&lt;br&gt;&amp;gt; sata-2 - до 3 Гбит/с  (300 МБайт/с).&lt;br&gt;&amp;gt; sata-3 - до 6 Гбит/с (600 МБайт/с).&lt;br&gt;&lt;br&gt;В том что этот болванчик как ни странно прав. Флеш - это чипы памяти. Как минимум на чтение доступ там произвольный. И 600 Мбайт/сек там совсем не предел мечтания для идиота. Особенно с современным навернутым контроллером который делает interleaving на кучу чипов. Как бы 600Мб/сек это скорость работы памяти характерная для времен первых атлонов. Не больно то и дофига. &lt;br&gt;&lt;br&gt;&amp;gt; Этого с головой хватает для десктопов и серверов начального уровня.&lt;br&gt;&amp;gt; А для более серьёзных серверов есть другие технологии.&lt;br&gt;&lt;br&gt;Ну да, ssd &#064; pcie по конским ценам, например одна из них. При том конская цена и pci-e все-таки намекают что крутым парням sata иногда может натурально не хватить :)&lt;br&gt;</description>
</item>

<item>
    <title>Оценка производительности планировщиков ввода/вывода в Linux (Аноним)</title>
    <link>https://www.opennet.me/openforum/vsluhforumID3/84503.html#20</link>
    <pubDate>Mon, 14 May 2012 08:48:07 GMT</pubDate>
    <description>&amp;gt; И, кстати, дисбалланс для random IO и линейного никуда не делася.&lt;br&gt;&lt;br&gt;У флеша seek time намного лучше. В плане чтения - 100&#037;, потому что никакие головы передвигать не надо, а передавать адреса по шинам - быстро. С записью - могут быть приколы, основанные на том что флеш крупноблочная память с брейнфакерскими правилами записи. Контроллер SSD конечно пытается это спрятать, но физику процесса то не обманешь: некоторые типы нагрузок при записи будут куда как более удобны чем некоторые другие.&lt;br&gt;</description>
</item>

</channel>
</rss>
