Я работаю над масштабированием внешнего прокси-сервера, и до вчерашнего дня я использовал Squid в качестве обратного прокси (хотя в основном ничего не кэшировалось, т.е. Squid только проксировал). Сегодня я попытался перейти на nginx и заметил, что намного быстрее нахожусь в пределах ip_conntrack.
В качестве краткосрочного обходного пути я просто увеличиваю пределы ip_conntrack (согласно http://rackerhacker.com/2008/01/24/ip_conntrack-table-full-dropping-packet), но мне было интересно, знает ли кто-нибудь здесь, почему nginx намного быстрее достигает этих пределов, и можно ли что-нибудь сделать, чтобы исправить это? (т. е. более быстрое извлечение соединений из таблиц отслеживания).
Используемые вещи - это последняя версия Centos 5.5, nginx 0.8.53 и Squid 2.6. Все устанавливается с RPM (как основных, так и EPEL).
Заранее благодарим за любой совет или полезное обсуждение.
Для моей справки, эта другая ветка была полезна по этой теме: Определение пределов нагрузки обратного прокси-сервера nginx
Использование ip_conntrack для порта 80 - пустая трата ресурсов. Пометьте эти пакеты как NOTRACK и используйте ip_conntrack для других портов.
Я не могу найти документацию, напрямую связанную с conntrack, но посмотрите этот фрагмент из Nginx документация:
В ситуации обратного прокси max_clients становится
max_clients = worker_processes * worker_connections / 4
Поскольку браузер по умолчанию открывает 2 соединения с сервером, а nginx использует fds (файловые дескрипторы) из одного пула для подключения к вышестоящему бэкэнду.
Поведение Nginx с браузером по умолчанию заключается в получении от него двух подключений и открытии двух подключений к бэкэндам (обратное проксирование), таким образом генерируя всего 4 подключения. Это может быть причиной того, что conntrack заполняется быстрее. Конечно, это всего лишь полуосведомленное предположение, основанное на поведении рабочего nginx.