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


91

내 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이 있습니다. 내 생각은 이것이다 : 글로벌 하나는 서비스로서 haproxy가 한 번에 대기열에 넣거나 처리 할 총 연결 수를 관리합니다. 숫자가 그 이상이면 연결이 끊어 지거나 일부 Linux 소켓에서 풀이 발생합니까? 그 수가 4000보다 커지면 어떻게되는지 모르겠습니다.

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

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

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

  1. 글로벌 연결이 4000을 초과하면 어떻게됩니까? 그들은 죽습니까? 아니면 리눅스에서 풀?
  2. 글로벌 연결보다 더 많은 총 서버 연결 수를 가질 수 없다는 사실 외에는 글로벌 연결이 서버 연결과 관련이 있습니까?
  3. 글로벌 연결을 파악할 때 서버 섹션에 추가 된 연결 수에 풀링을위한 특정 비율을 더한 것이 아닙니까? 그리고 분명히 연결에 대한 다른 제한이 있지만 실제로 프록시에 보내려는 수는 얼마입니까?

미리 감사드립니다.

답변:


167

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


10
게시 해 주셔서 감사합니다.
Tarantula

9
약 200 개의 다른 백엔드를 프록시하는 하나의 haproxy가 있습니다. 백엔드가 약 30 만 개의 코니 톤 / 초로 DDOS로 처리되면 다른 모든 백엔드는 죽습니다. 백엔드 서버 (ddos 아래)에서 maxconn 2048 값을 사용하면 haproxy가 제대로 실행됩니다. 정말 감사합니다, 당신은 내게 밤 :) 저장
hungnv을
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.