[haproxy] 글로벌 maxconn과 서버 maxconn haproxy의 차이점

Willy는 이메일로 답변을 받았습니다. 나는 그것을 나눌 것이라고 생각했다. 그의 대답은 대담합니다.

내 haproxy 구성에 대한 질문이 있습니다.

   #---------------------------------------------------------------------
   # Global settings
   #---------------------------------------------------------------------
   global
       log         127.0.0.1 syslog emerg
       maxconn     4000
       quiet
       user        haproxy
       group       haproxy
       daemon
   #---------------------------------------------------------------------
   # common defaults that all the 'listen' and 'backend' sections will
   # use if not designated in their block
   #---------------------------------------------------------------------
   defaults
       mode        http
       log         global
       option      abortonclose
       option      dontlognull
       option      httpclose
       option      httplog
       option      forwardfor
       option      redispatch
       timeout connect 10000 # default 10 second time out if a backend is not found
       timeout client 300000 # 5 min timeout for client
       timeout server 300000 # 5 min timeout for server
       stats       enable

   listen  http_proxy  localhost:81

       balance     roundrobin
       option      httpchk GET /empty.html
       server      server1 myip:80 maxconn 15 check inter 10000
       server      server2 myip:80 maxconn 15 check inter 10000

보시다시피 간단하지만 maxconn 속성이 작동하는 방식에 대해 약간 혼란 스럽습니다.

청취 블록에는 서버의 글로벌 및 maxconn이 있습니다.

또한 수신 블록에는 2000과 같은 기본값으로 설정된 또 다른 하나가 있습니다.

내 생각은 이것이다 : 글로벌 하나는 haproxy가 서비스로서 한 번에 쿼리하거나 처리 할 총 연결 수를 관리합니다.

옳은. 프로세스 당 최대 동시 연결 수입니다.

숫자가 그 이상이면 연결이 끊어 지거나 일부 Linux 소켓에서 풀이 발생합니까?

나중에 새로운 연결을 받아들이지 않고 커널의 소켓 대기열에 남아 있습니다. 대기열에 넣을 수있는 소켓의 수는 (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog 및 청취 블록의 maxconn)의 최소값에 의해 결정됩니다.

그 수가 4000보다 커지면 어떻게되는지 모르겠습니다.

초과 연결은 수락되기 전에 다른 연결이 완료 될 때까지 기다립니다. 그러나 커널의 대기열이 포화 상태가 아닌 한 클라이언트는 연결이 TCP 수준에서 허용되지만 처리되지 않기 때문에이를 알지 못합니다. 따라서 클라이언트는 요청을 처리하는 데 약간의 지연 만 인식합니다. 그러나 실제로는 수신 블록의 maxconn이 훨씬 더 중요합니다. 기본적으로 전역 블록보다 작기 때문입니다. 청취의 maxconn은 청취자 당 연결 수를 제한합니다. 일반적으로 서비스에 대해 원하는 연결 수로 구성하고 haproxy 프로세스가 처리하도록 허용하는 최대 연결 수로 전역 maxconn을 구성하는 것이 좋습니다. 서비스가 하나만있는 경우 둘 다 동일한 값으로 설정할 수 있습니다. 하지만 서비스가 많으면

그런 다음 서버 maxconn 속성을 15로 설정했습니다. 먼저 php-fpm이 별도의 서버에 전달되고 사용할 수있는 자식 프로세스가 너무 많기 때문에 15로 설정했습니다. php-fpm 대신 여기에서 요청을 풀링합니다. 더 빠르다고 생각합니다.

예, 더 빨라질뿐만 아니라 haproxy가 가능할 때마다 사용 가능한 다른 서버를 찾을 수 있도록하고 연결이 서버로 전달되기 전에 클라이언트가 “중지”에 도달하면 큐에서 요청을 종료 할 수 있습니다.

그러나 주제로 돌아가서이 숫자에 대한 나의 이론은이 블록의 각 서버가 한 번에 15 개의 연결 만 전송된다는 것입니다. 그런 다음 연결은 열린 서버를 기다립니다. 쿠키가 켜져 있으면 연결이 올바른 개방형 서버를 기다립니다. 하지만 그렇지 않습니다.

이것이 바로 원칙입니다. 프록시 당 대기열과 서버 당 대기열이 있습니다. 지속성 쿠키가있는 연결은 서버 큐로 이동하고 다른 연결은 프록시 큐로 이동합니다. 그러나 귀하의 경우에는 쿠키가 구성되지 않았으므로 모든 연결이 프록시 대기열로 이동합니다. 원한다면 haproxy 소스에서 doc / queuing.fig 다이어그램을 볼 수 있으며, 결정이 어떻게 / 어디에 있는지 설명합니다.

따라서 질문은 다음과 같습니다.

1. 글로벌 연결이 4000을 초과하면 어떻게됩니까? 그들은 죽습니까? 아니면 리눅스에서 풀?

   그들은 리눅스에서 대기열에 있습니다. 커널의 대기열을 압도하면 커널에서 삭제됩니다.

2. 글로벌 연결보다 더 많은 총 서버 연결 수를 가질 수 없다는 사실 외에는 글로벌 연결이 서버 연결과 관련이 있습니까?

   아니요, 글로벌 및 서버 연결 설정은 독립적입니다.

3. 글로벌 연결을 파악할 때 서버 섹션에 추가 된 연결 수에 풀링을위한 특정 비율을 더한 것이 아닙니까? 그리고 분명히 연결에 대한 다른 제한이 있지만 실제로 프록시에 보내려는 수는 얼마입니까?

   맞아요. 서버의 응답 시간이 짧은 경우에는 요청 처리 시간이 크게 줄어들 기 때문에 한 번에 몇 개만 서비스하도록 수천 개의 연결을 큐에 넣는 것이 잘못된 것은 아닙니다. 실제로 오늘날 연결을 설정하는 데는 기가비트 LAN에서 약 5 마이크로 초가 걸립니다. 따라서 haproxy가 매우 작은 maxconn을 사용하여 대기열에서 서버로 가능한 한 빨리 연결을 배포하도록하는 것이 좋습니다. 한 게임 사이트가 30000 개 이상의 동시 연결을 대기열에두고 서버 당 30 개의 대기열로 실행되는 것을 기억합니다! 아파치 서버 였고 아파치는 많은 수보다 적은 수의 연결로 훨씬 빠릅니다. 하지만이를 위해서는 정말 빠른 서버가 필요합니다. t 서버가 예를 들어 데이터베이스를 기다리고 있기 때문에 모든 클라이언트가 연결 슬롯을 기다리고 있기를 원합니다. 또한 매우 잘 작동하는 것은 전용 서버입니다. 사이트에 많은 정적이있는 경우 정적 요청을 서버 (또는 캐시) 풀로 보내서 정적 요청을 대기열에 넣지 않고 정적 요청이 값 비싼 연결 슬롯을 차지하지 않도록 할 수 있습니다. 이것이 도움이되기를 바라며, Willy