Citrix Metaframe을 운영하다 보면 많은 장애 상황을 겪게 되는데 이중 가장 많은 이슈 사항이 Memory

사용량이슈라고 생각된다. 주관적인 느낌일 수 있겠지만 Non Paged Pool, Paged Pool, PTE값등

서버 운영을 하다보면 Memory Counter들 중 3개의 값에 대해 아주 민감하게 반응할 때가 있다. 글을 쓰

는 나도 해당값에 민감하게 반응하여 모두 모니터링을 실시하고 있으니... 이거원...

오늘은 이와 연관된 Session Pool영역에 대한 문제를 다루어 볼려고 한다.

Windows 2003 Terminal Server에 Metaframe을 서비스하다보면 Citrix의 wfshell.exe 프로세스가

SMSS.exe 프로세스에 Session 정보를 전달하지 않아 Session은 존재하지 않지만 소유자만 있는

좀비 Process가 되어 불필요한 Resource를 점유하게 되는 경우가 발생하는 경우가 있다.

물론 전체 서버에서 이러한 현상이 발생되는것은 아니지만, 이러한 경우 해결할 수 있는 방법에

대하여 논의해 보고자 한다.

[현상] Session Pool Memory 부족으로 인한 Windows Process HANG 현상

        - Process 사용률이 작업관리자에서 확인해보면 약 25%정도를 사용하고 있는 것으로 보임

[조치방법]

1. 수동 Dump 수집

  - 위와같은 현상이 발생할 경우 해당 현상이 발생하는 Process에 대한 PID를 확인한 후

    수동Dump를 수집한다.

  - PID얻는 방법은 다양한 방법이 있지만 tasklist란 명령어를 이용하면 쉽게 PID를 확인 할 수 있다.

  - Windbg를 이용하여 Kernel Live 디버깅을 시도 할 수 있지만 Vendor를 통해 분석요청을 해야하기

    때문에 수동 Dump를 수집하는 방법을 권고한다. 참고 : Kernel Live 디버깅 방법

2. Dump 수집 후 Lock Session 및 Session들을 확인한다.

  - Windbg에서 "!vm 4"를 이용해서 확인하거나 Windows !session을 통해 확인해 보면 Session Pool을

    할당하지 못한다는 메세지가 나온다. 그럴경우에는 System에서 Paged Pool영역이 부족해 더이상

    User에 대한 Session Pool을 할당하지 못한다는 메세지로 Server에 대한

    Session Pool 정보를 확인해 본다. (위와같은 상황까지 발생하게 되었다면 일단 리부팅을 통한

    메모리 초기화 작업을 진행해야 한다.) 참조 : http://support.microsoft.com/kb/840342

    위 KB문서를 보면 Session Pool영역을 확인하는 Registry값과 추가 할당이 16M로 할당할 수 있는것

    을 확인 할 수 있다. Default Session Pool Size는 4M이다.

    [!vm 4를 통한 Memory 값 확인]

image

image image

      위 Dump는 실제로 운영하던 서버에서 위와 같은 현상이 발생하였을 때 수동 Dump를 수집해서

본 Windbg내용이다.

    이후 Session ID를 확인해서 !process 0 0 wfshell.exe를 확인해본다.

image

      위의 그림에서 보면 SessionId부분이 나온는데 HANG 상태였던 wfshell.exe의 프로세스 상태를

      확인하여 Stack상태를 확인하면 된다. 이후의 분석 방법은 생략~~~^^


[해결방법]

1. Session Pool 영역의 증가

  - 16M 단위로 할당할수 있는것을 생각하여 Windows Terminal Server에 대한 Session Memory

    할당량을 추정한다. Vendor(Citrix)에서 제공하는 권고치를 감안하여 설정하는것이 일반적이다. 만약

    Session Pool을 과도하게 설정할 경우 Terminal 접속되는 User의 수를 감소하는 부작용이 있어

    신중하게 생각해야 한다.

  - 즉, 예를들면 1280 x 1024 Dual Monitor사용하는 Client가 있는 환경일 경우 Citrix에서 권고하는

    Session Pool영역 권고치가 48M라고 하자. 접속하는 User가 모두 48M를 사용한다고 가정하면

    Windows 32Bit환경에서는 약 10명정도의 User만 Terminal Server를 이용할 수 있게 된다.

    평균접속 User수가 15명 정도가 되는 운영환경이라면 위와같은 설정은 서버 증설 및 무한한 갈굼을

    받으며 설정해야 할 것이다.^^

2. Citrix해상도 변경

  - Citrix Application Appearance 설정을 다소 낮추면 GDI객체 사용률을 낮추어 Session Pool영역을

    다소 감소시키는 효과가 있다. 위와 같은 환경일 경우 Session Pool영역을 증가시키는데는 다소 운영

    상의 무리가 있기 때문에 Citrix 설정을 변경하여 해결하는 방법이 있다.

  - Application Apperance 설정을 변경하는 방법은 다음과 같다. 알고보면 정말 간단!!ㅋ

    Data Collector서버에서 CPS Console을 기동 후에 Application 설정에서 보면 다음과 같은 화면을

    확인할 수 있다. 아래 그림중 Colors 부분에서 설정을 바꾸기만 하면 끝!!!

image

신고
Posted by hotpoto

메모리 영역 중 Non Paged Pool 영역에 Full 현상이 나면 서버는 어떠한 현상이 될까?? 그 대답은 간단하다. 바로 서버 HANG상태로 진입하게 되어 더이상 Resource를 이용할 수 없게 된다. Non Paged Pool 영역은 대한 내용은 아래의 Link에서 확인하면 감사...^^

Windows Memory Option, 메모리 튜닝 기초, 장애 관리 Point

서버가 HANG 상태가 될경우 취하는 Action Plan은 크게 2가지로 정리할 수 있다. 한가지 방법은 풀릴때까지 그냥 놔둘경우....(ㅋㅋ), 수동 Dump를 수집하여 근본원인 분석을 하는 아주 지극히 정상적인 Admin의 Plan.....(ㅋㅋ)

그냥 놔둘경우는 너무 무책임하다는 오명(?)을 들을 수 있기 때문에 여기서는 Dump 생성 후 추정원인을 생각해 볼수 있는 Tip을 설명하고자 한다.

먼저 Non Paged Pool영역을 감지하는 방법은 Windows Server에서 기본적으로 제공하는 Warning을 이용하는 방법이다.

image

위와 같이 Counter Log를 이용하여 임계치를 설정해놓고 위에 TAB의 작업을 이용하여 Event를 이벤트뷰어에 기록해서 Check하거나 프로그램 실행 Script를 통해 Admin에게 알려서 사전에 미리 감지할 수 있는 방법을 사전에 마련해 놓는다.

위와 같은 경고 메세지가 발생하였을 경우 필자는 모니터링 Tool에 다음과 같이 나오도록 설정하였다.  설정방법은 모니터링 Tool마다 약간 다름으로 그 설명보다는 Script를 이용해 아래와 같이 설정을 해놓는것도 하나의 방법이다. 좀더 강력한 방법은 문자발송을 통해 확인하는 방법이 더 강력하지 않을까?????^^

image

다시 돌아가서 서버에 접속이 가능하다면 WAS등의 Process를 재기동하여 Non Paged Pool영역을 낮출수도 있고 걍 서버를 리부팅 하는 방밥도 있다. 여기서 말하는 것은 서버 리부팅은 수동 Dump 생성을 위한 리부팅을 말한다.

리부팅 이후에 Dump 분석하는 방법에 대해 살짝 공유하면...

image

위에서 보면 Non Paged Pool MAX값과 Usage값이 거의 일치하는것을 볼수 있다... 그럼 Full 는 말...ㅋㅋ 이건 큰 의미가 없는것이 Non Paged Pool 영역을 감지하는 모니터링을 실시 했으니까... 또 그런이유로 Dump를 떨군 것이니 당연한 결과가 아닌가...ㅎㅎ

그럼 도대체 어떠한 넘들이 Non Paged Pool 영역을 사용했는지... Pool영역을 들여다 보자

 image

흠... Gsem이란 분이 거의다 사용을 하셔서 문제가 되었군요... Gsem은 Gdi Semaphores말하는 것이라고 친절하게 설명이 되어 있다...ㅡㅡ; 이 다음의 자세한 내용은 MS 엔지니어에게 질문...ㅋㅋ

이후 Locking Session을 확인하여 어떠한 Process가 Non Paged를 유발했는지 확인해볼 필요가 있다.

image

일단 확인할 수 있는 부분은 여기까지로 제한한다. 아직은 Skill이 부족하여 이 이후의 단계는 좀더 내공이 필요할 듯 싶다.

여튼... 이러한 방법으로 사전 감지나 1차 처리를 한다면... 도움이 되지 않을까...??ㅋㅋ

부끄럽기에... 급하게 마무리 하겠다..

신고
Posted by hotpoto

티스토리 툴바