» 윈도우 서버+가상화 » IIS 8.0 Administration and Troubleshooting 교육 1일차

IIS 8.0 Administration and Troubleshooting 교육 1일차

강사: 한국 MS CSS팀 최문혁님

[가장 조심할 점]

배포 시 web.config까지 배포하면 Debug가 True가 됨.

  • 예외가 생겼을 때 False이면 Connection Timeout이 됨
  • True이면 프로세스가 끝나지 않음
  • Debug가 True -> 성능 상으로 30% 지연 생김
    • 각각에 대한 코드가 메모리에 올라갔을 때 step과 heap 사이에 디버그 정보를 넣어서 성능상 이슈가 생김
    • 접속을 하면 IE에서 하얀 화면에서 뱅글뱅글 기다리는 현상이 생기게 됨

Default Web Site에 대한 Pool을 여러 개로 나눔

  • 만약 사이트에 문제가 생겨서 조치를 취할 때 UI 상에서 ?
  • IISRESET이 실패할 경우도 있음
    • net stop w3svc 이후 iisreset 을 하면 잘 됨

IIS 관리자

우측의 :80 ?

  • 특정 포트에 대한 것.
  • 우측에서 중지나 시작을 하면 특정 포트에 대해서만 닫았다 열었다 하는 것임.

애플리케이션 풀을 재생/IIS를 다시 시작

  • -> 차이가 있음.
  • -> 재생을 눌러도 UI상 변화는 없지만 실제로 재생이 된다.

appcmd list wp

  • (wp = worker process = W3WP.EXE)

[프로세스 ID]

PID: 해당 프로세스에 대한 고유 번호. 실행될 때마다 달라짐

풀을 재생하면 해당 PID가 달라짐. 오 ㅎㅎ(기존 프로세스가 죽고, 새로운 프로세스로 올라옴)

[고급 설정]

CLR 버전: 3.5까지는 2.0, 4.0부터는 4.0

Enable 32-Bit Applications: 32비트로 동작시킬 때.

파이프라인: 통합

Start Mode: Always Running이 추가됨

  • W3SVC가 시작되면 자동으로 해당 AppPool이 시작됨
  • Always Running: 가장 중요한 풀 하나만 설정

Rapid-Fail Production

  • production 환경에서는 반드시 False로 해야 함
  • ~분동안 ~번 오류가 발생하면 Service Unavailable 됨

Idle Time-out

  • 20분동안 동작하지 않으면 프로세스가 죽었다가 사용할 때 새로 올라옴
  • Idle Time-out을 0으로 설정(사용 안 함)하는 것이 좋음

Recycling

  • Regular Time Interval : 이것도 사용하지 않아야 함

Specific Times

  • 유휴 시간과 Regular…을 설정했으면 반드시 설정해야 함. TimeSpan Collection Editor를 사용하여 가장 사용이 적은 시간대에 재생하도록 설정(출근 전 1, 2시간 전, 임원분들 사용하시기 전으로)

Windows Architecture

  • *.sys: Kernel Mode에서 동작하는 것: OS에서 동작하는 영역
  • *.exe: User Mode에서 동작하는 것: 사용자에게 보이는 영역
  • lsass.exe: 인증을 담당, AD에서 인증을 받을 때 활용
  • w3wp.exe: 이 또한 User Mode로 동작하게 됨

notepad.exe에서 Hello라고 입력하는 순간 Kernel32.dll에서 키보드에 관련된 필터 드라이버가 하드웨어의 입력을 감지하고 Win32 Subsystem으로 넘겨주게 됨. user mode는 kernel mode에 접근할 수 없는데, win32 api를 호출함으로써 kernel mode에 접근 가능

예를 들어 네트워크를 활용한다면 user mode에서 kernel mode로 지나가게 됨

  • Memory manager: 메모리 관리(10GB짜리 텍스트 문서 10개 열 때 …)

Groupware

AppPool

Process

x86(일반적인 환경)

x64(똑같은 것인데도!)

news

w3wp.exe

300MB

1.2GB(8TB까지 있으니 적은 )

mobile

w3wp.exe

250MB

1GB

위 결과가 문제가 있나? 없다.

Garbage Collection 알고리즘이 64비트에서 32비트는 프로세스당 2GB까지 사용 가능

User mode 2GB를 넘어서면 메모리가 부족해서 Paging이 생김: Disk IO가 느려짐. 그래서 64Bit로 많이 사용함

메모리의 연속적인 공간이 확보되어야 1.2GB를 로드할 수 있음 -> Out of Memory

clip_image001

물리 메모리의 상태

프로그램이 돈다: 디스크의 프로그램의 내용을 메모리에 올려서 순차적으로 프로그램이 동작한다는 것

heap이 corruption되면 dump를 정상적으로 뜰 수 없다: 특정 스위치를 줘야 한다.

Thread의 집합을 Process, Program이 실행되는 순간 Process가 동작함

dump: WinDbg 6.11 ? 로 보는 듯

  • 내용: notepad.exe에 참조되는 dll 리스트가 나오고,
  • 하단을 보면 threads가 나와서 그것들이 합쳐져 process가 됨

Process 우선순위

  • 0~30까지
  • 0

    1-15

    16-31

    System Level

    Variable Levels

    Real-Time Levels(키보드 입력과 같은)

  • 높을 수록 우선 실행됨

ISAPI Filter에 SSO 모듈이 막히는 경우가 많음

  • SSO가 Multi-Threading을 보장하지 않는 방법으로 개발된 경우 문제 발생

예외 처리

  • 1st Chance Exception
    • 핸들링을 한 예외(Try~Catch로 잡은)
  • 2nd Chance Exception
    • Try~Catch로 잡지 못하고, SHE(Structured Exception Handling)에 걸리지 않은 것
    • SEH는 윈도우가 알고 있는 오류
    • 이게 발생해야지만 시스템이 죽음
[실습] IIS 설치 시

Request Monitor 설치하자.

  • appcmd list wp 등의 커맨드를 사용하려면 필요

Tracing

  • 실패한 요청을 추적하기 위해. 반드시 설치할 것.
  • Dump까지 가지 않고도 실시간으로 확인 가능

Performance Features

  • 정적 압축
    • 이미지, HTML, XML 등을 압축(20% 정도로 줄어듬, 네트워크 대역폭 확보 가능)
  • 동적 압축
    • .aspx와 같은 파일(동적 페이지)을 요청할 때마다 매번 압축함
    • 캐싱이 되지 않는 아이들이기 때문에, 동적 컨텐츠 압축을 시도
      • 압축에 CPU를 사용함
      • CPU가 85% 이상을 사용하게 되면 자동으로 동적 압축이 비활성화됨
      • ex) Gmarket과 같은 특수한 사이트에서는 CPU 30%만 넘어도 장애로 판단, 두 압축 옵션 모두 사용하지 않음

Authentication

  • Windows Authentication 정도만 사용함(이것만 선택하면 문제 없음)
  • 테스트를 위해 Basic Authentication을 선택하기도 함.

Application Development Features

  • 필요한 것을 선택
  • ASAPI 쪽을 선택하지 않으면 SSO 모듈 등을 설치하기 힘든 경우가 있음

기능을 선택적으로 고르게 한 이유?

버전 비교

IIS 버전

OS 버전

비고

6.0

2003

이전 UI

7.0

2008

문제가 있는 버전/ UI

7.5

2008 R2

보안적인 측면이 올라감

8.0

2012

문제가 있음

8.5

2012 R2

안정화

7.x 대와 8.x 대의 큰 차이는 대용량 처리를 위해 내부적으로 많이 바뀌었지만, 기능 상으로는 큰 차이가 없다고 함

clip_image002

%windir%\System32\inetsrv\config\ApplicationHost.config에 IIS에 대한 설정값이 저장됨. 대부분은 이 파일에 저장되지만 특정한 값은 해당 Website의 web.config에 저장됨.

UI는 중요하지 않다.

clip_image003

ApplicationHost.config 파일을 그대로 복사하면 위와 같은 키가 맞지 않을 수 있으므로 제거하여 복사하거나 다른 조치를 취해주면 된다.

[성능 모니터]

clip_image004

트래픽을 볼 때: WebService의 Current Connections

clip_image005

마지막(last)에 1 이 있는 이유는 나 혼자 localhost에 접속했기 때문.

[HTTP.SYS]

HTTP.SYS 캐시를 보는 것보다 성능 모니터를 확인하는 것이 효율적

clip_image006

IIS의 가장 하위에 위치, 커널 모드에서 동작

[Archeitecture]

IIS6 vs II8

아키텍처가 가장 중요

처음 사용자가 웹 주소(~~~/index.aspx)를 입력해 서버에 요청이 들어오면 TCPIP.SYS가 소켓이나 RPC, HTTP 등 모든 통신을 받아들임. IIS에서 사용자가 많지 않은데 느리다고 하면 TCPIP.SYS(가장 하위에 있는 필터 드라이버)를 봐야 함.

TCPIP.SYS에서 패킷을 파악, HTTP.SYS로 넘어감. HTTP 1.1 표준 스펙에 맞춰 반응

HTTP.SYS에서 Queue로 등록, 클라이언트 브라우저에서 waiting …

해당 Queue는 Namespace Mapper라는 클래스에서 갖고 있는 테이블에서 news,mobile,main 중 선택, W3SVC가 큐를 가져간다. WAS는 Windows Process Activation Service(프로세스를 활성화시키는 서비스)로, HTTP 포트를 Listening하는 역할만 한다. 7.x 시절에 WAS를 만들어 W3WP.exe 프로세스를 동작시킴. applicationhost 파일을 읽어 돌아감.

.NET Framework, Machine.config, aspnet.config + web.config을 갖고 프로세스를 만들어주는 것이 WAS.

그리고 프로세스를 만들어줬으니 W3WP.exe는 aspnet_isapi.dll라는 .NET 4.x대 DLL에서 index.aspx를 처리하게 됨.

aspnet_isapi.dll는 해당 .NET 폴더의 Temporary 폴더에 복사하여 컴파일하고, 임의의 이름으로 바꿈. 그리고 지금까지와는 반대 경로로 결과를 보내게 됨.

_첫번째 요청

DNS -> TCPIP.SYS -> HTTP.SYS -> HTTP.SYS의 큐에 쌓임 -> Namespace Mapper -> 활성화된 큐가 있는지 확인 -> 없으면 Marking -> …

(W3WP.exe가 실행되기까지 시간이 좀 걸림)

_두번째 요청

HTTP.SYS -> Namespace Mapper에 Marking이 됨 -> W3WP.exe가 곧바로 가져감 -> 이번에도 index.aspx라고 한다면 아까 생성된 파일을 그대로 보냄. 처음보다 훨씬 빠름

다른 주소라면 …

[종속성] Dependency

clip_image007

W3SVC 는 Windows Process Activation Service에 종속성이 있다.

WAS는 프로세스를 Activation 하는 역할인데, WAS가 죽으면 서비스는 잘 되는데, 문제는 메인 화면의 문구를 바꾼 후에 정상동작하지 않음.

웹 사이트가 아니라 웹 애플리케이션 타입으로 배포하면 Pool이 Recycling 되는데, WAS가 있어야 새로 만들어주는데 W3WP가 정상 작동하지 못함. IISRESET도 안 됨. WAS가 죽으면 이벤트 로그에 나타남.

※ 서비스는 잘 돌아가고 있는데 소스 수정 후 문제 발생 -> 개발자는 억울

IIS 트러블슈팅 전에 Windows Process Activation Service 등이 제대로 동작하고 있는지 확인

clip_image008

위 폴더에 컴파일된 결과가 나타난다. 자주 본 느낌.

clip_image009

Microsoft.NET\Framework##\Temporary 폴더에 특정 AD 계정에 대한 권한이 필요. IIS AppPool을 실행할 때 특정 AD 계정으로 실행되는데, 그 계정을 변경하는 경우 위 폴더에 대한 권한 확인이 필요.

applicationhost.config과 web.config에 대한 권한도 확인 필요

Web log: 일반적인 IIS 로그

  • 서버IP, 클라이언트IP, URI, TIME_TAKEN

HTTPERR log: 성능 이슈 시 확인 가능

  • HTTP.SYS에서 발생된 로그
  • CONNECTION_IDLE과 같은 값이 찍혀 있어야 제일 좋음.(정상적)
  • CONNECTION_DROP 같은 것이 찍혀 있으면 확인 필요.

로그를 바로바로 디스크에 쓰면 Disk IO에 영향을 줌.

6.x때에는 해당 로그를 열어봐도 몇 시간 전까지는 볼 수 없었는데, 지금은 해당 폴더에 가서 새로고침만 해도 잘 보임.

clip_image010

도서 4장 12p의 Request Queue에 1000개까지 담을 수 있다. 큐를 1000 -> 5000개로 늘리면?? 기본적으론 권하지 않지만, 동시에 수많은 사람이 많이 들어와야 할 경우에 Request Queue를 늘려주는 경우가 있었다.(Olleh TV에서 특정 시간대에 동시에 모든 가입자에게 광고 png, html을 보여줄 때 사용)

큐는 선입선출(FIFO)

스타벅스 다이어리 이벤트 시 모바일로 접속하는 수많은 사용자를 위해 큐를 늘려주는 것은 의미가 없음, 서버 증설을 해줘야 함. 네트워크나 CPU 성능도 중요

IISRESET은 가장 마지막 순간에, 그 이전에는 AppPool은 큐가 다 빠질때까지 기다리기 때문에 조금 더 시간이 걸림.

“큐는 늘려주는 것이 아닙니다.”

18p 클래식 모드

맨 처음 ISAPI Filter가 처리.

동적 요청과 ASPX 요청이 서로 다름

가장 큰 문제: 인증 처리를 두 번 함(lsass.exe가 두 번 호출되어 부담, AD DC까지 두 번이나 다녀와야 함)

“통합 파이프라인”은 IIS 6대의 두 파이프라인을 하나로 합침

각각의 단계에 대해 IHttpModule을 구현함

20p 핵심 동작 순서

[WAS]

WAS가 지정된 시간 동안 응답이 없으면 W3WP.exe를 죽여 버림.

Ping enabled: True인데 이걸 False로 설정한 고객사도 있다. 이미 Ping이 되지 않은 경우에는 w3wp.exe가 스스로 죽어 있다.

[Tools]

DebugDiag

WinDblg

Standalone Debugging Tools for Windows (WinDbg)
출처: <https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx>

clip_image011

clip_image012

Debug Diagnostic Tool v2 Update 1
출처: <https://www.microsoft.com/en-us/download/details.aspx?id=42933>

clip_image013

clip_image014

clip_image015

Analysis와 Collector가 있음.

clip_image016

Crash나 hang 상황에서 파악하는 데 사용.

clip_image017

First Chance Catch는 Try~Catch 로 잡히는 부분에 대한 것인듯.(핸들링한 곳에 대한)

[문제 상황]

문제는 크게 두 가지

  • Crash
    • W3WP.exe 프로세스가 죽었을 때(Terminated)
    • DebugDiag로 원인까지 찾을 수 있음
  • Hang
    • 개요: 프로세스는 살아 있는데 응답이 없거나 브라우저로 접속했을 때 계속 로드하고 있는 형태
    • 특징: 짐작만 할 수 있음, 완전히 찾을 수 있다는 보장은 없음
    • 종류
      • High CPU: loop <== dump를 뜨면 됨
      • Low CPU: CPU는 놀고 있는데 접속이 안 됨. 이런 경우는 대부분 스레드 동기화 하는 경우 발생.
        • 스레드 동기화: 식당 화장실 열쇠를 생각. 누가 빌려가면 반납할 때 까지 사용 불가, 다른 사람은 기다려야 함

※ 덤프를 뜬 뒤에는 무조건 Remove를 선택해 지워야 함.

[IIS Troubleshooting]

문제 발생 시 순서

  1. identify
    • 증상을 파악하기 힘듦.
    • 문제가 무엇인지 찾는 것이 가장 어렵다.
    • 모든 사용자가 느린가? 특정 사용자가 느린가?
    • 내/외부 네트워크에서 동일하게 발생하는 문제인가?
    • 모든 서버에 같은 증상이 발생하나?
      • 특정 서버만 느리면 개발자의 잘못일 경우가 … 누락되거나 설정이 잘못된.
    • 오류 코드가 무엇인가?
    • 언제 오류가 나기 시작했나? 네트워크 등등의 어떤 구성을 바꾼 뒤에 오류가 나왔나?
  2. data collection
    • hang에 대해 데이터 수집이 필요함. crash는 거의 debugdiag에서 나옴
    • debugdiag로 수집하는 것이 좋으나 윈도우에 있는 것으로 수집해도 좋지만 …
    • MS에 분석 의뢰하는 데 비용이 든다.
    • 수집할 데이터
      • IIS Logs
        • IIS Log & HTTPERR 모두 확인
      • Event Logs
        • 1st Chance Exception을 찾기 위함.
        • WAS가 AppPool을 계속 모니터링하고 있으며, 해당 AppPool의 변화를 이벤트로그에 기록해준다.
      • FREB(Failed Request Tracing Rules) Logs
  3. analysis
  4. resolution
  5. prevention

clip_image018

작업 관리자에서 덤프 파일 만드는 것은 정말 부득이한 경우에만.

[그룹웨어가 느려요]

일단 그룹웨어의 경우 HTTP 통신이니 Fiddler로 확인한 후 어느 구간에서 느린지 확인, 오류나는 곳을 확인

IIS Log 확인해서 Time-Taken 값 확인

/main.aspx?moonchoi=1 이렇게 검색하면 로그에서 해당 세팅을 바로 확인 가능.

해결을 하였지만 원인을 찾지 못한 경우가 발생할 수 있다.

[툴: 로그파서]

https://www.google.co.kr/?gws_rd=ssl#newwindow=1&q=logparser+example

로그파서 샘플 찾아보면 좀 나옴.

이것도 살펴보세요!

Active Directory Backup & Restore: 액티브 디렉터리 백업 및 복원 방법

Active Directory 백업 및 복원 방법 참고: Best Practices for AD DS Backup and Recovery …

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.