System Compleat.

'시스템관리'에 해당되는 글 1건

  1. Nonpaged Pool

Nonpaged Pool

Techs
( 정윤진, bluebird_dba@naver.com )

---------
시작하기 전에, 본 내용은 2010/03/18일에 포스팅한 내용을 보는것이 Nonpaged 및 Paged Pool 영역에 대한 추적에 용이함을 미리 말씀 드린다.

해당 내용은 여기 를 참조 하시면 되며, 아래의 내용은 경험담 정도로 보아주시면 좋겠다.
---------


일전에 윈도우 서버에서 nonpaged pool 영역에 문제가 생기면서 추적을 하다 하다가 포기한 적이 있다.  그 당시의 장애는 프로그램의 코드 문제로 나중에 밝혀 졌지만  이러한 유형의 장애 추적이 윈도우에서는 매우 어렵다 라고 느꼈던 개인적으로는 큰 사건중의 하나였다.

나의 경우에는 장애 상황에 장애 해결을 위한 실마리를 찾지 못하면 빠르게 원복하는게 항상 답이라고 생각한다.  이 원복의 의미에는, 최근에 변경한 ( 업데이트한 ) 서비스의 구성요소 일 수도 있고 일부 정말 모르겠는 경우 메모리의 문제가 발생하면 재부팅을 하거나 하는 것.

다만, 장애 상황에서 단 하나의 연관 가능성 있는 실마리라도 발견하면 추적하게 되는데, 적당한 시간만 있다면 이러한 잠깐의 추적이 완전한 문제 해결로의 지름길이 되곤한다.
따라서 장애 발생 시간에 ( 서비스에 문제가 되고 있는 시간에 ) 빨리 원복을 할지 이 장애의 원인을 추적할 지는 숱한 번민의 대상이 되고,  당황하거나 이런 부분을 조금이라도 소흘히 하게 되면 서비스 재개는 늦어지고, 장애 원인은 찾지 못해 매번 동일한 장애를 맞이하게 되는 슬픈 현실에 빠지게 될 수도 있다.

서론이 길었지만,  뭐 어쨌든 이번 이야기는 IIS를 동작시키는 윈도우 서버에서의 Non paged pool 의 부족  상황에 대해 어떠한 드라이버가 문제가 되는지를 추적하는 방법에 대해서다. 


윈도우 2003에서는 ( 다른 버전의 윈도 서버에서도 비슷한 방법을 제공하리라 생각한다 ) Windows Support Tools 에서  poolmon.exe 라는 툴을 제공한다.
일단 이 툴을 시스템에 미리 설치 해 두고, 정상 동작 상황에서도 한번 쯤 사용법을 익히는 것도 좋은 공부가 될 것으로 생각한다. ( 윈도 커널에 대한 )
조금 더 개발쪽으로 치우친 시스템 엔지니어라면, windbg.exe 같은 툴을 병행해서 사용하면 더 좋을 듯 싶다.


일단, IIS 구동중인 서버에서 Non-paged pool 영역의 메모리 부족사태가 발생하면 다음과 같은 IIS Error 로그가 발생하게 된다.

2009-xx-xx 02:06:22 - - - - - - - - - 1_Connections_Refused -
2009-xx-xx 02:06:32 - - - - - - - - - 1_Connections_Refused -
2009-xx-xx 02:07:37 - - - - - - - - - 1_Connections_Refused -
2009-xx-xx 02:11:02 - - - - - - - - - 2_Connections_Refused -

당연히 정상적인 서비스가 되고 있지 않은 상황이다.

윈도우 서버의 non-paged pool 은 다들 잘 아시다 시피 커널의 메모리 영역이며, 통상 윈도우에서는 최대 256M 의 메모리를 이 영역에 할당한다.  문제는, IIS 의 http.sys 가 이 영역에서 동작하기 때문에 시스템의 다른 드라이버 또는 커널 메모리 영역에서 동작하는 '그 무언가'가 메모리를 많이 잡수시면 정상적인 IIS 의 동작을 방해한다는데 있다.

유닉스 시스템을 기반으로 유추해 보건데, 이는 IIS 에서 응답 처리를 하기 위해 새로운 thread 의 할당 및 클라이언트 응답에 대한 정상적인 프로세스를 진행하는데 있어 할당 되어야할  커널 메모리 영역이 부족하기 때문에 '난 지금 처리 불가' 라는 메세지를 토해 내는 것 쯤으로 이해한다.

문제는, '그래서 어떤 드라이버인데?'  를 알아야 이 문제가 풀릴 테지만, 이게 쉽지 않다.

poolmon.exe 를 사용하면,  paged pool 과 non-paged pool 에 대한 정보를 알 수 있다.
이 정보에 나타나는 드라이버의 이름은 아래의 스크린샷에서 처럼 당최 뭔 드라이버인지 그 이름을 유추해 내기 힘든 ( 또는 명명규칙을 내가 모르니까 ) 구조로 되어있어, poolmon 자체에서 일종의 translate 를 제공하기도 한다.  ( poolmon.exe -C 하면 .txt 를 뱉어낸다.  )

사용자 삽입 이미지

poolmon.exe



그런데, 이 정보에도 나타나지 않거나 또는 이 정보로도 어떤 드라이버인지 알아낼 수 있는 여지가 많지 않다는게 참 큰일이다.  분명히 시스템에서는 이러한 이름으로 할당된 정보가 어디엔가에서는 참조되고 있을터인데, 각 영역의 Addressing 번지 수 라도 알면 어떻게 좀 해보겠는데  이 non-paged pool table(?) 비슷한 정보를 찾아 내는데 나는 결국 실패했다.

IIS 에서 구동하는 프로세스 자체가 문제인가? 라는 증거만 나와도 그 다음은 참 쉬웠을 텐데.

iisdiag.msi 를 사용하여 IIS 프로세스에 대한 덤프를 떠서 MS 에서 제공하는 Analyze 툴을 써도 신뢰할 만한 정보는 딱 부러지게 나오는게 없었던 기억이다.

결국, 윈도 시스템에 대한 이해 부족이 문제여서 'Windows 커널의 구조와 원리' 에 대한 책을 구입해서 파 보고 있는 중이다.


non-paged pool 영역이 꽉 차면, IIS 재시작은 답이 아니다.  서버 재부팅으로 아예 비워야 한다.  .NET 의 GC 동작도 의심해 보고 perfmon 으로 GC의 Level 별 카운트 증가에 대해 파 보기도 했지만, 결국 원하는 답은 나오지 않아  주기적으로 서버를 재부팅 해야 했던 아픈 기억이 있다.  이런 경우, 커널 덤프를 MS에 보내면 뭔가 답을 알려 주려나?


어쨌든, 좀 지난 일이긴 하지만 이러한 문제는 언제든 재발 될 수 있고, 또 어떤 서비스를 구성하건간에 사전에 신경쓰지는 않아도 발생했을때 한가지 더의 실마리를 알아내기 위해 평소에 이것 저것 많이 봐야 하는 직업임에는 분명한 듯.


결국은 또 신세타령 -ㅁ-;;


( 정윤진, bluebird_dba@naver.com )