Ниже приведена моя конфигурация haproxy.
global
log /dev/log local0 notice
log /dev/log local0 debug
log 127.0.0.1 local0
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
maxconn 5000
defaults
log global
mode tcp
option tcplog
option tcpka
timeout connect 60s
timeout client 1000s
timeout server 1000s
frontend aviator-app
option tcplog
log /dev/log local0 debug
bind *:4433 ssl crt /etc/haproxy/certs/{domain_name}.pem
mode tcp
option clitcpka
option http-server-close
maxconn 5000
default_backend aviator-app-pool
# Table definition
stick-table type ip size 2000k expire 30s store conn_cur
# Allow clean known IPs to bypass the filter
tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
# Shut the new connection as long as the client has already 100 opened
# tcp-request connection reject if { src_conn_cur ge 500 }
tcp-request connection track-sc1 src
backend aviator-app-pool
option tcplog
log /dev/log local0 debug
balance roundrobin
mode tcp
option srvtcpka
option http-server-close
maxconn 50
# list each server
server appserver1 10.0.1.205 maxconn 12
server appserver2 10.0.1.183 maxconn 12
server appserver3 10.0.1.75 maxconn 12
server appserver4 10.0.1.22 maxconn 12
# end of list
listen stats
bind *:8000
mode http
log global
maxconn 10
clitimeout 100s
srvtimeout 100s
contimeout 100s
timeout queue 100s
stats enable
stats hide-version
stats refresh 30s
stats show-node
stats auth username:password
stats uri /haproxy?stats
Когда я запускаю нагрузочный тест с 12-13 HTTP-запросами в секунду, я не вижу никаких ошибок примерно в течение первого часа теста. Но примерно через 90 минут после начала теста большое количество запросов перестает работать. Сообщение об ошибке от jmeter обычно гласит: «Истекло время ожидания подключения: подключение» или «имя_домена: 4433 не удалось ответить». Ниже приведены некоторые сообщения журнала из haproxy.log. Я также вижу большое количество «ошибок подключения», как показано на изображении выше, и несколько «ошибок».
May 7 19:15:00 ip-10-0-0-206 haproxy[30349]: 64.112.179.79:55894
[07/May/2018:19:14:00.488] aviator-app~ aviator-app-pool/<NOSRV>
60123/-1/60122 0 sQ 719/718/717/0/0 0/672
May 7 19:15:00 ip-10-0-0-206 haproxy[30349]: 64.112.179.79:49905
[07/May/2018:19:12:53.483] aviator-app~ aviator-app-pool/appserver2
60022/1/127171 2283568 -- 719/718/716/11/0 0/666
Я не вижу ошибок или трассировки стека на моих внутренних серверах. Использование ЦП на балансировщике нагрузки во время теста низкое (менее 10%) для балансировщика нагрузки и около 30% для каждого внутреннего сервера. Любая помощь в устранении этой проблемы приветствуется.
В вашем бэкэнд есть maxconn 50
поэтому HAProxy ставит переполнение в очередь, ожидая завершения одного из существующих 50. Когда каждое соединение разрывается, к серверной части разрешается еще одно ... но ваша серверная часть работает недостаточно быстро. Запросы копируются на прокси-сервере, и в конечном итоге прокси-сервер разрывает их после того, как они попадают в очередь прокси для timeout connect 60s
.
В sQ
в записи журнала это объясняет.
s
: время ожидания на стороне сервера истекло во время ожидания отправки или получения данных сервером.
Q
: прокси ожидал в ОЧЕРЕДИ слота подключения. Это может произойти, только если на серверах установлен параметр maxconn.
Видеть Состояние сеанса при отключении в руководстве по настройке HAProxy.