w3wp.exe가 메모리를 비웃음

8

Small Business Server 2011 설치에서 많은 수의 w3wp.exe 프로세스가 많은 양의 메모리를 사용하는 것으로 보입니다. SBS 기본 제공 설치에는 총 7 개의 사이트와 20 개의 ASP.NET 응용 프로그램 풀 (SharePoint, Exchange, WSUS 및 Remote Web Workplace와 같은 SBS 관련 항목)이 제공됩니다.

결과적으로 수십 개의 w3wp.exe 프로세스는 시간이 지남에 따라 4GB 이상의 서버 메모리를 사용하는 경향이 있습니다. 최대 응용 프로그램 풀은 작업 세트에서 약 800MB의 WSUS에 속하는 풀입니다. IIS MMC를 통해 응용 프로그램 풀을 수동으로 재활용하면 일시적으로 메모리 사용을 줄일 수 있습니다 (w3wp.exe 프로세스는 10MB로 축소되고 일부는 빠르게 커짐). 그러나 관리자가 하루 종일하고 싶은 것은 아닙니다. SBS가 사전 설치된 응용 프로그램 풀의 자동 재활용에 대한 권장 사항을 찾지 못했기 때문에 프로덕션 시스템에서 "그냥 해"하는 것을 꺼려했습니다.

이것을 제한하는 방법에 대한 나의 그물에 대한 연구는 w3wp 메모리 소비가 아프지 않지만 메모리가 "다른 응용 프로그램에서 필요할 때 해제 될 것"이므로 성능에 이익이된다는 많은 게시물을 던져 넣었습니다. 문제는 그것이 작동하지 않는다는 것입니다.

하나의 경우, SBS는 다중 역할 서버이며, 역할 중 하나 (주요 서버)는 CIFS 네트워크 스토리지 역할을하는 "파일 시스템 캐싱의 이점"으로, "다른 프로세스에서 다른 프로세스에서 사용하지 않는"여유 메모리에 다시 의존합니다. way "-사용자를 거의 보지 않고 메모리를 사용하지 않는 ASP.NET 응용 프로그램 풀은 비생산적입니다.
또 다른 것은 메모리 부족시 w3wp 인스턴스 메모리 소비가 여전히 크게 감소해야한다는 것입니다.

IIS 나 ASP.NET 응용 프로그램을 관리하는 경우는 거의 없으므로 응용 프로그램 풀의 메모리 요구 사항을 효과적으로 정리하는 방법에 대한 아이디어는 언제든지 환영합니다.

— 토끼
소스

이 ASP.NET 앱의 기능은 무엇입니까? 앱이 Linq-To-SQL 또는 Entity Framework와의 연결을 닫지 못하는 경우 w3wp.exe가 많은 메모리를 사용하는 것을 보았습니다.

— Nate

몇 가지가 있습니다. 많은 OWA / OMA 및 동기화 서비스, 하나의 매우 큰 하나가 WSUS이며, 일부는 셰어 포인트 사용 또는 SBS 별 (companyweb을, 원격 웹 작업) 사이트를 사용자 정의하는 등의 교환에 관련된

— 더 - wabbit

7

SBS의 놀라운 세계에 오신 것을 환영합니다. RAM의 권장 요구 사항은 10GB이며 최소 8GB가 필요합니다. ( Microsoft에 따르면 ) 타당한 이유가 있습니다. 잘 정돈 된 기름칠 된 기계가 아닙니다. 매우 조잡하고 부풀어 오며 태양 아래 모든 것이 묶여 있습니다. 그 상자에 RAM을 더 많이 넣을수록 더 좋습니다. 불행히도 최대 32GB로 제한됩니다. 어느 imho ... 바보입니다.

— 컴 위즈
소스

내 대답을 약간 수정해야한다고 생각합니다. 사용하는 RAM의 양이 걱정된다면 다음 중 하나를 수행하여 많은 시간과 두통을 덜 수 있습니다. A) SBS를 사용하지 마십시오 ... 표준 서버를 사용하고 필요한 역할을 설정하십시오. 개별적으로. 또는 B) RAM이 매우 저렴하기 때문에 더 많은 RAM을 시스템에 넣습니다. SBS는 위해 설계 매우 (... 10 ~ 20 워크 스테이션) ... 소규모 사무실과 잘 확장되지 않습니다.

— TheCompWiz

답변 주셔서 감사합니다. 동작을 관찰 한 시스템에는 물리적 한계 인 16GB의 RAM이있었습니다. 사용 가능한 메모리는 Exchange의 store.exe와 SQL Server 및 w3wp.exe의 수많은 인스턴스로 빠르게 채워졌으며 "미세 조정되지 않은"것이 아니라 철저한 뇌인입니다. Exchange 및 SQL Server 시스템을 자주 관리 할 때 다른 두 시스템의 과도한 메모리 소비 문제를 처리하는 방법을 알고 있지만 w3wp를 사용하면 다소 손실이 발생합니다. 네트워크 자체에는 11 명의 사용자 만 있습니다.

— the-wabbit

Exchange, SQL Server 및 IIS에는 모두 "캐시 된"데이터에 대해 100 % RAM을 사용하고 시도하는 메커니즘이 있습니다. 다른 것이 더 많은 RAM을 요구하는 경우 ... 3 개 모두 다른 서비스가 스와핑에 의존하지 않고 실행되도록 스케일 백 해야 합니다. (이론상) 실제로, 나는 당신이 어떤 것들에 펀치로 굴려야한다는 것을 알았습니다 ... 당신은 수동으로 모든 것을 시도하고 조정하고 하드 한계를 설정할 수 있습니다 ... 그러나 당신은 꼬리를 계속 쫓을 것입니다 하나. 몇 년 전에 내가 당신을 위해 IIS에서 응용 프로그램 풀 제한에 대해 읽은 기사를 찾을 수 있는지 알 수 있습니다 ...

— TheCompWiz

technet.microsoft.com/ko-kr/library/cc732519(WS.10).aspx

— TheCompWiz

technet.microsoft.com/en-us/library/cc725749(WS.10).aspx

— TheCompWiz

7

이것이 내가 한 일입니다.

이 답변 에서 제안한대로 web.configat에서 privateBytesLimit 매개 변수를 설정하여 .NET AppPools의 서버 응용 프로그램 캐시를 낮은 값 (5MB)으로 설정합니다 .%WINDIR%\Microsoft.NET\Framework\<version>\Config

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

이는 기본 풀 재활용 설정으로 메모리 사용량을 1GB 이상으로 줄였습니다.

"서버"유형의 가비지 수집기 ( <gcServer = "true">) 를 사용하면 상당한 메모리 소비가 발생할 수 있지만 <gcServer>기본적으로 false로 설정되어 있습니다.

— 토끼
소스

참고-잠시 후 우리는 다음 기사를 읽은 후 gcserver를 false로 설정하기 시작했습니다. forums.asp.net/t/1654596.aspx/1 및 msdn.microsoft.com/en-us/library/ff647787.aspx

— Greg Askew

@ the-wabbit 서버 가비지 수집이 동시에 발생하므로 gcServer = false 설정에 대한 조언이 여전히 최신입니까?

— Michael Steele

6

소프트웨어 결함으로 인해 결과 메모리 소비가 문제라고 생각되면 Microsoft DebugDiag 1.2를 사용하여 전체 메모리 덤프를 작성하고 일반적인 문제에 대한 덤프를 분석 할 수 있습니다. 메모리 문제가 있다고 생각되면 "누설 모니터링"옵션을 선택하여 누출 추적을 활성화하고 덤프를 생성 / 분석하기 전에 잠시 동안 실행되도록해야합니다.

DebugDiag 1.2 다운로드
https://www.microsoft.com/download/en/details.aspx?id=26798

여기에 이미지 설명을 입력하십시오

— 그렉 비 스케
소스

링크 주셔서 감사합니다, 나는 그것을 시도 할 것입니다. MSI 설치 패키지는 현지화 된 (미국 이외의 Englisch) 버전의 Windows에서 실행할 때 문제가있는 것 같습니다. 이에 대한 해결 방법이 있는지 확인해야합니다.

— the-wabbit

2

모든 앱에 대해 별도의 앱 풀이 필요하지 않으며 신뢰할 수 없거나 우선 순위를 지정하려는 앱 풀만 필요합니다. 많은 사람들이 공유 할 수 있습니다 (서로 다른 .net 버전을 별도로 유지). 그런 다음 앱 풀에서 사용할 메모리를보다 현실적으로 제한 할 수 있습니다. 하루에 한 번 이상 풀을 반복해서 재활용 할 필요가 없습니다.

또한 이런 방식으로 해제 할 수있는 메모리가 너무 많습니다. 일부는 캐시이지만 각 앱에는 특정 웹 앱에 크게 의존하는 일정한 양의 작업 메모리가 필요합니다. 이것을 너무 많이 제한하려고 시도하면 분쇄가 중단됩니다.

문제는 실제로 SBS가 한 번에 너무 많은 일을 시도한다는 것입니다. 실제로 사용하는 것을보고 사용하지 않는 것을 차단해야합니다.

그러나 11 명의 사용자에게 정직하기 위해 나머지 메모리는 어디로 갈까요? 가벼운 사용을위한 Exchange 및 SQL은 확실히 12Gb 이상이 필요 하지 않습니다 !

— 제임스 라이언
소스

아, SBS의 아름다움을 경험 한 적이 없습니까? Exchange의 정보 저장소는 제한되지 않으면 8GB로 증가하고 여러 SQL Server 인스턴스는 다른 3GB를 행복하게 차지합니다. 대부분의 앱 풀은 동일한 .NET 버전과 동일한 보안 컨텍스트 내에서 1-2 개의 응용 프로그램 만 실행합니다. 그러나 지원 문제로 인해 다시 그룹화 할 수 없습니다. 또한 메모리 문제를 해결할 가능성이 거의 없습니다. 12 개의 작은 프로세스 대신 4 개의 1GB 프로세스 만 있으면 많은 돈을 얻지 못합니다.

— the-wabbit

앱 풀 수가 적을 때의 차이점은 다양한 캐시가 정기적으로 사용되는 항목으로 가득 차서 그렇지 않은 것을 밀어냅니다. 많은 응용 프로그램 풀을 사용하면 더 많은 낭비가 발생합니다. 11 명의 사용자에게 실제로 몇 개의 보안 컨텍스트가 필요합니까? 그렇습니다. Exchange는 실제로 사용할 수있는만큼의 메모리를 충분히 사용하지만 제한이있는 경우 소수의 사용자 만 2GB로 실행합니다. SBS를 사용하면 어디에서나 모범 사례를 사용하거나 옵션을 최적으로 실행할 수 없다는 사실을 인정해야합니다. 엔지니어가 아닌 실용적이어야합니다.

— JamesRyan

서버에서 20 개의 인스턴스를 실행하려는 경우 메모리에 모두 넣는 것은 놀라운 일이 아닙니다. 질문에서 완전히 다른 빛을 비추기 때문에 실제로 언급해야합니다.

— JamesRyan

나는 실제로 언급하지 않았지만 거의 사용되지 않는 앱 풀이 훨씬 더 가치있는 파일 시스템 캐시에서 메모리를 훔치는 물리적 시스템에서 문제가 발생합니다. 나는 이것이 응용 프로그램 풀 내의 일부 객체 캐싱 때문일 것으로 생각하고 캐시를 줄이거 나 비활성화 할 수단을 찾고있었습니다.

— the-wabbit