TIME_WAIT(실제로 그 중 다수)가 우리 서버 중 하나의 속도 저하의 실제 원인이라는 확실한 증거가 필요합니다. 서버는 Parallels Baremetal 가상화에서 호스팅되며 실제 서버는 듀얼 CPU 및 2GB RAM을 갖춘 CentOS5라는 가상 머신입니다.
일주일 전부터 우리는 속도가 너무 느려서 몇 개의 파일(약 20개)만 있는 디렉터리에서 "ls"를 실행해도 결과를 표시하는 데 약 1.5초가 걸린다는 사실을 깨닫기 시작했습니다.
나는 이것을 시도했지만 vmstat그것을 사용하는 스왑이없는 것 같습니다. 네트워크에 병목 현상이 없습니다. 하지만 을 실행하면 topJava가 주로 리소스를 소비하는 것을 볼 수 있습니다. VM이 허드슨 서버이기 때문에 Java가 필요합니다.
내 동료 중 한 명이 다음을 통해 연결을 확인하려고 했습니다.
$ vmstat -vatpno
그리고 TIME_WAIT 상태에 약 300개 이상의 연결이 많이 있음을 확인했습니다. 그래서 우리는 이러한 제안 중 일부를 적용하려고 노력합니다.이 페이지특히 TCP_FIN_TIMEOUT, TCP_KEEPALIVE_INTERVAL 및 TCP_KEEPALIVE_PROBES입니다. TIME_WAIT의 연결 수가 감소했지만 여전히 220에서 280 사이에서 변동합니다(아마도 TIME_WAIT의 다른 연결이 아직 "시간 초과"되지 않은 반면 때때로 새 연결이 추가되기 때문일 수 있음). 나중에 개선이 보이지 않으면 TCP_TW_RECYCLE 및 TCP_TW_REUSE를 추가해 볼 수 있습니다.
이제 주요 질문으로 돌아가겠습니다. 다수의 TIME_WAIT 연결이 많은 RAM을 소비한다는 확실한 증거가 있습니까?
답변1
TIME_WAIT 상태의 연결은 다른 연결의 패킷과 섞이지 않도록 다른 쪽 끝에서 네트워크를 통해 들어오는 마지막 길 잃은 패킷이 있는지 확인하기 위해 단순히 기다리고 있습니다. 실제로는 없습니다하다이 패킷과 관련된 모든 것. 따라서 TIME_WAIT 연결은 열린 연결보다 적은 리소스를 사용합니다.
오늘날의 잘 구성된 웹 서버10,000개 이상의 동시 연결을 처리할 수 있습니다.(이 글은 2003년에 작성되었으며 무어의 법칙은 계속 발전하고 있습니다.) 어쨌든 TIME_WAIT 상태의 연결은 열린 연결보다 적은 메모리를 차지하므로 TIME_WAIT 상태의 300개 연결은 아무 것도 아닙니다.
TIME_WAIT에 대한 자세한 내용은 다음을 참조하세요.http://tangentsoft.net/wskfaq/articles/debugging-tcp.html그리고http://developerweb.net/viewtopic.php?id=2941.
또한, 귀하의 디스크 I/O 사용량이 어떤지 알고 싶습니다. 내 경험에 따르면 과도한 디스크 I/O는 과도한 CPU 사용량보다 Linux 커널 속도를 더 쉽게 저하시킵니다. 그들이 말하는 내용을 확인하려면 조사 iostat와 도구가 필요할 수 있습니다 .dstat