Назад | Перейти на главную страницу

Определение пределов нагрузки обратного прокси-сервера nginx

У меня есть сервер nginx (CentOS 5.3, linux), который я использую в качестве балансировщика нагрузки обратного прокси перед 8 ruby ​​на серверах приложений rails. Поскольку наша нагрузка на эти серверы увеличивается, я начинаю задаваться вопросом, в какой момент сервер nginx станет узким местом? Процессоры практически не используются, но этого следовало ожидать. С памятью вроде все нормально. Никакого ввода-вывода не о чем говорить.

Так это единственное ограничение на пропускную способность сетевых адаптеров? В настоящее время, согласно некоторым графикам cacti, сервер достигает около 700 Кбит / с (в среднем 5 минут) на каждой сетевой карте во время высокой нагрузки. Я думаю, это все еще довольно низкий уровень.

Или ограничение будет в сокетах или каком-либо другом ресурсе в операционной системе?

Спасибо за любые мысли и идеи.

Редактировать:
гонщик:

Спасибо за понимание. Я покопался еще немного. У меня есть 1 рабочий, разрешающий 1024 worker_connections. Предположим, что 95% запросов относятся к небольшим объемам данных. Какие-либо рекомендации относительно того, что система с 512 МБ должна быть способна обрабатывать с точки зрения подключения?

Кроме того, как лучше всего считать соединения? Будет ли что-то вроде этого точным ?:

netstat -np | grep ESTABLISHED | grep nginx | wc -l

Конец редактирования

Аарон

В настоящее время у вас довольно низкая нагрузка в зависимости от использования полосы пропускания. Существует множество возможных узких мест, если назвать некоторые из них:

Связанные с сетью

По мере роста количества подключений вы можете нажать worker_connections ограничение рабочего процесса Nginx. Описание гонщика довольно хорошее, я просто добавлю к нему несколько центов. На самом деле, чем больше у вас рабочих, тем больше шансов ударить worker_connections одного конкретного работника. Причина в том, что главный процесс Nginx не может гарантировать равномерного распределения соединений между воркерами - некоторые из них могут обрабатывать запросы быстрее, чем другие, и, таким образом, лимит может быть окончательно превышен.

Мой совет - использовать как можно меньше рабочих с большим количеством worker_connections. Однако вам придется увеличить количество рабочих, если у вас есть ввод-вывод (см. Ниже). Используйте nginx status модуль для просмотра количества используемых сокетов.

Вероятно, вы достигнете предела ОС (Linux или FreeBSD) на количество дескрипторов открытых файлов для каждого процесса. Nginx будет использовать дескрипторы не только для входящих запросов, но и для исходящих соединений с бэкэндами. Первоначально этот предел установлен на очень низкое значение (например, 1024). Nginx будет жаловаться на error.log об этом событии.

Если вы используете iptables и его модуль conntrack (Linux), вы должны превышать размер conntrack стол тоже. Осторожно dmesg или /var/log/messages. При необходимости увеличьте этот предел.

Некоторые очень хорошие оптимизированные приложения используют 100% пропускную способность. Я уверен, что вы столкнетесь с предыдущими проблемами раньше.

IO связанные

Фактически, воркер Nginx блокирует ввод-вывод. Таким образом, если ваш сайт обслуживает статический контент, вам нужно будет увеличить количество воркеров Nginx, чтобы учесть блокировку ввода-вывода. Здесь сложно привести рецепты, так как они сильно различаются в зависимости от количества и размера файлов, типа загрузки, доступной памяти и т. Д.

Если вы проксируете соединения с каким-либо сервером через Nginx, вы должны принять во внимание, что он создает временные файлы для хранения ответа серверной части, и в случае большого трафика это может привести к значительной нагрузке на файловую систему. Следите за сообщениями в Nginx error.log и настроить proxy_buffers (или fastcgi_buffers) соответственно.

Если у вас есть фоновый ввод-вывод (например, MySQL), это также повлияет на работу статических файлов. Следить за IO wait%

По поводу открытых подключений. лучший способ отслеживать их - проверять / proc / net / ip_conntrack.

cat /proc/net/ip_conntrack | egrep 'dport=(80|443)'| wc -l 

Теперь, что касается вашего вопроса о nginx, настоящего ответа нет. Вам просто нужно проверить свою настройку (используя такие инструменты, как httperf) и посмотреть, с какой нагрузкой вы справитесь.

Это больше, чем просто пропускная способность сетевой карты. Nginx может обрабатывать максимальное количество подключений. Максимальное количество подключений можно вычислить по простой формуле: «worker_processes» * «worker_connections». Узкое место будет зависеть от вашего приложения. Если у вас много соединений с низкой пропускной способностью, у вас больше шансов исчерпать их до того, как вы заполните свой канал. И наоборот, небольшое количество соединений, использующих большую пропускную способность, может заполнить ваш канал, не достигнув максимального количества соединений.