Я собираюсь заменить проприетарный программный балансировщик нагрузки на HAProxy. В рамках этого исследования я пытаюсь протестировать HAProxy под нагрузкой. Хотя моя конфигурация HAProxy работает нормально при тестировании в качестве одного пользователя, как только я загружаю на нее какую-либо нагрузку, скорость сайта начинает резко падать, и вскоре (~ 100 смоделированных пользователей) наш инструмент тестирования нагрузки начинает сообщать неудачи.
Это довольно простая конфигурация, с единственными примечательными моментами: мы используем HAProxy 1.5.4 с поддержкой OpenSSL и PCRE, скомпилированной и используемой. У нас также есть некоторые списки ACL для сопоставления URL-адресов, хотя этот интерфейс не используется в этом нагрузочном тесте.
Это работает на машине CentOS 6.5.
Наша (очищенная) конфигурация для комбинации внешнего и внутреннего интерфейса в нагрузочном тесте, а также глобальные настройки и значения по умолчанию:
global
daemon
tune.ssl.default-dh-param 2048
maxconn 100000
maxsessrate 100000
log /dev/log local6
defaults
mode http
option forwardfor
option http-server-close
timeout client 61s
timeout server 61s
timeout connect 13s
log global
option httplog
frontend stats
bind xxx.xxx.xxx.xxx:80
default_backend stats-backend
backend stats-backend
stats enable
server stats 127.0.0.1:80
frontend portal-frontend
bind xxx.xxx.xxx.xxx:80
default_backend portal-backend
frontend portal-frontend-https
bind xxx.xxx.xxx.xxx:443 ssl crt /path/to/pem
default_backend portal-backend
backend portal-backend
redirect scheme https if !{ ssl_fc }
appsession session len 140 timeout 4h request-learn
server web1.example.com web1.example.com:80 check
server web2.example.com web2.example.com:80 check
[...snip...]
Во время нагрузочного теста мы получаем некоторую информацию из логов, но не большие объемы. Соответствующие фрагменты:
Sep 4 11:06:12 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:30983 [04/Sep/2014:11:05:42.984] portal-frontend-https~ portal-frontend-https/<NOSRV> -1/-1/-1/-1/28782 408 212 - - cR-- 1840/1840/0/0/0 0/0 "<BADREQ>"
...
Sep 4 11:06:03 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:61502 [04/Sep/2014:11:05:47.810] portal-frontend-https~ portal-frontend-https/<NOSRV> -1/-1/-1/-1/14345 400 187 - - CR-- 1715/1693/0/0/0 0/0 "<BADREQ>"
...
Sep 4 11:06:03 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:43939 [04/Sep/2014:11:05:59.553] portal-frontend portal-backend/<NOSRV> 314/-1/-1/-1/2602 302 181 - - LR-- 1719/22/223/0/3 0/0 "GET /mon/login.php?C=1&LID=15576783&TID=8145&PID=8802 HTTP/1.1"
На основе этих записей журнала мы пробовали такие вещи, как настройка тайм-аута http-запроса, но без каких-либо улучшений (нагрузочный тест будет работать дольше, прежде чем наш инструмент сообщит о сбоях, но замедление происходит аналогичным образом) .
Я уверен, что HAProxy может работать намного лучше этого, но я действительно не знаю, куда обратиться, чтобы начать диагностику проблемы (или ограничения).
Пожалуйста, запустите dmesg и убедитесь, что ваша таблица conntrack iptables не заполнена ... У вас может быть много сообщений, подобных этому: "ip_conntrack: table full, drop packet"
Если это так, настройте свой sysctl: net.ipv4.netfilter.ip_conntrack_max Значение по умолчанию очень низкое. Вы можете установить до 50000, а может и больше, в зависимости от вашей нагрузки.
Батист
Феликс прав. Вам нужно, чтобы maxconn на ваших внутренних серверах был установлен на низком уровне, а ваш глобальный maxconn был слишком высоким. Положите это примерно на 4000.
Очень важно понимать разницу между глобальным и серверным maxconn.
Вилли Тарро (автор HAProxy) очень ясно описывает это здесь: https://stackoverflow.com/questions/8750518/difference-between-global-maxconn-and-server-maxconn-haproxy
Я использую HAProxy в течение многих лет, и мое значение по умолчанию - 64 maxcon на внутренних серверах.
HAProxy обладает очень высокой производительностью и, безусловно, способен перегрузить веб-сервер при неправильной настройке. Взгляните на сетевые подключения веб-серверов и журналы ошибок, чтобы узнать, достигают ли они максимального количества подключений. Я не удивлюсь, если это так.