Windows 2008에서 TIME_WAIT 상태의 TCP 연결 톤-Amazon AWS에서 실행

OS : Windows Server 2008, SP2 (EC2 Amazon에서 실행)

Apache httpd & Tomcat Server 6.02 및 웹 서버를 사용하여 웹앱을 실행하면 연결 유지 설정이 있습니다.

TIME_WAIT 상태 (netstat 및 tcpview 사용)에 약 69,250 (http 포트 80) + 15000 (포트 80 이외) TCP 연결이 있습니다. 웹 서버를 중지 한 후에도이 연결이 닫히지 않는 것 같습니다 (24 시간 동안 대기)

성능 모니터 카운터 :

• TCPv4 활성 연결 : 145K
• TCPv4 수동 연결 : 475K
• TCPv4 실패 연결 : 16K
• TCPv4 연결 재설정 : 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay 키가 없으므로 값은 기본값이어야합니다 (2 * MSL, 4 분).

동시에 수천 개의 연결 요청이 발생하더라도 Windows OS에서 결국이를 정리할 수없는 이유는 무엇입니까?
이 상황의 원인은 무엇입니까?
Windows OS를 다시 시작하지 않고 이러한 모든 TIME_WAIT 연결을 강제로 닫을 수있는 방법이 있습니까?

며칠 후 앱에서 새로운 연결을 중단합니다.

우리는이 문제도 다루었습니다. 아마존이 근본 원인을 찾아서 수정 한 것처럼 보입니다. 그들이 나에게 준 정보는 다음과 같습니다.

안녕하세요,이 문제의 원인에 대한 설명을 아래에 붙여 넣습니다. 좋은 소식은이 문제가 최근 엔지니어링 팀에 의해 수정되었다는 것입니다. 수정하려면이 문제가 발생한 Windows Server 2008 인스턴스를 중지 / 시작하기 만하면됩니다. 다시, 나는 다른 REBOOT에 대해 이야기하고 있지 않습니다. STOP / START는 인스턴스를 다른 (정상) 호스트로 이동시킵니다. 이러한 인스턴스가 다시 시작되면 수정 사항이있는 호스트에서 실행되므로이 ​​문제가 다시 발생하지 않습니다. 다음은이 문제에 대한 엔지니어링 설명입니다. 자세히 조사한 결과, 대부분의 사용 가능한 인스턴스 유형에서 Windows 2008 x64를 실행할 때 ve는 TCP 연결이 TIME_WAIT / CLOSE_WAIT에 지나치게 오랜 시간 동안 (어떤 경우에는이 상태를 무기한으로 유지함) 유지할 수있는 문제를 식별했습니다. 이러한 상태에서 특정 소켓 쌍을 사용할 수없는 상태로 유지하고 충분히 축적되면 해당 포트의 포트가 소진됩니다. 이러한 특정 상황이 발생하면 해당 소켓 쌍을 지우는 유일한 해결책은 해당 인스턴스를 재부팅하는 것입니다. 우리는 그 원인이 Windows 2008 커널 API의 타이머 함수에 의해 생성 된 값인 것으로 판명되었으며, 이는 많은 64 비트 플랫폼에서 때때로 미래에 극히 멀리있는 값을 검색 할 것입니다. 이는 TCP 소켓 쌍의 타임 스탬프가 향후 훨씬 더 많이 스탬핑되도록하여 TCP 스택에 영향을줍니다. Microsoft에 따르면이 API 호출로 생성 된 값이 누적 값보다 크지 않으면 업데이트되지 않는 저장된 누적 카운터가 있습니다. 궁극적으로이 시점 이후에 작성된 소켓은 미래 시간에 도달 할 때까지 미래에 너무 멀리 스탬핑됩니다. 어떤 경우에는,이 값이 미래에 수 백일 동안 보였으므로 소켓 쌍이 영원히 붙어있는 것처럼 보입니다.

Ryan의 답변은 Ravi가 EC2에서 겪고있는 조건에 적용되지 않는다는 점을 제외하고는 일반적인 조언입니다. 우리도이 문제와 Windows가 TcpTimedWaitDelay를 완전히 무시하고 TIMED_WAIT 상태에서 소켓을 해제하지 않는 이유를 보았습니다.

기다리는 것이 도움이되지 않습니다 ... 앱을 다시 시작해도 도움이되지 않습니다 ... 발견 한 유일한 해결책은 OS를 다시 시작하는 것입니다. 정말 못 생겼어

별도의 문제를 디버깅하는 동안이 스레드를 완전히 무작위로 찾았지만 EC2의 Windows에서는 잘 알려지지 않았지만 잘 알려진 문제입니다. 우리는 프리미엄 지원을 위해 사용하고, 그 채널을 통해 비공개 설정에서 그들과 함께이 문제를 논의하지만, 이것은 우리가하는 관련 문제 않았다 공개 포럼에서 논의 .

다른 사람들이 언급했듯이 Windows Server를 즉시 조정해야합니다. 그러나 StopWatch가 위의 스레드에서 작동하지 않는 것과 같은 방식으로 TCP / IP 스택은 QueryPerformanceCounter호출을 사용 하여 TCP_TIME_WAIT 기간이 언제 지속되어야 하는지를 정확하게 결정합니다. 문제는 EC2에서 QueryPerformanceCounter헤이 와이어 가 발생하는 문제를 발견하고 알게 되었으며 미래에 훨씬 더 많은 시간을 돌려 줄 수 있다는 것입니다. TIME_WAIT 상태가 무시되는 것이 아니라 TIME_WAIT의 만료 시간이 향후 몇 년이 될 수 있습니다. httpd 설정에서 실행할 때 상태가 발생하면 이러한 좀비 소켓을 빠르게 누적하는 방법을 볼 수 있습니다 (일반적으로 좀비가 천천히 누적되는 것이 아니라 개별 이벤트임을 알 수 있습니다).

우리가하는 일은 TIME_WAIT 상태의 소켓 수를 쿼리하는 백그라운드에서 서비스를 실행하는 것입니다.이 임계 값을 초과하면 조치를 취합니다 (서버 재부팅). 어떻게 든 지난 45 초 동안 누군가가 서버를 중지 / 시작하여 문제를 해결할 수 있다고 지적했습니다.이 두 가지 접근 방식을 결합하는 것이 좋습니다.

Windows에서 TCP 스택의 기본 설정은 HTTP 서버를 호스팅 할 시스템에 가장 적합하지 않은 것입니다.

HTTP 서버로 사용될 때 Windows 시스템을 최대한 활용하기 위해 일반적으로 MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval 등과 같은 몇 가지 매개 변수가 있습니다.

몇 년 전에 시작해야 할 빠른 기본값이 필요한 경우를 대비 하여 메모를 작성했습니다 . 매개 변수를 이해하고 조정하십시오.

AWS와 관련이 없어서이 문제가 발생했습니다.이 KB 기사의 결과 인 것 같습니다.

http://support.microsoft.com/kb/2553549/en-us

기본적으로 시스템이 497 일 이상 가동되고 핫픽스가 적용되지 않은 경우 시작됩니다. 물론 재부팅해도 문제가 해결되었습니다. 핫픽스가 작동 한 경우 다음 16 개월 동안은 알지 못할 수도 있지만 서버가 오래 가동 된 사용자에게는 도움이 될 수 있습니다.

Windows Server 2008 R2 x64 SP1과 함께 대부분의 상자에서 거의 똑같은 문제가 발생했으며 대부분 CLOSE_WAIT (TIME_WAIT와 약간 다름)입니다. 서버가로드 밸런서 (내)에서 실행중인 경우 Microsoft 의 KB와 핫픽스 를 참조하는 이 답변에 부딪 쳤습니다 . 핫픽스를 설치하고 재부팅 한 후 모든 CLOSE_WAIT 항목이 해결되었습니다.