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

Настройка HAProxy - не может поддерживать более 50 одновременных пользователей

Я собираюсь заменить проприетарный программный балансировщик нагрузки на 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 обладает очень высокой производительностью и, безусловно, способен перегрузить веб-сервер при неправильной настройке. Взгляните на сетевые подключения веб-серверов и журналы ошибок, чтобы узнать, достигают ли они максимального количества подключений. Я не удивлюсь, если это так.