Я установил два выделенных сервера haproxy, чтобы распределить нагрузку на три сервера приложений. Я установил обычную балансировку http 80, а также специальную для работы с веб-сокетами.
Он отлично работает около 2 часов, но после этого он становится очень медленным, загрузка страницы занимает около 30 секунд. Когда я перезапускаю haproxy, снова все в порядке.
Ниже мой конф. Есть идеи, что может быть причиной этого?
global
user haproxy
group haproxy
defaults
mode http
timeout connect 5s
timeout client 5s
timeout server 60s
stats enable
stats auth aa:bb
frontend proxy
# listen on 80
bind 0.0.0.0:80
# allow for many connections, with long timeout
maxconn 200000 # total maximum connections, check ulimit as well
timeout client 24h
# default to webapp backend
default_backend webapp
# is this a socket io request?
acl is_websocket hdr_end(host) -i node.domain.com
use_backend websocket if is_websocket
backend webapp
balance roundrobin # assuming that you don't need stickiness
# allow client connections to linger for 5s
# but close server side requests to avoid keeping idle connections
option httpchk HEAD /check.txt HTTP/1.0
option http-server-close
option forwardfor
server app1 x.y.149.133:80 cookie app1 weight 10 check
server app2 x.y.149.134:80 cookie app2 weight 15 check
server app3 x.y.149.135:80 cookie app3 weight 15 check
backend websocket
balance source
# options
option forwardfor # add X-Forwarded-For
# Do not use httpclose (= client and server
# connections get closed), since it will close
# Websockets connections
no option httpclose
# Use "option http-server-close" to preserve
# client persistent connections while handling
# every incoming request individually, dispatching
# them one after another to servers, in HTTP close mode
option http-server-close
option forceclose
server app1 x.y.149.133:3000 cookie app1 weight 10 check
server app2 x.y.149.134:3000 cookie app2 weight 15 check
server app3 x.y.149.135:3000 cookie app3 weight 15 check
Что обычно отличает веб-сокеты от вашей повседневной балансировки нагрузки http, так это то, что вы получаете большое количество одновременных подключений по сравнению со скоростью поступления. Это важное различие в системах, поэтому, если вам непонятно, посмотрите на этот мой ответ.
Итак, какой бы ни была ваша проблема, я предполагаю, что она возникает, когда вы достигаете определенного порога одновременные соединения. Вот мое лучшее предположение, основанное на предоставленной вами информации:
Внутренние веб-сокеты содержат 3 сервера. Балансировщик нагрузки общается со всеми с одного IP-адреса. Это означает, что у вас есть всего IP-адресов source_port_range * destination. Это выглядит примерно так:
[root@ny-kbrandt01 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
[root@ny-kbrandt01 ~]# echo $(( (61000-32768) * 3 ))
84696
Таким образом, когда вы попадаете где-то около 84 тыс. Соединений, ваши экземпляры haproxy испытывают нехватку исходных портов, загрузка процессора резко возрастает, поскольку он делает что-то вроде сборки мусора, чтобы найти больше исходных портов.
Если это не так, держу пари, что это что-то в этом переулке, отслеживайте ваши одновременные соединения с помощью страницы статистики haproxy и отслеживайте свой процессор, чтобы лучше понимать, что происходит, когда все замедляется.