On Saturday 17 October 2009 23:43:32 h31 wrote:
Уважаемые, кто игрался с планировщиками и их параметрами, раскажите о результатах опытов.
* CFQ - Completely Fair Queuing - полностью справедливая очередь * Deadline * NOOP * Anticipatory - упреждающий конвейер
Deadline и Anticipatory вроде бы для серьезных серверов. При наличии NCQ (посмотреть это можно в dmesg | grep NCQ, глубина должна быть больше нуля) неплохо работает noop, в остальных случаях можно оставить CFQ. Так что выбор невелик. Когда-то включил noop, потом стер конфиги и забыл включить опять. Основное преимущество noop при наличии NCQ - минимальная нагрузка на ЦПУ.
Если бы при оценки I/O планировщиков был какой-то один параметр "производительность", то все было бы гораздо легче - прогнать тесты и выбрать лучший. Однако есть 2 основные характеристики: пропускная способность и отзывчивость. Они противоречат друг другу. Представьте нефтепровод Москва-Берлин. Пропускная способность 24 тыс тонн нефти в сутки. Но это не значит, что за час можно переправить 1 тыс тонн. Когда нефть нужна прямо сейчас, хотя бы пару тонн, а не завтра, то важна не пропускная способность, а отзывчивость - то есть через какое время начнут поступать первая нефть. Для десктопа считается важнее отзывчивость, для сервера пропускная способность. Действительно - пользователю десктопа хочется получить данные в приложение как можно быстрее. На сервере работает множество пользователей и гораздо интереснее за 10 сек обслужить 100 пользователей, чем по 10 за каждые 2 секунды. Небольшое введение про I/O планировщики с кратким объяснением механизма работы. http://www.opennet.ru/base/sys/ioshedulers.txt.html CFQ - справедливая очередь, больше всех остальных подходит для десктопа. Не совсем оптимален с точки зрения общей пропускной способности, но хорош в плане отзывчивости. Если у вас есть небольшой тестовый сервер на 5ых человек или личный сервер для тестов на 1ого человека - то скорее всего вам опять же понадобится CFQ, нежели Deadline. Ну и даже на многопользовательском сервере не всегда нужно оптимизировать именно I/O подсистему в плане общей пропускной способности - вероятно вы добьетесь гораздо больших успехов другими способами, например настройкой прикладного ПО. Если вспомнить советы гуру Oracle Тома Кайта, то он рекомендовал уделять гораздо большее внимание настройке схемы, нежели тюнингу производительности самой СУБД. Приминительно к I/O подсистеме Linux - наврядли замена планировщика спасет вас от тормоза. Лучше пользуйтесь CFQ (что стоит по умолчанию) пока у вас не будет веских причин от него отказываться. --- WBR, Mittov Dmitry.