열린 포트가 부족한 바니시, 많은 SYN_SENT 연결

최근에 바니시 (3x)-> 아파치 (3x) 설정에 문제가 발생하여 SYN_SENT연결 이 크게 증가했습니다 .

스파이크 자체는 어떤 종류의 DDOS가 아닌 사이트를 방문하는 새로운 트래픽의 양으로 인한 것이며, 바니시 머신은 백엔드 서버로 트래픽을 전달하는 데 문제가있는 것 같습니다 (아파치 트래픽의 하락은 니스의 스파이크와 관련이 있습니다) )로 사용 가능한 포트 풀을 정체시킵니다 SYN_SENT.

Keep-alives는 Apache (15s)에서 활성화됩니다.

어느 쪽이 고장입니까? 트래픽 양은 많지만 그러한 설정 (3x Varnish 프론트 엔드 시스템, 3x 백엔드 Apache 서버)이 정지되는 경우는 없습니다.

도와주세요.

방화벽을 통한 연결에 대한 Munin 스크린 샷은 여기에 있습니다 .

광택 ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf(Varnish)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

아파치 netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (아파치)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

Apache 서버의 sysctl에 문제가있을 수 있습니다.

몇 가지 가정 : 일반적으로 Varnish는 웹 서버보다 각 연결을 처리하는 데 훨씬 빠릅니다 (Vanish 서버의 CPU가 훨씬 적고 Apache 서버가 메모리에 캐시 된 정적 파일 만 제공하지 않는 한) 연결 프로세스가 더 빠르다고 가정합니다. Apache보다 Varnish에서.

따라서 Apache 서버의 리소스는 충분할 수 있지만 요청은 아주 짧을 경우 어딘가에 대기해야합니다. 현재 그들은 결국 처리되는 건강한 방식으로 대기하지 않습니다.

귀하의 요청이 Varnish에서 중단되어 Apache 서버로 전송되지 않는 것 같습니다.

이에 대한 몇 가지 증거가 있습니다.

munin 그래프에서 SYN_SENT가 백업되기 전에 TIME_WAIT의 요청이 증가한 다음, 포인트 후에 SYN_SENTS로 쌓이기 시작합니다. 이는 요청이 더 느리게 응답되기 시작하고 큐가 백업되고 요청에 전혀 응답하지 않음을 나타냅니다.

이것은 Apache 서버가 충분한 연결을 수락하지 않았 음을 나타냅니다 (Apache가 처리하기 위해 앉아서 대기열에 넣을 수 있음).

구성 파일에 몇 가지 가능한 제한이 있습니다.

스파이크가 발생하면 Varnish 서버의 SYN_SENT 상태에 약 30000 개의 연결이 있습니다.

그러나 Apache 서버에서 max_syn_backlog는 16384입니다. somaxconn은 2048입니다.

Apache 서버의 네트워크 메모리 버퍼 크기도 매우 낮습니다. Varnish 서버에서 16MB로 조정했습니다. 그러나 Apache 서버에서 net.ipv4.tcp_rmem은 net.core.rmem_max와 일치하도록 524KB에 불과합니다.

Apache 서버에서 이러한 모든 매개 변수를 올리는 것이 좋습니다.

무슨 일이 일어나고 있는지 정확히 파악하려면 Apache 서버의 진단에 더 집중해야하지만 이러한 값을 높이면 필요하지 않을 수 있습니다.

net.ipv4.tcp_mem을 조정해서는 안됩니다. 이 매개 변수의 단위는 바이트가 아닌 페이지 단위이므로 net.ipv4.tcp_rmem 또는 net.ipv4.tcp_wmem (둘 다 바이트)에서 동일한 값을 복사하는 것은 의미가 없습니다. 메모리 양에 따라 Linux에서 자동 조정되므로 조정이 거의 필요하지 않습니다. 실제로 이것은 전체 연결 대기열에 사용할 수있는 메모리를 임의로 제한하여 문제가 될 수 있습니다.

참조 : http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

또한 "vm.swappiness = 0"이 두 번, 한 번 10으로, 아래쪽에서 다시 0으로 설정되어 유효 값입니다.

Varnish 서버에서 다음 두 매개 변수를 변경하십시오.

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuse를 사용하면 TIME_WAIT에서 연결을 재사용 할 수 있습니다.

tw_recycle은로드 밸런서 등에 문제를 일으킬 수 있습니다.