Уважаемые, кто игрался с планировщиками и их параметрами, раскажите о результатах опытов. * CFQ - Completely Fair Queuing - полностью справедливая очередь * Deadline * NOOP * Anticipatory - упреждающий конвейер -- To unsubscribe, e-mail: opensuse-ru+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ru+help@opensuse.org
В сообщении от 17 октября 2009 13:09:30 автор Черноусов Антон Анатольевич написал:
Уважаемые, кто игрался с планировщиками и их параметрами, раскажите о результатах опытов.
* CFQ - Completely Fair Queuing - полностью справедливая очередь * Deadline * NOOP * Anticipatory - упреждающий конвейер
Deadline и Anticipatory вроде бы для серьезных серверов. При наличии NCQ (посмотреть это можно в dmesg | grep NCQ, глубина должна быть больше нуля) неплохо работает noop, в остальных случаях можно оставить CFQ. Так что выбор невелик. Когда-то включил noop, потом стер конфиги и забыл включить опять. Основное преимущество noop при наличии NCQ - минимальная нагрузка на ЦПУ. N�����r��y隊Z)z{.�����칻 �&ޢ���� �����v+b�v�r��jwlzf���^�ˬz����i����� ��
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.
On 10/18/2009 08:14 PM, Mittov Dmitri wrote:
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. N�����r��y隊Z)z{.�����칻 �&ޢ���� �����v+b�v�r��jwlzf���^�ˬz����i����� org=
Спасибо за советы, но хотелось бы увидеть результаты теститрований или примеры внедрений тех или иных планировщиков в достаточно нагруженных системах. Заранее спасибо :) Своими результатами, могу поделиться, я на данный момент использую DeadLine, оптимизировать софт не имею возможности ибо он не мой и исходников его нет :( Могу лишь его переиодически мониторить на предмет потребления IO ресурсов и ресурсов проца, так вот, перых он жреть немеряно ... поэтому и встают вопросы оптимизации. -- To unsubscribe, e-mail: opensuse-ru+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ru+help@opensuse.org
On Sunday 18 October 2009 20:53:42 Черноусов Антон Анатольевич wrote:
Спасибо за советы, но хотелось бы увидеть результаты теститрований или примеры внедрений тех или иных планировщиков в достаточно нагруженных системах. Заранее спасибо :)
Извини, этого у меня нет.
Своими результатами, могу поделиться, я на данный момент использую DeadLine, оптимизировать софт не имею возможности ибо он не мой и исходников его нет :(
У софта есть настройки и параметры. Например параметр keep-alive в Apache, имхо, важнее I/O планировщика.
Могу лишь его переиодически мониторить на предмет потребления IO ресурсов и ресурсов проца, так вот, перых он жреть немеряно ... поэтому и встают вопросы оптимизации.
Это скорее вы на своей тестовой системе, максимально приближенной к реальной должны эксперименты ставить. Ваша система, возможно, выполняет большие линейные чтения. У дргугого человека с другим софтом идет запрос большого числа блоков разбросаных по дискам. В итоге вы выберете разные планировщики. --- WBR, Mittov Dmitry.
On 10/18/2009 09:46 PM, Mittov Dmitri wrote:
On Sunday 18 October 2009 20:53:42 Черноусов Антон Анатольевич wrote:
Спасибо за советы, но хотелось бы увидеть результаты теститрований или примеры внедрений тех или иных планировщиков в достаточно нагруженных системах. Заранее спасибо :)
Извини, этого у меня нет.
Своими результатами, могу поделиться, я на данный момент использую DeadLine, оптимизировать софт не имею возможности ибо он не мой и исходников его нет :(
У софта есть настройки и параметры. Например параметр keep-alive в Apache, имхо, важнее I/O планировщика.
Могу лишь его переиодически мониторить на предмет потребления IO ресурсов и ресурсов проца, так вот, перых он жреть немеряно ... поэтому и встают вопросы оптимизации.
Это скорее вы на своей тестовой системе, максимально приближенной к реальной должны эксперименты ставить. Ваша система, возможно, выполняет большие линейные чтения. У дргугого человека с другим софтом идет запрос большого числа блоков разбросаных по дискам. В итоге вы выберете разные планировщики.
--- WBR, Mittov Dmitry. N�����r��y隊Z)z{.�����칻 �&ޢ���� �����v+b�v�r��jwlzf���^�ˬz����i����� org= Спасибо за советы, потестирую и обязательно поделюсь результатами. -- To unsubscribe, e-mail: opensuse-ru+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ru+help@opensuse.org
participants (3)
-
h31 -
Mittov Dmitri -
Черноусов Антон Анатоль евич