Немного про nginx

8

десять символов

Спасибо :)

Аналогичный вопрос.

У 2-х процессорного xeon 5650 шесть ядер на процессор. С гипертрейдингом получается 24 виртуальных процессора на сервере.

Сколько в этом случае ставить значение worker_processes?

Поставил 24.

Работает нормально. Но как проверить, что значение worker_processes выставлено оптимально?

да все очень просто - сколько тредов одновременно может выполняться, столько и нужно ставить.

У вас с гипертредами 24? Значит ставьте 24.

Я, правда, ставлю N + 1

На очень нагруженных системах можно выделить отдельно треды скажем для веб-сервера и отдельно для базы данных, чтобы программные треды не скакали по аппаратным. Но это на действительно очень нагруженных системах

Это все в теории естественно, на практике зависит от конкретного случая, какие компоненты у вас работают, как распределяется нагрузка по компонентам, какие требования у компонентов. Ну и добавьте сюда железо, которое не из одного проца состоит, есть же еще харды, сетевые карты, как прерывания распределены. Шаманство, в общем

Ну и старый принцип - работает нормально? Не трогай.

гипертрединг - вобще-то не удваивает полноценные ядра.

иногда результат может быть близок к удвоенному, но зачастую прирост от гипертрединга где-то 1.6 раза.

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

для точного и оптимального ответа лучше задать вопрос вот тут

я бы поставил 4, у вас сервер не только ведь статику отдает, но и, наверняка, динамику генерит, БД поднята (а там везде свои потоки).

Один из способов определения количества процессоров, которое "видит" система. Для Linux

cat /proc/cpuinfo | grep processor | wc -l

Это так, но немного не в тему, т.к. производительность падает не из-за того, что есть недостаток ниток, а из-за того, что нитки используют общий кеш.

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

В этом кстати недостаток систем построенных по этой схеме - теряется интерактивность, если у вас выстроилась очередь из 100 сообщений, то обрабатываются эти сообщения последовательно, и пока 99 сообщений не будет обработано, 100-е будет ждать своей очереди. В отличии от многониточных систем, где каждой нитке (грубо говоря, сообщению), дается немного времени выполнения, поэтому обрабатываться сотое сообщение вполне может начаться когда обработка первого еще не закончилась.

это да, надо смотреть на конкретную систему. А еще лучше вообще ничего не трогать, если все устраивает :)

Про прирост чего Вы говорите? 1.6 раза от чего? Вы это где и когда видели УДВОЕНИЕ 😮 хоть чего-либо от использования гиппер-трейдинга? 😂

😂 это как ? Это что за ноу-хау "параллелизация за счет событий" ?

Параллелизация внутри nginx идет за счет создания нитей в рамках одного процесса (имеется ввиду не по кол-во коннектов, а просто что в nginx работает несколько потоков, как и в любом достаточно сложном демоне).

TC, по сабжу имхо надо понять какая доля нагрузки лежит именно на nginx, возможно как раз nginx стоит вообще загнать на 1-2 процесса (у меня лично nginx вообще в один процесс работает, так как его роль 1% от общей вычислительной нагрузки), а остальное пускай кушает mysql, php и прочие ресурсоемкие процессы.

Вобщем зависит все от того, какой у Вас сайт, какие ресурсы он потребляет больше всего.

Дело в том что nginx, сам по себе, не много ресурсов потреблеят, и возможно нет никакого смысла, а то и вообще вред (в виде лишней скушанной памяти) в увеличении кол-ва его процессов.

хм, че-то вы тут загнули.

сцылкой не поделитесь почитать? а то быстрый гуглопоиск ниче не дает такого.

Я не имею ввиду ветвление по кол-ву пользователей, но явно nginx внутри работает не в рамках одного потока. Ссылка :)

В этом его и отличие от apache, что апач создает потоки для каждого запроса в результате чего, в памяти могут застревать процессы, которые уже давно выполнились, но ждут пока клиент закончит прием данных.

Но и в nginx явно одновременно работает несколько потоков каждый своего назначения, одни отвечают за ввод/вывод, одни за чтение файлов, другие за проксирование.

Писать веб-сервер в ОДИН поток это очень не эффективно, так как одновременно разные коннекты находятся на разной стадии выполнения и эти стадии зачастую полностью параллельны друг-другу.

Это имхо, исходники дадут точный ответ, если он нужен :)

PS: мельком сейчас посмотрел исходники nginx, на первый взгляд все именно так, как я написал :)