Преобразование процесса в отрицательный хороший уровень увеличивает приоритет планирования процесса. Процессы с высоким приоритетом запускаются перед процессами с низким приоритетом. Им также разрешено работать дольше, прежде чем быть опережающим (они получают более длинные отрезки времени).
На веб-сервере выполняется httpd процессы с отрицательным приятным стоимость должен уменьшить переключение контекста и поэтому улучшить общую производительность.
Кто-нибудь пробовал это делать? Какая разница? Время отклика улучшилось? Увеличивается или уменьшается стандартное отклонение времени отклика? Увеличилась ли пропускная способность?
Редактировать:
Я не стремлюсь снижать приоритет других процессов; и я не собираюсь исправлять перегруженную систему. Мне интересно, влияют ли отрицательные хорошие уровни на уменьшение переключений контекста, и если да, то как это влияет на время отклика и пропускную способность.
Я очень рекомендую не делая это. Если ваш сервер настолько загружен, что apache не получает необходимое ему процессорное время, то рендеринг процесса будет иметь очень минимальный эффект, если таковой имеется. Кроме того, в apache будет много разные процессы, запущенные одновременно. Вы можете переименовать родительский процесс, и его дочерние элементы унаследуют аккуратность родительского процесса, но тогда все процессы httpd будут бороться друг с другом за время.
В старых ядрах (скажем, в конце 90-х / начале 00-х) я обнаружил, что есть некоторая ценность в процессах переноса (хотя обычно я только уменьшился приоритет, не повышенный). С планировщиком в современных ядрах я никогда не считал это необходимым или даже стоящим размышлений.
В заключение хочу сказать, что для решения проблем с производительностью есть множество других областей, на которые я хотел бы обратить внимание, прежде чем я начну обвинять приоритет процесса.
Предупреждение: IANAKD (я не разработчик ядра :)
Предполагая, что мы говорим о Linux, вы можете прочитать о том, как реализовано nice по адресу:
http://www.kernel.org/doc/Documentation/scheduler/sched-nice-design.txt
Чтобы попытаться ответить на ваш вопрос, это не повлияет на пропускную способность, потому что процессы не имеют приоритета при блокировке ввода-вывода, а веб-сервер, обслуживающий статический контент, скорее всего, будет привязан к вводу-выводу.
См. Также команду "ionice" - хотя она бесполезна, если за ввод-вывод не борются разные процессы.
В конечном счете, я не думаю, что уменьшение переключений контекста будет иметь значение. Скорее всего, веб-сервер, обслуживающий статический контент, тратит все свое время на ввод-вывод (сетевой или дисковый), а процессор относительно простаивает. В наши дни процессоры настолько мощнее подсистем ввода-вывода, что они редко становятся узким местом во многих серверных сценариях. (Очевидно, что чистое вычисление чисел или 3D-рендеринг являются исключениями.) Если вы планируете реализовать это на реальном сервере для повышения производительности, я бы посоветовал сначала контролировать систему с помощью таких инструментов, как top, iostat, vmstat, dstat и т. Д. ... чтобы увидеть, где он проводит большую часть своего времени. Как только у вас появятся данные об узком месте, вы сможете найти решения.