윈도우 2003에서 TransferFile 호출시 w3wp.exe 메모리가 증가하는 문제 해결

T 1688-5863 / 010-8678-1397

윈도우 2003(IIS 6.0)에서 TransferFile을 호출해서 웹브라우저로 매우 큰 파일을 전송할 경우 파일 크기 만큼 w3wp.exe 프로세스의 메모리가 증가하는 문제가 있습니다. 문제 발생 이유는 ASP에서 전송한 데이터를 웹브라우저로 보내지 않고 IIS 작업 프로세스 내의 메모리에 캐시하기 때문입니다. 참고 문서는 You experience high memory usage in the W3wp.exe process on a Windows Server 2003-based computer that has Internet Information Services (IIS) 6.0 installed 입니다.

해결 방법
Windows 2003 SP2를 설치한 후 윈도우 업데이트를 통해 중요 업데이트를 설치합니다.

W3wp.exe내에 큐잉되는 최대 데이터 량을 제한합니다

레지스트리 편집기(regedit.exe)를 실행합니다.

다음 레지스트리 키로 이동합니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP\Parameters

키가 없을 경우 새로 생성합니다.

VectorSendThrottleLimit라는 DWORD 값을 생성합니다.

VectorSendThrottleLimit에 0x00100000(1048576)을 지정합니다.

변경 값을 적용시키기 위해 IIS를 재시작 합니다.

댓글'8'

홈지기 (작성자)

2012.04.09

http://support.microsoft.com/kb/916984/ko

홈지기 (작성자)

2012.05.02

장애 현상
 
부하가 증가하면 웹서버(windows2003r2, iis 6.*)의 속도가 매우 저조해진다.
부하가 있는 상태에서도 뒷단에 존재하는 웹로직 서버(windows2003r2)는 정상적인 속도가 나온다.
부하가 증가한 상태에서 access로그를 보면 웹로직에서 응답을 늦게 준것 처럼 속도가 매우 저조한 수치를 보인다.
 
해결
 
** IIS 튜닝
 
MaxEndPointConnections : LONG 
Range: 0 - unlimited   Default: 200      ======> 1000
이 값은 네트워크 Endpoint에 모일 수 있는 Listen Socket의 최대 값을 명시합니다. 한 포트에 연결될 수 있는 Connection 의 수를 말합니다.
설정 방법 : C:InetpubAdminScriptsadsutil.vbs SET w3svc/MaxEndPointConnections 1000
=======================
ServerListenBacklog : INTEGER
Range: 0 - unlimited Default: 200      ======>  1000
이 값은 queue될 수 있는 미활성된 Socket의 수를 명시합니다.
설정 방법 : C:InetpubAdminScriptsadsutil.vbs SET w3svc/ServerListenBacklog 1000
=======================

 
** 윈도우 튜닝
 
MaxPoolThreads : REG_DWORD
Range:  0 - 0xFFFFFFFF                Default: 10   ======>  20
  MaxPoolThreads는 Processor 마다 생성될 수 있는 pool threads의 수를 명시합니다.
 이 값은 inetinfo process의 i/o thread로 일반적으로 20이상의 값을 설정하는 것은 좋지 않습니다.
아래의 레지스트리에서 설정 :
[HKEY_LOCAL_MACHINE]SYSTEMCurrentControlSetServicesInetInfoParameters
=======================
MaxUserPort
서버에 연결되는 Port의 숫자가 5000개 이상 (Exchange 60000) 될 경우 서버에서 네트워크 장애가 발생될 수 있음.
일반적으로 WAS와 연결되는 Windows 서버나 Exchange 서버에서 주로 발생됨.

레지스트리 위치: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
유효한 범위: 5000~65534
값 이름 : MaxUserPort
값 종류: DWORD
기본값: 5000
추천 값: 65534
======================
TcpTimedWaitDelay를 설정

 TCP 파라미터는 물론 플랫폼 별로 많은 파라미터가 존재하지만, Windows에서의 TcpTimedWaitDelay 와 Solaris의 tcp_time_wait_interval 은 동일한
파라미터로서, 커넥션이 종료 되었을 때 TIME_WAIT 상태로 머물게 되는 시간을 설정한다.
이 값의 디폴트는 4분으로 짧은 시간에 많은 클라이언트가 접속을 하면 네트웍(Network) 퍼포먼스에 영향을 줄 수 있기 때문에 60초로 제한을 두도록
권고한다.
 
   레지스트리 위치 : HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
   유효한 범위 : 030~300초
   값 이름 : TcpTimedWaitDelay
   값 종류: DWORD
   기본값: 240초
   추천 값: 60
 
 
* 특히 플러그인 옵션 적용을 위해 IIS 웹서버 파라미터를 수정하고 반드시 IIS Admin 서비스도 재시작을 하여야 제대로 설정이 되니 유의한다.
* 테스트를 위해 Debug=ALL옵션을 적용한 상태에서 그냥 나오면, 반드시 고객에게서 전화를 받으니 이 옵션도 테스트 후에 반드시 제거하자.

홈지기 (작성자)

2012.05.02

문제 발생 후 조취사항

1. 웹서버
   1)  접근 : 이메일 대량 발송으로 인한 SMTP 프로토콜 부하로 인한 메모리 증가 라고 생각함.
        조취내용 : 관리자 이메일 발송 모듈 차단
        해결여부 : X
   2) 접근 : SMS 대량 발송 중 루프 발생으로 인한 캐시 메모리 증가 라고 생각함.
        조취내용 : 관리자 SMS 발송 모듈 차단
        해결여부 : X
   3) 접근 : 쪽지내용 확인을 유도하는 대량 SMS. 메일 발송으로 인한 해당 웹페이지 과부하 발생.
               그리고 해당 웹페이지는 실제로 페이징 처리가 한번에 전체 데이터를 가져와서 가져온데이터
               를 페이징하는 방식으로 되어있었음. 현재 글쓰는 시점의 쪽지 테이블에는 200만건 이상의
               데이터가 쌓여있었음. 해당페이지 캐싱되기 전 로딩속도 느림.

       조취내용 : 유저 쪽지 확인 페이지 페이징 방식 변경. 15씩만 DB쿼리하도록 변경
       해결여부 : 해당페이지는 빨라졌으나 메모리 누수 문제는 해결 안됨.
   4) 접근 : 웹서버 프로세스를 모니터링 중 w3wp.exe 프로세스가 지속적으로 증가 . iis 관련 프로세
             스이고 이를 분석하기 위해 DebugDiag 1,1v 툴을 사용해 해당 프로세스를 덤프하고 분석해봄.
             분석 후 주로 문제를 일으키는  FinalizerThread 중
                      mscorwks!SVR::GCHeap::FinalizerThreadWorker가 표시 되었고 이를 가지고 검색

       조취내용 : C:WINDOWSMicrosoft.NETFrameworkv1.1.4322aspnet.config 파일안에
                      다음 내용 추가
                                   <configuration>
                                        <runtime>
                                           <generatePublisherEvidence enabled="false"/>
                                        </runtime>
                                     </configuration>
       해결여부 : O

결론

인증 기관으로부터 받은 인증서로 signtool 을 이용하여 서명한 닷넷 어셈블리를 실행하는 경우, 초기 실행 시간이 hang 현상에 가까운 이상 증상이 나타나는 컴퓨터가 있다고 함. 행도 걸리고 메모리도 소모하고 반환시간도 느리고. 이러니 메모리가 지속적으로 증가 할 수밖에..

홈지기 (작성자)

2012.05.02

MetaBase.xml 파일 수정 방법 입니다.

1.       인터넷 정보서비스 (IIS) 관리자를 실행 합니다.

2.       IIS에 컴퓨터 이름(로컬 컴퓨터)에서 속성을 누릅니다.

3.       인터넷 정보 서비스 탭에 메타베이스 직접 편집 허용에 체크하고 확인 합니다.

4.       C:WindowsSystem32Inetsrv폴더에 Metabase.xml파일을 메모장으로 엽니다.

5.       AspBufferingLimit 값을 수정합니다. (기본 4메가로 되어 있습니다. 이때 단위는 바이트 단위 입니다.) <= 다운로드 관련

6.       AspMaxRequestEntityAllowed 값을 수정 합니다. (기본 200kb로 되어 있습니다. 이때 단위는 바이트 단위 입니다.) <= 업로드 관련

7.       저장한 뒤 3번에 체크한 부분을 체크해제 하고 확인 합니다.

8.   인터넷 정보서비스(IIS) 를 재시작 합니다.

홈지기 (작성자)

2012.05.02

iis 자체 파일을 다운 로드 할때, php 처럼 바로 페이지 자체 switch문을 사용 분류 하면 에러가 발생한다.
캐시 부족으로 발생되는 이 원인은 iis를 다루는 사람이며 누구나 경험 했을것이다.

그래서 iis는 원래 페이지를 두개 구성 한다.

1. LIst 페이지
2. Excel 페이지
이다.

파일 다운로드 오류로 인해서 필자도 2주를 버렸지만 결국 알아 냈다.

문제 해결.
1. 리스트가 900 개 이상 되는 Row 라면 iis 버퍼를 엄청 먹기때문에 . Response.Buffer = False 한다. 버퍼사용 금지.

위 1번만 시행해도 해결을 볼수 있다. 필자도 1번으로 해결봤다.

부가적 문제 해결.
1.iis 서버에서 windows -<; system32-<;intsev -<; metabase.xml 에서 aspbufferingLimit ="4MB" 통상 4메가로 잡혀 있다.
-<;aspbufferingLimit ="204800000" 으로 수정한다. (aspBufferingLimit 는 다운로드 최대량이다.)

2. MIME 설정 : IIS서버 프로퍼티에 httpHeader 에 보면 mime 설정을 볼수있는데 , 거기서 (.* ) 확장자네임, application/octet-stream 을 추가 하여 IIS서버를 재시작 하는것이다.

운영자 (작성자)

2012.05.02
수정: 2023.03.22 08:01:43

X-Powered-By Header Remove 방법

헤더 항목 : X-Powered-By: PHP/4.1.0 PHP/5.0.3

php가 설치된 서버의 웹페이지 호출시, 헤더를 모니터링해보면 X-Powered-By 항목을 발견할 수 있다.

필요없이 트래픽만 증가시키기 때문에, 제거하는게 효율적이다.

표시되지 않도록 설정하는 방법은 쉽다.

php.ini파일의 expose_php값을 off로 변경하고 웹서버(apache나 iis 등)를 재시작하면 된다.

홈지기 (작성자)

2012.05.02

IIS 파일 캐시 설정 변경

IIS는 서버에서 사용 가능한 메모리의 50% 까지 사용한다. 그러나 웹전용 서버이면서 IIS에서 점유하는 메모리가 50%에 다다른경우 시스템운영에 적정여유량을 제외한 나머지 값까지 사용할수 있도록 이 값을 변경해 볼 필요가 있다.

MemCacheSize
레지스트리 경로:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesInetInfoParameters
데이터 형식: REG_DWORD
범위: 0-2,500MB 기본값은 60초마다 동적으로 조정.

캐시된 리소스에 대한 TTL값 조정

IIS는 마지막요청후 30초 이내에 재요청이 없을경우캐시를 파기한다. 서버에 메모리 여유가 있다면 캐시에 오래 남아 있을수 있도록 TTL값을 조정해 볼 필요가 있다.

ObjectCacheTTL
레지스트리 경로:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesInetInfoParameters
데이터 형식: REG_DWORD
기본값: 30초
범위: 0 - 4,294,967,295 (제한 없음)

홈지기 (작성자)

2012.05.02

문제 발생 후 조취사항

1. 웹서버
   1)  접근 : 이메일 대량 발송으로 인한 SMTP 프로토콜 부하로 인한 메모리 증가 라고 생각함.
        조취내용 : 관리자 이메일 발송 모듈 차단
        해결여부 : X
   2) 접근 : SMS 대량 발송 중 루프 발생으로 인한 캐시 메모리 증가 라고 생각함.
        조취내용 : 관리자 SMS 발송 모듈 차단
        해결여부 : X
   3) 접근 : 쪽지내용 확인을 유도하는 대량 SMS. 메일 발송으로 인한 해당 웹페이지 과부하 발생.
               그리고 해당 웹페이지는 실제로 페이징 처리가 한번에 전체 데이터를 가져와서 가져온데이터
               를 페이징하는 방식으로 되어있었음. 현재 글쓰는 시점의 쪽지 테이블에는 200만건 이상의
               데이터가 쌓여있었음. 해당페이지 캐싱되기 전 로딩속도 느림.

       조취내용 : 유저 쪽지 확인 페이지 페이징 방식 변경. 15씩만 DB쿼리하도록 변경
       해결여부 : 해당페이지는 빨라졌으나 메모리 누수 문제는 해결 안됨.
   4) 접근 : 웹서버 프로세스를 모니터링 중 w3wp.exe 프로세스가 지속적으로 증가 . iis 관련 프로세
             스이고 이를 분석하기 위해 DebugDiag 1,1v 툴을 사용해 해당 프로세스를 덤프하고 분석해봄.
             분석 후 주로 문제를 일으키는  FinalizerThread 중
                      mscorwks!SVR::GCHeap::FinalizerThreadWorker가 표시 되었고 이를 가지고 검색

       조취내용 : C:WINDOWSMicrosoft.NETFrameworkv1.1.4322aspnet.config 파일안에
                      다음 내용 추가
                                   <configuration>
                                        <runtime>
                                           <generatePublisherEvidence enabled="false"/>
                                        </runtime>
                                     </configuration>