윈도우 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를 재시작 합니다.
http://support.microsoft.com/kb/916984/ko
이 댓글을
이 댓글을
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 현상에 가까운 이상 증상이 나타나는 컴퓨터가 있다고 함. 행도 걸리고 메모리도 소모하고 반환시간도 느리고. 이러니 메모리가 지속적으로 증가 할 수밖에..
이 댓글을
MetaBase.xml 파일 수정 방법 입니다.
1. 인터넷 정보서비스 (IIS) 관리자를 실행 합니다.
2. IIS에 컴퓨터 이름(로컬 컴퓨터)에서 속성을 누릅니다.
3. 인터넷 정보 서비스 탭에 메타베이스 직접 편집 허용에 체크하고 확인 합니다.
4. C:WindowsSystem32Inetsrv폴더에 Metabase.xml파일을 메모장으로 엽니다.
5. AspBufferingLimit 값을 수정합니다. (기본 4메가로 되어 있습니다. 이때 단위는 바이트 단위 입니다.) <= 다운로드 관련
6. AspMaxRequestEntityAllowed 값을 수정 합니다. (기본 200kb로 되어 있습니다. 이때 단위는 바이트 단위 입니다.) <= 업로드 관련
7. 저장한 뒤 3번에 체크한 부분을 체크해제 하고 확인 합니다.
8. 인터넷 정보서비스(IIS) 를 재시작 합니다.
이 댓글을
캐시 부족으로 발생되는 이 원인은 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서버를 재시작 하는것이다.
이 댓글을
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 등)를 재시작하면 된다.
이 댓글을
IIS 파일 캐시 설정 변경
IIS는 서버에서 사용 가능한 메모리의 50% 까지 사용한다. 그러나 웹전용 서버이면서 IIS에서 점유하는 메모리가 50%에 다다른경우 시스템운영에 적정여유량을 제외한 나머지 값까지 사용할수 있도록 이 값을 변경해 볼 필요가 있다.
레지스트리 경로:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesInetInfoParameters
데이터 형식: REG_DWORD
범위: 0-2,500MB 기본값은 60초마다 동적으로 조정.
캐시된 리소스에 대한 TTL값 조정
IIS는 마지막요청후 30초 이내에 재요청이 없을경우캐시를 파기한다. 서버에 메모리 여유가 있다면 캐시에 오래 남아 있을수 있도록 TTL값을 조정해 볼 필요가 있다.
레지스트리 경로:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesInetInfoParameters
데이터 형식: REG_DWORD
기본값: 30초
범위: 0 - 4,294,967,295 (제한 없음)
이 댓글을
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>
이 댓글을