Число сеансов TCP HAProxy останавливается на 400 - PullRequest
6 голосов
/ 28 января 2011

Я пытаюсь HAProxy для балансировки нагрузки TCP.Соединения подключаются к порту X на одном IP-адресе, и HAProxy затем балансирует эти соединения с бэкэндом, используя метод балансировки «наименьшее количество подключений», чтобы сохранить количество соединений четным.Это на Ubuntu 10.04 x64.

Я настроил file-max в конфигурации ядра на 700 000.Я увеличил улит-процесс до 400 000.Я настроил maxconn в конфигурации haproxy на 200 000.Он сообщает, что видит этот штраф maxconn:

show info
Name: HAProxy
Version: 1.3.22
Release_date: 2009/10/14
Nbproc: 1
Process_num: 1
Pid: 1355
Uptime: 0d 4h38m46s
Uptime_sec: 16726
Memmax_MB: 0
Ulimit-n: 400013
Maxsock: 400013
Maxconn: 200000
Maxpipes: 0
CurrConns: 1113
PipesUsed: 0
PipesFree: 0
Tasks: 1113
Run_queue: 1
node: XXXXX

Это внешнее распределение нагрузки по 5 внутренним системам.Однако, когда он получает до 400 сеансов на бэкэнд, он просто прекращает балансировку и просто откладывает дополнительные подключения.Я могу видеть это со статом "smax".Вы заметите, что максимальное количество сеансов в каждом из них равно 400, а общее максимальное количество сеансов - 2000:

show stat
#
pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,
protoa,FRONTEND,,,958,2000,2000,12624,6230219,6445523,0,0,0,,,,,OPEN,,,,,,,,,1,1,0,,,,0,0,0,406,
protoa,XXX1672,0,0,191,400,,3222,1249403,1286659,,0,,221,0,664,0,no check,1,1,0,,,,,,1,1,1,,2559,,2,0,,198,
protoa,XXX1674,0,0,192,400,,3106,1242103,1289247,,0,,178,0,535,0,no check,1,1,0,,,,,,1,1,2,,2572,,2,0,,171,
protoa,XXX1707,0,0,193,400,,3043,1266305,1305311,,0,,164,0,492,0,no check,1,1,0,,,,,,1,1,3,,2551,,2,0,,161,
protoa,XXX1782,0,0,189,400,,3046,1236790,1282690,,0,,204,0,619,0,no check,1,1,0,,,,,,1,1,4,,2429,,2,0,,190,
protoa,XXX1851,0,0,193,400,,3060,1235618,1281616,,0,,189,0,570,0,no check,1,1,0,,,,,,1,1,5,,2490,,2,0,,180,
protoa,BACKEND,0,0,958,2000,2000,12624,6230219,6445523,0,0,,956,0,2880,0,UP,5,5,0,,0,17645,0,,1,1,0,,12601,,1,0,,406,
protob,FRONTEND,,,4,6,2000,28,15204,15726,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,2,
protob,XXX1672,0,0,2,2,,5,2313,2322,,0,,0,0,0,0,no check,1,1,0,,,,,,1,2,1,,5,,2,0,,1,
protob,XXX1674,0,0,0,2,,5,3520,3803,,0,,0,0,0,0,no check,1,1,0,,,,,,1,2,2,,5,,2,0,,1,
protob,XXX1707,0,0,0,2,,8,3303,3214,,0,,0,0,0,0,no check,1,1,0,,,,,,1,2,3,,8,,2,0,,1,
protob,XXX1782,0,0,1,2,,5,3529,3745,,0,,0,0,0,0,no check,1,1,0,,,,,,1,2,4,,5,,2,0,,1,
protob,XXX1851,0,0,1,1,,5,2539,2642,,0,,0,0,0,0,no check,1,1,0,,,,,,1,2,5,,5,,2,0,,1,
protob,BACKEND,0,0,4,6,2000,28,15204,15726,0,0,,0,0,0,0,UP,5,5,0,,0,17645,0,,1,2,0,,28,,1,0,,2,

Откуда исходит это ограничение?Я действительно хочу вложить сотни тысяч соединений в этот экземпляр haproxy.(У машины есть сеть, процессор и оперативная память для поддержки)

1 Ответ

11 голосов
/ 28 января 2011

Итак, читая исходный код версии 1.3.x, я обнаружил, что: Есть два максимума.Одним из них является глобальное max # connection, устанавливаемое с помощью -n в командной строке и maxconn в глобальной конфигурации.Другой тип - максимальное число подключений для прокси-сервера, установленное с помощью -N в командной строке или настроенное для каждого прокси в конфигурации.В частности, вы не можете настроить максимальное число подключений по умолчанию для каждого прокси, кроме как из командной строки!По умолчанию ... подождите ... 2000!Поэтому добавление «maxconn 200000» в каждый из разделов «listen» в моем файле /etc/haproxy/haproxy.cfg решает эту проблему.

Обратите внимание, что, несмотря на довольно хорошую документацию, это не помоглохорошая работа, чтобы объяснить это.В частности, прочитав документацию, я подумал, что глобальный maxconn будет применяться и к каждому прокси, но не так.Глобальное maxconn равно принудительно для общего числа соединений, но локальное максимальное количество соединений для данного внешнего прокси-сервера должно быть явно указано.

...