Application hang 으로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항
Hang은 웹 서버로부터 응답이 없어서 화면이 로딩 중이거나 혹은 빈 페이지로 표시되는 증상입니다. 또는 웹 서버로부터 응답이 상당히 느린 경우도 이에 해당됩니다. 문제 발생 하였던 시점의 이벤트 로그에 다음과 같은 경고 메시지가 남을 수 있습니다.
|
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1013
Description:
A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
The process id was <id>.
(응용 프로그램 풀 '%1'을(를) 지원하는 프로세스를 종료하는 동안 제한 시간이 초과되었습니다.
프로세스 ID는 '%2'입니다.)
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1010
Description:
A process serving application pool 'DefaultAppPool' failed to respond to a ping.
The process id was '<PID>'.
(응용 프로그램 풀 '%1'에 사용되는 프로세스가 Ping에 응답하지 못했습니다.
프로세스 ID는 '%2'입니다.) |
문제 발생 원인 파악을 위해서는 메모리 Dump를 수집하여야 합니다.
IIS Diagnostics Toolkit (x86)
http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en
문제 발생시 Debug Diagnostic tool에서 Tools 탭에 있는 “Create IIS Hang Dump”를 2~3번 정도 클릭하여 수동으로 Hang dump를 수집합니다. 단, IIS 관리자에서 모든 재활용 옵션을 체크하지 않은 상태에서 수집하셔야 합니다.
Hang은 CPU, Memory를 지속적으로 많이 소비하는 증상을 동반할 수도 있습니다. 이는 문제 발생 시 CPU와 memory 사용량이 어느정도인지 작업 관리자에서 확인이 가능합니다. 성능 탭에서 CPU 사용량과 할당된 메모리를 확인하고, 프로세스 탭에서 VM크기를 통해 프로세스별로 할당된 메모리의 양을 확인합니다. 성능 카운터 로그를 통해서도 리소스 사용량을 확인할 수 있는데, 다음 기술 문서에 나온 항목을 체크합니다.
http://technet.microsoft.com/ko-kr/library/cc671175.aspx
CPU/Memory 사용량이 높은 Hang 증상의 대표적인 원인을 알아보면, String Manipulation, Garbage Collection, 그리고 Infinite Loop 수행이 있습니다.
1. String Manipulation
문자열 연결을 자주 수행할 때 High CPU Hang이 발생할 수 있습니다. 따라서, 문자열 조작이 필요한 경우에는 String 개체 대신 StringBuilder를 사용하시기 바랍니다.
PRB: 웹 서비스 또는 Web Form의 높은 CPU 사용
http://support.microsoft.com/kb/307340
2. Garbage Collection
Garbage Collection이란 개발자로 하여금 메모리 관리 작업을 단순하게 처리하게끔 도와주는 매커니즘입니다. 하지만 빈번한 GC 작업은 웹 서버의 성능에 많은 영향을 주게 됩니다.
Garbage Collection: Microsoft .NET Framework의 자동 메모리 관리
http://www.microsoft.com/Korea/MSDN/MSDNMAG/ISSUES/2000/GCI/default.aspx
3. Infinite Loop
이는 개발자가 소스 코드에서 어떤 부분이 무한루프 수행을 유발시키는지 디버깅해야 합니다.
반면 CPU/Memory 사용량이 낮은 Hang 증상의 대표적인 원인에는 Critical Sections, Deadlock, Serialization 등이 있습니다. 즉, 리소스를 많이 소모할만큼 작업을 바쁘게 수행중이지는 않으나, 어떠한 원인으로 인해 클라이언트에서 응답을 줄 수 없거나 늦게 주는 상황을 말합니다.
1. Critical Sections
만약 3,4,5,6 번 쓰레드가 critical section을 갖고 있는 7번 쓰레드의 수행이 끝나기를 기다리고 있고, 7,8,9,10 번 쓰레드가 critical section을 갖고 있는 12번 쓰레드의 수행이 끝나기를 기다리고 있으며, 12,13,14 번 쓰레드가 critical section을 갖고 있는 4번 쓰레드의 수행이 끝나기를 기다리고 있다고 합시다. 이때 마침 critical section 을 갖고 있는 4번 쓰레드가 죽었다고 한다면, 이를 기다리고 있던 다른 쓰레드들은 계속 기다리고 있는 상태로 머무르게 됩니다.
2. Deadlock
서로 다른 쓰레드가 서로 상대 쓰레드의 수행결과를 기다리고 있는 상태를 말합니다.
3. Serialization
어떤 프로세스를 수행하는 쓰레드들이 무수히 많이 존재하고, 각각의 쓰레드들이 한 파일에 수행결과를 기록해야 작업이 끝나도록 만든 로직이 있습니다. 이럴때는 한쓰레드가 파일을 write 하는 동안 그밖의 다른 쓰레드들은 기다려야 되는 현상이 발생하게 됩니다. 즉, Serialization은 병렬처리를 해야됩에도 불구하고 직렬로 수행됨으로써 성능상의 문제를 유발시키는 것을 말합니다.
