정리하며 배우다.

아래 사이트에서 얘기하는 IISRESET을 사용하지 말아야 하는 이유에 대해서는, 
점검 시간이 보장이되고 있는 케이스라면, 크게 신경쓰지 않아도 될 듯 합니다.
또한, 사전에 유저의 진입을 차단할 수 있는 프로세스를 갖춘 웹사이트라면 신경쓰지 않아도 됩니다. 
개선된 IISRESET 명령을 이용하면, 충분히 개선이 될 것으로 생각이 됩니다. 

하지만, 어떠한 이유에서 IISRESET 대신, 다른 명령어를 사용하라는것인지 핵심은 한번쯤 읽어볼만해서 정리하였습니다.
또한, 하나의 IIS 웹서버를 이용해사 다중의 웹사이트를 이용하고 있는 사용자라면, 한번쯤은 참고하셔도 좋을 내용입니다.

IISRESET - IIS를 다시 시작하는 최악의 방법

해당 웹사이트 번역글입니다.

IISRESET

IISRESET은 IIS 서비스를 다시 시작하는 데 사용되는 잘 알려진 도구입니다.
불행히도 이는 가장 큰 문제이기도 합니다.

구성 변경 사항을 선택하거나 잘못된 동작을 하는 IIS 웹 사이트를 재설정하는 데 종종 사용됩니다.
이는 웹사이트의 가용성과 서버의 전반적인 안정성을 적극적으로 손상시킵니다.
이 게시물에서는 이러한 경우가 발생하는 이유와 IISRESET이 IIS 서비스에 어떤 영향을 미치는지 자세히 살펴보겠습니다.

IIS를 재설정하고, 응용 프로그램을 다시 시작하고, 응용 프로그램 풀을 재활용하는 올바른 방법에 대해 자세히 알아보려면 IIS 재설정, 다시 시작 및 재활용 가이드를 참조하세요.

IISRESET을 사용하여 IIS를 다시 시작하면 웹 서버에 어떤 영향을 미치는지 자세히 알아보기 전에 IISRESET이 사용되는 이유를 검토해 보겠습니다.

IISRESET 명령의 히스토리

IISRESET은 Windows Server 2003에 IIS 6.0이 출시되기 이전에 사용되던 명령어입니다.

IIS 5.0 및 이전버전의 IIS에서는 웹 서버가 모놀리식 단일 프로세스 였습니다. 응용프로그램에서 발생할 수 있는 성능 문제를 해결하기 위해 IIS 를 다시 시작 명령이 필요했습니다.

IIS 6.0 에서는 응용프로그램 풀 아키텍처를 도입했습니다.

요청 수신을 담당하는 IIS 시스템 프레임워크(Http.sys 커널 드라이버, W3SVC 리스너 서비스)에서 

웹사이트 응용 프로그램 코드 (호스팅에서 IIS 워커 프로세스, w3wp.exe)가 분리되었습니다. 

그래서, 응용프로그램 재시작할 경우 iisreset.exe 가 더이상 필요하지 않습니다. iis를 재시작하는 쉬운방법으로는 남아있지만, 과도한 방법입니다.

IISRESET 명령이 사용되는 이유는

1. Configuration 을 변경하기 위해

• IIS 7.0 이상 모든 IIS 서비스는 Configuration 변경 및 응용프로그램 콘텐츠 변경을 자동으로 감시하고 적용합니다. 
• 이러한 변경 사항은 자동으로 처리되고, 응용 프로그램 또는 응용프로그램 풀이 다시 시작됩니다.
• 즉, IISRESET 을 사용해서, configuration 변경 사항을 선택할 필요는 없습니다.
• IISReset의 사용은 IIS 6.0과 같은 IIS의 이전 버전에서 권장되었으며 IIS 7.0, IIS 7.5 또는 그 이후 버전에서는 지원되지 않습니다. https://techcommunity.microsoft.com/t5/iis-support-blog/iisreset-internals/ba-p/951578

2. 성능 및 안정성 문제를 복구하기 위해

• 웹사이트가 정지가 되었거나, 성능적으로 문제가 있는 웹사이트를 복구하기위해 사용됩니다.

다시 시작하는 것이 전술적으로 유익한 경우에도, IIS 를 재 설정하는 것은 올바른 방법이 아닙니다. 
대신 올바른 응용 프로그램 풀을 이용해서 재활용 하는 것이 좋습니다. 
응용프로그램풀을 재활용 하는 것은 아래와 같이 막대한 이점이 있습니다. 

- 해당 응용 프로그램 풀에만 영향을 미칩니다.
- 중첩된 IIS 재활용을 통해 제로 다운타임 재시작합니다.
- 전체 워밍업으로 다시 시작하는 기능에 지연이 없습니다.
- 다른 웹사이트에 영향이 없습니다.  (다중 웹사이트 운영시)
- 웹서버 전체에 잠재적인 결과가 없습니다.

IISRESET 작동방식

가장 정확한 비유는 서버에서 전원 코드를 뽑아 특정 어플리케이션을 닫는 것이다. 
최소한 서버를 다시 사용하려면, 서버가 다시 부팅 될 때 까지 기다려야 한다.
아래 이미지는 IISRESET을 사용할 때 대략적으로 일어나는 일입니다.

1. Windows 정품 인증 서비스 (WPAS)인 WAS 를 중지하려고 시도합니다.
2. W3SVC를 포함하여 WAS에 의존하는 모든 서비스가 중지됩니다.
3. WAS는 모든 활성 응용 프로그램 풀을 중지하려고 시도합니다.
4. 이는 WAS가 중지되는 동안, 서버의 각 웹사이트에 대한 모든 수신요청이 503 Sevice Unavailable 을 반환하기 시작함을 의미합니다.
5. 이제 모든 IIS 작업자 프로세스가 중지되기를 기다리고 있습니다. shutdownTimeLimit(기본 90초)
6. 작업자 프로세스가 이 시간내에 중지되지 않으면 종료됩니다.
7. 마지막으로 90초 정도 후에 WAS 가 중지됩니다.
8. 그런 다음 IISRESET은 WAS 및 W3SVC 를 다시 시작하려고 시도합니다.

즉, IISRESET이 WAS가 중지될 때 까지 대기 시간이 초과되지 않는 한 WAS를 강제로 종료합니다.

이 경우 명령이 실패하고, 중지된 IIS 서비스를 다시 시작하지 못하여, 웹서버가 영구적으로 비활성화 될 수 있습니다.

IISRESET 이 웹서버 가용성을 해치는 방법

1. IISRESET으로 인해 웹사이트가 중단됨

IISRESET으로 가장 먼저 발생하는 일은 W3SVC 서비스가 중지된다는 점입니다.

즉, 웹사이트 바인딩을 듣는 사람이 없고, 연결이 거부 됩니다. 이는 해당 서버의 모든 웹사이트에서 즉시 발생합니다.

2. IISRESET은 전체 서버에 긴 다운타임을 일으킴

IISRESET이 특정 웹 사이트 또는 응용 프로그램 풀을 대상으로 하지 않기 때문에, 시스템의 모든 응용 프로그램 풀을 중지한다는 것입니다. 

즉, 모든 웹사이트의 중단 시간은 응용 프로그램 풀의 작업자 프로세스가 현재 실행 중인 요청을 완료하는 데 걸리는 가장 긴 시간입니다(종료 시간 제한까지).

왜냐하면, 성능 문제가 있을때, IIS 재시작을 가장 자주 재설정 하기 때문에, 이러한 요청이 완료하는데 매우 오랜 시간이 걸릴 가능성이 높습니다. 따라서 IISRESET을 호출할 때 마다 전체 90초 지연이 예상됩니다.

3. 서버를 중지 상태로 남을 수 있습니다.

IISRESET 에는 기본제한시간이 20초입니다. 기본 응용 프로그램 풀 종료 시간 제한과 같은 90초가 아닙니다.

이는 활성 시스템의 IISRESET 이 WAS가 중지되기 전에 매번 시간 초과됨을 의미합니다. 강제로 WAS 종료를 시도하게 됩니다.

이로 인해 IISRESET을 관리자 권한으로 실행하는 경우에도, IISRESET에 권한 오류가 발생 할 수 있습니다.

Attempting stop...
Stop attempt failed.
Access denied, you must be an administrator of the remote computer to use this command. 
Either have your account added to the administrator local group of the remote 
computer or to the domain administrator global group.

결과적으로 WAS 및 W3SVC 서비스가 이제 중지되고 서버가 영구적으로 다운됩니다.

IISRESET NOFORCE 명령을 사용하고 있다고 가정해 보겠습니다 .

/NOFORCE 명령은 시간 제한을 소진하고 서비스를 종료하지 않고 중지하여 동일한 중지 상태가 됩니다.

개선된 IISRESET 명령

IISRESET을 사용해야 하는 경우, IIS 7.0 이상에서 사용할 수 있는 실패 위험이 낮은 IIS cmd는 다음과 같습니다.

iisreset /stop /timeout:60
taskkill /F /FI "SERVICES eq was"
iisreset /start

이것이 더 잘 작동하는 이유는 기본 IIS 재시작 cmd에서 발생하는 "액세스 거부" 오류를 방지하기 때문입니다.

더 긴 시간 초과를 사용하여 작동한 다음 IISRESET 중지가 시간 초과되면 WAS를 완전히 종료하고 나중에 다시 시작해야 합니다.

이렇게 하면 웹 서버가 영구적으로 다운되는 것을 방지할 수 있습니다.

4. IISRESET을 사용하면, 성능문제를 해결 할 수 없습니다.

서버중단, 높은 CPU, 메모리 누수, 성능 저하는 IISRESET으로 해결 할 수 없습니다. 
서버에 대한 로직을 검증하는 방법으로 수정해야 합니다.

5. 중복 재활용 및 100% 예열의 이점을 거부합니다.

진지하게. 손상되었거나 어려움을 겪고 있는 응용 프로그램 풀을 다시 시작하려는 경우 재활용 방법은 대신 중단 시간이 없고 완전히 예열되며 시작 지연이 없는 다시 시작을 허용합니다.

결론

IIS가 서버를 재설정할 필요가 없으니, IISRESET 을 사용하지 마세요.

이로 인해서 웹사이트 가동 중단 시간이 길어지고, 웹 서버가 작동할 수 없는 상태가 될 수 있습니다.

대신 IIS 서비스를 적절하게 다시 시작하는 방법을 알아보고, Zero 시작 지연 작업을 위해 웹사이트를 구성하는 방법에 대해서 알아보세요.

참조

https://www.leansentry.com/guide/reset-restart-recycle-iis/dangers-of-iisreset#to-recover-from-performance-or-stability-issues

END

Windows Server 계열에서 IIS를 설치하는 여러가지 방법이 있는데요. 지난번 포스팅에서는 PKGMGR (패키지매니저)를 이용했다면, 이번 포스팅은 DISM 배포 이미지 서비스를 이용해서 IIS 워크로드를 설치 및 설정하는 방법을 정리하였습니다. 

이전글

https://holjjack.tistory.com/226

01. DISM 이란?

배포 이미지 서비스 및 관리(DISM.exe)는 Windows PE, Windows RE(Windows 복구 환경) 및 Windows 설치 프로그램에 사용되는 이미지를 포함하여 Windows 이미지를 제공 및 준비하는 데 사용할 수 있는 명령줄 도구입니다. 

DISM은 Windows 이미지(.wim) 또는 가상 하드 디스크(.vhd 또는 .vhdx)를 제공하는 데 사용할 수 있습니다.

DISM은 Windows에 기본 제공되며 명령줄 또는 Windows PowerShell을 통해 사용할 수 있습니다. 

02. PowerShell 에서 목록 확인하기

PS> dism /online /get-features

PowerShell 에서 해당 명령어를 이용해서 DISM으로 설치 가능한 목록을 확인 할 수 있습니다. 

03. CMD 창에서 확인하기

/>  dism /online /get-features | find "IIS"

명령 프롬프트 이용시에는 find 명령어를 사용할 수 있기 때문에, PowerShell 보다는 목록을 확인하는데 유용했습니다.

04. DISM 스크립트

DISM.EXE /enable-feature /online /featureName:IIS-WebServerRole /featureName:IIS-WebServer 
/featureName:IIS-CommonHttpFeatures /featureName:IIS-StaticContent /featureName:IIS-DefaultDocument 
/featureName:IIS-DirectoryBrowsing /featureName:IIS-HttpErrors /featureName:IIS-HttpRedirect 
/featureName:IIS-ApplicationDevelopment /featureName:IIS-ASPNET /featureName:IIS-NetFxExtensibility 
/featureName:IIS-ASPNET45 /featureName:IIS-NetFxExtensibility45 /featureName:IIS-ASP /featureName:IIS-CGI 
/featureName:IIS-ISAPIExtensions /featureName:IIS-ISAPIFilter /featureName:IIS-ServerSideIncludes 
/featureName:IIS-HealthAndDiagnostics /featureName:IIS-HttpLogging /featureName:IIS-LoggingLibraries 
/featureName:IIS-RequestMonitor /featureName:IIS-HttpTracing /featureName:IIS-CustomLogging 
/featureName:IIS-ODBCLogging /featureName:IIS-Security /featureName:IIS-BasicAuthentication 
/featureName:IIS-WindowsAuthentication /featureName:IIS-DigestAuthentication 
/featureName:IIS-ClientCertificateMappingAuthentication /featureName:IIS-IISCertificateMappingAuthentication 
/featureName:IIS-URLAuthorization /featureName:IIS-RequestFiltering /featureName:IIS-IPSecurity 
/featureName:IIS-Performance /featureName:IIS-HttpCompressionStatic /featureName:IIS-HttpCompressionDynamic 
/featureName:IIS-WebDAV /featureName:IIS-WebServerManagementTools /featureName:IIS-ManagementScriptingTools 
/featureName:IIS-ManagementService /featureName:IIS-IIS6ManagementCompatibility /featureName:IIS-Metabase 
/featureName:IIS-WMICompatibility /featureName:IIS-LegacyScripts /featureName:IIS-FTPServer /featureName:IIS-FTPSvc 
/featureName:IIS-FTPExtensibility /featureName:NetFx4Extended-ASPNET45 /featureName:IIS-ApplicationInit 
/featureName:IIS-WebSockets /featureName:IIS-CertProvider /featureName:IIS-ManagementConsole /featureName:IIS-LegacySnapIn

위 스크립트를 이용하면, DISM 매니저를 이용해서 IIS 워크로드를 손쉽게 구성할 수 있습니다. PKGMGR 보다는 조금더 길이가 늘어났지만, 다른점이라고는 /featureName을 하나씩 명시적으로 입력해줘야 하네요.

해당 스크립트를 원격으로 실행시, 재시작을 대기하는 상황이 발생하는데요. 

이럴경우에는 /NoRestart 옵션을 사용해주면 재시작하지 않고 설치가 가능합니다.

DISM.EXE /enable-feature /online /NoRestart /featureName:IIS-WebServerRole /featureName:IIS-WebServer
...
...

참조

END

동일한 웹서버에 같은 환경의 IIS 를 여러대 설정해야할 경우, 스크립트를 사용해서 설치하는 방법이 매우 유용합니다.

Cloud 환경에 웹서버를 구성할 경우 용이하게 이용하실 수 있습니다.

아래의 설치 방법은 Pkgmgr.exe 를 이용한 방법이며, IIS 8.5 이상에서는 DISM.exe 를이용한 설치방법을 권장하고 있으나,Pkgmgr.exe 로도 설치는 가능하니 참고하세요.

스크립트를 이용한 IIS 설치

스크립트를 사용하여 IIS 7.5를 설치할 수도 있습니다. 이 스크립트를 사용하면 사용 가능한 모든 기능 패키지를 설치하는 전체 IIS 설치를 얻게 됩니다. 필요하지 않은 기능 패키지가 있는 경우 필요한 패키지만 설치하도록 스크립트를 편집해야 합니다.

스크립트를 사용하여 IIS 설치를 자동화하는 것은 여러 웹 서버를 배포해야 하고 각 웹 서버가 동일한 구성 요소와 서비스로 설정되어 있는지 확인하려는 경우에 매우 유용합니다.

Windows Server 2008 및 Windows Vista 운영 체제에서 Pkgmgr.exe는 무인 스크립트에 사용되므로 명령 프롬프트 또는 스크립트에서 선택적 기능을 설치하거나 제거할 수 있습니다. (참고: Pkgmgr.exe는 Windows Server® 2003에서 사용된 Sysocmgr.exe를 대체합니다.)

스크립트

CMD /C START /w PKGMGR.EXE /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;
IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;
IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASP;IIS-CGI;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;
IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;
IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;
IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;
IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;
IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementScriptingTools;
IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;
WAS-WindowsActivationService;WAS-ProcessModel;IIS-ASPNET;IIS-NetFxExtensibility;
WAS-NetFxEnvironment;WAS-ConfigurationAPI;IIS-ManagementService;MicrosoftWindowsPowerShell;
IIS-ASPNET;IIS-ASPNET45;IIS-NetFxExtensibility45;NetFx4Extended-ASPNET45;IIS-ApplicationInit;
%windir%\system32\inetsrv\appcmd set config /section:httpLogging /dontLog:True

위 내용을 bat 파일로 만드셔서 이용하시면 편리합니다.

또한 추가적으로 설치가 필요한 부분은 IIS-xxx 형태의 옵션을 찾으셔서 포함하면 됩니다.

예를 들어 웹소켓 설치시,

IIS-WebSockets;

를 추가 하면 됩니다.

참고

https://docs.microsoft.com/en-us/iis/install/installing-iis-7/installing-iis-7-and-above-on-windows-server-2008-or-windows-server-2008-r2

이 포스트는 아래의 Blog를 번역한 글이며, 영어공부 겸, 지식을 전달하기 위한 목적으로 작성된 글입니다.

보시기 불편하시거나, 해당글의 무분별한 포스팅이 문제가 된다면, 삭제하겠습니다.

https://stackify.com/w3wp-high-cpu-usage/

w3wp.exe IIS 작업자 프로세스의 높은 CPU 점유율은 많은 이유가 있습니다.

6개의 공통된 원인을 이 포스트에서 선택했습니다. 

• ASP.NET 어플리케이션의 높은 에러율
• 높은 CPU의 원인이 되는 웹 트래픽 증가.
• 어플리케이션의 의존성 문제
• GC (Garbage collection)
• ASP.NET 파이프 라인에서 요청이 차된되거나, 중단된 경우
• 최적화가 필요한 비효율적인 .NET 코드

Microsoft.NET 은 가비지 수집을 활용해서 메모리 할당 및 해제를 관리합니다.

어플리케이션이 수행하는 작업에 따라, 어플리케이션의 메모리 할당 및 정리에 많은 GC 활동이 발생 할 수 있습니다. 

예를들어, 대형 개체 힙에 대형 문자열 변수를 많이 사용하면, 가비지 수집에 문제가 발생합니다. 

가비지 컬렉션이 어플리케이션에 문제를 일이킬 수 있는지 측정하려면, Windows의 성능 모니터를 확인하세요.

.NET CLR Memory -> % Time in GC

이 카운터는 어플리케이션이 가비지 컬렉션을 수행하는데 소요되는 시간 (%) 을 반영합니다. 만약 이 수치가 5~10%를 넘게 급증하면 메모리 사용량을 더 자세히 조사해야 합니다. 

.NET Framework 2.0 버전을 사용중이라면, 서버모드를 활성화 해야 할 수도 있습니다. 

<configuration
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

ASP.NET request 의 lifecycle 에는 여러 단계가 있습니다. 여기에는 요청시작, 인증, 권한 부여, 올바른 HTTP 핸들러 평가 및 요청완료와 같은 기본적인 단계가 포함됩니다. 그 일환으로 사용 가능한 표준 및 사용자 정의 HTTP 모듈이 많이 있습니다.

성능문제가 있는 경우 모든 요청이 특정 HTTP모듈에 정지된 것처럼 보이는지 살펴보는 것이 좋습니다. 

HTTP 모듈은 네이티브 코드이거나 관리되는 .NET 코드일 수 있습니다. 

FormsAuthenticaion 또는 SessionStateModule과 같은 표준 .NET 모듈일 수 있습니다. 많은 애플리케이션은 타사 또는 사용자 정의 HTTP 모듈도 사용합니다.

세션을 사용하고 있습니까?
대부분의 사람들은 ASP.NET 세션으로 인해 얼마나 많은 성능 오버헤드가 발생하는지 알지 못합니다.
페이지를 로드할 때마다 IIS 작업자 프로세스가 세션 개체를 검색하고 잠근 다음 요청이 끝나면 해제합니다.
세션으로 인해 잠금이 발생하고 애플리케이션 내에서 병목 현상이 발생할 수 있습니다.
Redis 또는 SQL과 같은 세션 공급자를 사용하는 경우 성능 저하가 애플리케이션 성능에 영향을 미칩니다.

다른 일반적인 원인중 어느것도 문제가 되지 않는 경우, 코드를 자세히 살펴보고 개선해야 할 수 도 있습니다.

코드에서 호출되는 메서드와 소요시간을 캐처하려면 .NET 코드 프로파일러를 사용해야 합니다.

프로파일러는 코드에서 속도가 매우 느린 특정 메서드를 식별하는데 도움이 됩니다.

경고: 프로파일러는 어플리케이션의 오버헤드를 추가합니다. 따라서 어플리케이션의 CPU 사용량이 이미 매우 높으면 (90%+) 프로파일링이 매우 느려지고 어플리케이션 성능이 저하됩니다.

이로 인해 수행중인 프로파일링의 세부수준과 프로파일링을 시작하기 전의 CPU 사용량에 따라 어플리케이션을 사용 할 수 없게 될 수 있습니다. 

.NET 프로파일러는 RedGate의 ANTS 성능프로파일러가 있습니다. 

https://www.red-gate.com/products/ants-performance-profiler/

https://stackify.com/w3wp-high-cpu-usage/

END

이 포스트는 아래의 Blog를 번역한 글이며, 영어공부 겸, 지식을 전달하기 위한 목적으로 작성된 글입니다.

보시기 불편하시거나, 해당글의 무분별한 포스팅이 문제가 된다면, 삭제하겠습니다.

https://stackify.com/w3wp-high-cpu-usage/

w3wp.exe IIS 작업자 프로세스의 높은 CPU 점유율은 많은 이유가 있습니다.

6개의 공통된 원인을 이 포스트에서 선택했습니다. 

• ASP.NET 어플리케이션의 높은 에러율
• 높은 CPU의 원인이 되는 웹 트래픽 증가.
• 어플리케이션의 의존성 문제
• GC (Garbage collection)
• ASP.NET 파이프 라인에서 요청이 차된되거나, 중단된 경우
• 최적화가 필요한 비효율적인 .NET 코드

응용프로그램에서 응용프로그램의 에러가 발생할 수 있으며, 사용자는 알지 못합니다. 일부 오류는 당신의 유저가 특정형식의 오류 메시지를 받는 원인이 될것입니다. 다른 오류가 발생할 수 있고, 그것에 대해 아무도 알지 못합니다.

당신이 에러 모니터링 또는 응용프로그램 성능 관리 툴을 사용한다면, 높은 에러율을 체크할 수 있습니다

윈도우즈 Event Viewr, IIS 로그 등에서 응용프로그램 에러율과 실제 에러를 찾을 수 있는 몇가지 위치가 있습니다.

에러율을 위한 윈도우즈 성능 카운터

높은 에러율을 검토할 것을 권장하는, 두가지 특정 성능 카운터를 추천한다. 윈도우즈에서 성능 모니터를 열고, 챠트보기에서 카운터를 추가하여야 합니다.

• .NET CLR Exceptions -> # of Exceps Thrown / Sec : 이것은 당신의 응용프로그램의 많은 예외 상황을 보여줄 겁니다. 당신의 응용프로그램에 큰 성능 문제의 원인이 되는 숨겨진 많은 오류가 있을 수 있습니다. 예외는 않좋으나, 그것을 피할 수는 없습니다.
• W3SVC_W3WP -> %500 HTTP Response Sent : 상태 코드가 500인 모든 요청은 내부 서버코드 에러 입니다. 이 확율이 매우 낮은지 확인하세요. 0~1% 여야 합니다.

w3wp.exe 의 높은 CPU 사용량에 대한 가장 간단한 설명 중 하나는 웹 트래픽 증가 입니다. 그러나 정상적인 트래픽 양에 대한 기준이 없는 경우, 트래픽이 증가했는지 알기 어려울 수 있습니다.

트래픽을 추적하는 응용프로그램 모니터링 툴을 사용하는 경우, 이를 확인하고 트래픽 레벨이 변경되었는지 확인하십시오.

트레픽 레벨이 변경되었는지 알수있는 방법이 없는 경우, IIS 로그 파일을 사용해서 알아 볼 수 있습니다.

VisualLogParser 또는 Log Parser Lizard를 이용해서 질의할 수 있습니다.

또는 Requests / Sec 와 Requests Corrent 에 대한 윈도우 성능 카운터가 있어서 현재 트래픽 속도를 실시간으로 확인 할 수 있습니다. 

웹 트래픽 증가에 대한 가능한 이유

트레픽 레벨이 높은경우, 당신은 그 수준이 높아야 하는지 평가해야 합니다. 트래픽 레벨 증가와 관련하여 고려해야 할 몇가지 사항은 다음과 같습니다.

• 고객 또는 유저 : 특별한 고객, 유저, 또는 자원으로 부터 트래픽이 급증했습니까? 아마도 가끔 당신의 사이트에 접속하는 것이 작동하지 않을 수 있습니다. 특정 IP 주소를 차단이 필요할 수 있습니다.
• Bots : 비슷한 특별한 유저가 많은 트래픽의 원인이라면, 그것은 봇일 수 있습니다. IIS 로그에서 당신의 사이트 접속하는데 사용되는 사용자 에이전트를 확인하세요. 
• 오프라 효과 : 오프라(오프라윈프리)나 누군가가 당신의 제품을 언급했나요? 방금 입소문을 냈나요? 엄청나게 많은 관심을 받는 것은 좋은 일이지만, 이를 처리하기 위해 성능을 확장해야 할 수 있습니다.

당신의 사이트가 많은 트래픽을 받을 경우, 대용량 서버(스케일업) 또는 다수의 서버(스케일아웃)이 필요할 수 있습니다.

그러나 초당 많은 요청을 받지 않을 경우, 트래픽이 문제가 되지 않을 수 있습니다.

많은 ASP.NET 어플리케이션은 초당 10-30개 요청이 있습니다. 그러나 바쁜 앱에서 초당 100개 이상의 요청을 수행하는 가벼운 요청도 보았습니다.

하나의 웹앱에서 다른 웹 앱으로의 트래픽 양과 관련해서, CPU 사용량은 크게 다릅니다.

요즘의 웹 어플리케이션은 다양한 유형의 외부 서비스 및 종속성을 활용합니다. SQL, NoSQL, 대기열, 캐싱 및 다양한 외부 HTTP 웹 서비스가 포함됩니다.

어플리케이션 종속송으로 인한 속도 저하로 인해 어플리케이션 성능문제가 발생할 수 있습니다. 

가장 일반적인 문제는 느린 SQL 쿼리문 또는 외부 HTTP 웹 서비스 입니다. 

https://stackify.com/w3wp-high-cpu-usage/

END

이 포스트는 아래의 Blog를 번역한 글이며, 영어공부 겸, 지식을 전달하기 위한 목적으로 작성된 글입니다.

보시기 불편하시거나, 해당글의 무분별한 포스팅이 문제가 된다면, 삭제하겠습니다.

https://stackify.com/w3wp-high-cpu-usage/

IIS 성능 문제가 있거나, w3wp 높은 사용량 문제가 있거나, 높은 CPU 사용량을 IIS Worker Process 로 해결하는 방법을 알고 싶다면, 이 문서가 도움이 될겁니다.

이 포스트는, 당신의 ASP.NET Web Application의 높은 CPU 사용량의 원인이 무엇인지, 그를 식별하기 위한 몇가지 팁에 대해서 논의 합니다.

당신의 IIS Worker Process (w3wp) 많은 CPU를 사용하는 데는 여러가지 이유가 있습니다.

우리는 몇가지 주요 원인과, IIS 성능 문제를 해결하는 방법에 대해 설명합니다. 

가장먼저 해야 할 일중에 하나는, 당신은 현재 실행중인 웹 요청을 확인해야 한다. 이것은 문제를 일으키는, 특정 URL을 식별하는데 도움이 된다.

시간이 매우 오래 걸리거나, 높은 CPU 문제를 일으키는 URL중에 하나를 인식하는 기회가 된다. 

그러나 이것은 대기열에 있는 많은 웹 요청을 보여줄수 있으며, 근본적인 원인으로 연결되지는 않는다.

IIS 관리 콘솔을 통해서, 당신은 실행중인 Worker 프로세스를 볼 수 있습니다.
당신은 어떤 IIS Application pool 이 높은 CPU의 원인이 되는지와 현재 실행중인 Web 요청을 볼수 있습니다.

IIS 메인 메뉴로 부터 "작업자 프로세스"를 선택 하면 현재 실행중인 작업자 프로세스를 볼 수 있습니다. 

작업자 프로세스를 더블클릭하면, 현재 실행중인 모든 요청을 볼 수 있습니다.

다음은 우리의 서버중 하나의 예입니다. 각 요청이 ASP.NET의 파이프라인의 다른 부분에 있으며, 현재 실행중인 HTTP 모듈을 볼 수 있습니다.

appcmd.exe 유틸은 현재 실행중인 웹 요청을 포함하여, 많은 작업을 하는데 유용하게 사용할 수 있습니다.

C:\Windows\System32\inetsrv>appcmd list requests
REQUEST "f20000048000021c" (url:GET /nopcommerce, time:6312 msec, client:localhost, 
stage:BeginRequest, module:IIS Web Core)

IIS UI 및 Command Line을 통해 현재 실행중인 웹 요청을 볼 수 있습니다.

각기 다른 방법으로 같은 정보를 확인 할 수 있습니다. 

• URL :  실행되었던 완성형 URL.
• Time : 웹 요청이 실행되었던 밀리초 단위의 시간의 총 합.
• Client : 요청을 시작했던 유저의 주소
• Stage : 현재 요청의 IIS 파이프라인 단계
• Module : 현재 실행중인 ASP.NET 모듈

• 모든 요청이 동일한 URL 입니까? 아마도 해당 URL이 문제의 원인 일 수 있습니다. 
• 같은 Client 로 부터 많은 수의 요청이 옵니까? 아마도 특정 유저가 당신의 서버에 트래픽을 보내고 있을 수 있습니다.
• 모든 요청이 같은 단계나 모듈에 갇혀있습니까? 특정 IIS 파이프라인 단계에 요청이 중단되는 문제일 수 있습니다.

END