웹 서버가 높은로드에서 TCP 재설정으로 연결을 끊는 이유는 무엇입니까?

nginx로 작은 VPS 설정이 있습니다. 최대한 많은 성능을 발휘하고 싶기 때문에 최적화 및로드 테스트를 실험하고 있습니다.

Blitz.io를 사용하여 작은 정적 텍스트 파일을 가져 와서로드 테스트를 수행하고 동시 연결 수가 약 2000에 도달하면 서버가 TCP 재설정을 보내는 것처럼 보이는 이상한 문제가 발생합니다. 많은 양이지만 htop을 사용하여 서버에 여전히 CPU 시간과 메모리를 아끼지 않아도 되므로이 문제의 원인을 파악하여 더 밀어 넣을 수 있는지 확인하고 싶습니다.

2GB Linode VPS에서 Ubuntu 14.04 LTS (64 비트)를 실행하고 있습니다.

이 그래프를 직접 게시 할 정도로 평판이 좋지 않으므로 Blitz.io 그래프에 대한 링크가 있습니다.

다음은 문제의 원인을 파악하기 위해 수행 한 작업입니다.

• nginx 구성 값 worker_rlimit_nofile이 8192로 설정되었습니다.
• 한 nofile모두 하드와 소프트 한계에 대한 64000로 설정 root하고 www-data사용자 (로 실행을 nginx에 무엇을)에서/etc/security/limits.conf

• 아무것도 잘못되었다는 징후가 없습니다 /var/log/nginx.d/error.log(일반적으로 파일 디스크립터 한계에 도달하면 nginx가 오류 메시지를 표시합니다)

• ufw 설정이 있지만 속도 제한 규칙이 없습니다. ufw 로그는 아무것도 차단되지 않았 음을 나타내며 동일한 결과로 ufw를 비활성화하려고 시도했습니다.

• 에 표시 오류가 없습니다 /var/log/kern.log
• 에 표시 오류가 없습니다 /var/log/syslog

• 다음 값을 추가하고 아무런 효과없이 /etc/sysctl.conf로드했습니다 sysctl -p.

  net.ipv4.tcp_max_syn_backlog = 1024
  net.core.somaxconn = 1024
  net.core.netdev_max_backlog = 2000
  

어떤 아이디어?

편집 : 새로운 테스트를 수행하여 매우 작은 파일 (3 바이트 만)에서 3000 연결로 상승했습니다. Blitz.io 그래프는 다음과 같습니다.

다시 한번, Blitz에 따르면 이러한 모든 오류는 "TCP 연결 재설정"오류입니다.

Linode 대역폭 그래프는 다음과 같습니다. 이것은 평균 5 분이므로 로우 패스가 비트를 필터링 (순간 대역폭이 훨씬 높을 수 있음)하지만 여전히 아무것도 아닙니다.

CPU :

I / O :

htop테스트 가 거의 끝났습니다.

또한 다른 (그러나 비슷한 모양의) 테스트에서 tcpdump를 사용하여 일부 트래픽을 캡처하여 오류가 발생하기 시작했을 때 캡처를 시작했습니다. sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

누군가가 그것을 보길 원한다면 파일은 다음과 같습니다 (~ 20MB) : https://drive.google.com/file/d/0B1NXWZBKQN6ETmg2SEFOZUsxV28/view?usp=sharing

Wireshark의 대역폭 그래프는 다음과 같습니다.

(라인은 모든 패킷, 파란색 막대는 TCP 오류입니다)

캡처에 대한 나의 해석 (그리고 나는 전문가가 아닙니다)에서 TCP RST 플래그가 서버가 아닌로드 테스트 소스에서 오는 것처럼 보입니다. 따라서로드 테스트 서비스 측면에서 잘못된 것이 아니라고 가정하면 이것이로드 테스트 서비스와 내 서버 간의 일종의 네트워크 관리 또는 DDOS 완화의 결과라고 가정하는 것이 안전합니까?

감사!

연결 재설정 소스는 얼마든지있을 수 있습니다. 로드 테스터가 사용 가능한 임시 포트가 부족하여 연결을 시작할 수 있습니다. NAT를 수행하는 방화벽과 같은 디바이스는 NAT 풀이 소진되어 연결에 대한 소스 포트를 제공 할 수 없습니다. 연결 제한에 도달했을 수있는로드 밸런서 또는 방화벽? 인바운드 트래픽에서 소스 NAT를 수행하는 경우 포트 소진이 발생할 수도 있습니다.

실제로 양쪽 끝에서 pcap 파일이 필요합니다. 당신이 찾고 싶은 것은 연결 시도가 전송되었지만 서버에 도달하지는 않지만 여전히 서버에 의해 재설정 된 것처럼 보입니다. 이 경우 회선을 따라 연결을 재설정해야합니다. NAT 풀 고갈은 이러한 종류의 문제의 일반적인 원인입니다.

또한 netstat -st는 추가 정보를 제공 할 수 있습니다.

최근의 비슷한 튜닝 경험을 바탕으로 시도해 볼 몇 가지 아이디어. 참고로 :

정적 텍스트 파일이라고 말합니다. 업스트림 처리가 진행중인 경우 도메인 소켓은 TC 포트 기반 연결을 통해 TCP 처리량을 향상시킵니다.

https://rtcamp.com/tutorials/php/fpm-sysctl-tweaking/ https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads

업스트림 종료에 관계없이 :

multi_accept 및 tcp_nodelay 활성화 : http://tweaked.io/guide/nginx/

TCP 슬로우 스타트 비활성화 : /programming/17015611/disable-tcp-slow-start http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/

TCP 혼잡 최적화 창 (initcwnd) : http://www.nateware.com/linux-network-tuning-for-2013.html

열린 파일의 최대 수를 설정하려면 (문제가 발생한 경우) /etc/sysctl.conf에 "fs.file-max = 64000"을 추가해야합니다.

TIME_WAIT명령을 사용하여 몇 개의 포트가 상태인지 확인 하고 1로 netstat -patunl| grep TIME | wc -l변경하십시오 net.ipv4.tcp_tw_reuse.