ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: увеличение количества worker_processes


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: увеличение количества worker_processes
  • From: Maxim Dounin <mdounin@xxxxxxxxxx>
  • Date: Sun, 29 Jul 2012 02:04:20 +0400
  • In-reply-to: <CAK=u2EVy-qq2c4tDEXn8r15SVzp1J=DcSCPhgrtFrQUpP2nJfg@mail.gmail.com>
  • References: <CAK=u2EVy-qq2c4tDEXn8r15SVzp1J=DcSCPhgrtFrQUpP2nJfg@mail.gmail.com>

Hello!

On Sat, Jul 28, 2012 at 01:57:21PM +0400, Phil Kulin wrote:

> Приветствую.
> 
> Древняя тема про worker_processes. Используя в промышленных
> количествах nginx с лета 2004 года, я как-то уже забыл тонкости.
> Почему-то в голове жёсткое правило - без причины не увеличивать
> количество worker_processes. А вот обосновать не могу.
> 
> Не смог за два дня нагуглить тезисный  список проблем, которые могут
> возникнуть при увеличении этого параметра. Где-то упоминается
> количество дисков, без ссылки на историю проблемы, где-то просто
> абстрактно говорится, что проблема начнётся раньше, чем проблема
> CPU... Даже рекомендация про равенство количеству ядер очень
> осторожная - в нескольких местах вежливо написано "если уж нужно
> считать SSL/gzip, то вот начните с количества CPU".
> 
> Вопрос - какие специфические проблемы могут возникать при увеличении
> количества воркеров? В чём их основа?

Как и при любом конкурентном доступе - увеличение конкурентности 
приводит к увеличению накладных расходов.  Это и затраты на 
переключение процессов, и просто расход лишней памяти, и банальное 
снижение эффективности кешей процессоров из-за миграции процессов 
с процессора на процессор и/или вымывания их другими процессами, и 
lock contention где не надо, и так далее, и тому подобное.

Что касается специфичных для nginx'а вещей, то тут пожалуй в 
первую очередь всякие per-process вещи вроде кеша резолвера, 
open_file_cache, статистике по upstream'ам и кеша соединений к 
ним.

Что важнее - увеличение конкурентности или рост накладных 
расходов, а соответственно в какое значение ставить количество 
рабочих процессов - зависит от конкретной ситуации.

До недавнего времени местной достопримечательностью была 
конфигурация Миши Монашёва с 1000 (тысячей) рабочих процессов.  И 
эта цифра была вполне оправдана и разумна (сейчас там используется 
aio, и процессов стало поменьше).

Безусловно, ставить сильно больше рабочих процессов, чем надо для 
конкретной задачи - не есть правильно.  Но обычно не фатально.

> P.S. Я думаю это надо в документацию написать потом, или хотя бы в
> wiki. Я за последний месяц уже 5-ую конфигурацию вижу с
> worker_processes = 2xCPU с обоснованием "так на многопроцессорных
> системах все делают".

2xCPU - это почти всегда неправильно.  Потому что если nginx упёрт 
в CPU, то это много, если в диски - то вопрос не в количестве CPU.  
А в большинстве случаев nginx ни во что не упёрт, и лишние 
процессы просто без пользы потребляют ресурсы.

Впрочем, современные системы имеют не столько процессоров, чтобы 
2xCPU так уж сильно отличалось от оптимального значения.  

Что до документации, то там уже расписано всё, что можно 
расписать в рамках документации, а не отдельной статьи на тему 
"как правильно тюнить количество рабочих процессов в различных 
ситуациях: примеры из практики и синтетические тесты". 

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.