실행중인 프로세스 목록 외부에서 Windows Server의 메모리 사용량을 설명하는 방법

커밋 요금과 페이지 파일 사용량이 결국 재부팅 될 때까지 확인되는 Windows 2003 Server가 약간 느리게 실행됩니다. 이 문제를 해결하려면 모든 메모리를 소비하는 것이 무엇인지 알아야합니다. 이곳이 큰 미스터리입니다.

작업 관리자의 현재 통계 :

Physical Memory (K): 2096400
Commit Charge (K):   5364848
Page file usage:     5.11 GB

자, SysInternals Process Explorer 를 열고 실행중인 모든 것의 작업 세트 크기를 확인하십시오. 가장 큰 범인은 121,980K WS, 481,284K VM 크기를 사용하는 Tomcat 인스턴스입니다. 5GB 커밋 요금을 설명하는 데는 아무것도 없습니다.

다음 단계 : SysInternals pslist : pslist -m, 출력을 열별로 나누고보고 된 61 개의 프로세스에 대한 열 합계를 계산하십시오.

SUM (Working Set)  : 681,484 K
SUM (Private Bytes): 593,424 K

도구가보고하는 내용을 근본적으로 이해하고 있습니까? 나는 실제로 OS가 실제로 그렇게 많이 사용하지 않을 것이라는 가정하에 VM이 여기에 있다는 가정하에 OS가 실제로 프로세스에 의해 매핑 된 전체 가상 메모리보다 훨씬 적은 메모리를 커밋한다는 인상을 받았습니다. 붉은 청어.

JP, 이것이 안정적인 코드보다 적게 실행되는 자동화 된 빌드 / 단위 테스트 서버라는 의견은 모든 것을 말합니다. 내 생각에 불안정한 코드로 인해이 서버를 자주 재부팅해야 메모리 누수로 인해 증상이 나타납니다. 메모리 누수는 실행중인 프로세스의 프로세스 트리에 표시되지 않습니다. 메모리가 없기 때문에 더 이상 존재하지 않는 프로세스에 의해 잡히고 여전히 할당 된 메모리이기 때문에 실행중인 프로세스의 프로세스 트리에는 표시되지 않습니다.

이 동작이 성능 문제를 나타내는 속도에 따라 야간, 일주일에 몇 번 또는 매주이 시스템을 자동으로 재부팅 할 수있는 유지 관리 기간을 자주 확보하십시오.

우리는 Windoze에 Oracle Application Servers 서버가 있으며, 하루에 두 번 재부팅해야했습니다. 우리는 점심 시간과 매일 심야에 사용자를 쫓아 냈습니다. 몇 년 전, 오라클의 안정적인 프로덕션 코드와 함께였습니다.

링크를 붙여서 죄송합니다. logparser와 powershell을 사용하여 메모리 누수를 찾기 위해 몇 가지 기술을 사용하고 있으므로 공유하겠습니다.

http://blogs.msdn.com/debuggingtoolbox/archive/2008/08/22/powershell-script-chart-and-statistics-from-top-20-objects-leaking.aspx

(Never Doubt Thy Debugger 사이트는 훌륭합니다) : http://blogs.msdn.com/carloc/archive/2007/09/14/something-you-need-to-know-before-start-debugging.aspx

또한 Windows에서 메모리 사용에 대한 Mark Russinovich의 탁월한 통찰력에 대한 링크를 제공합니다.

http://blogs.technet.com/markrussinovich/search.aspx?q=memory&p=1

실제 Microsoft 사례를 열지 못하는 Performance Team 사이트에는 많은 정보가 있습니다. http://blogs.technet.com/askperf/Default.aspx?p=2

이를 진단하는 데 도움이되는 주요 도구는 perfmon입니다. 내가 볼 카운터는 다음과 같습니다.

Memory, Committed Bytes (메모리, 커밋 된 바이트) 이것은 가상 메모리에 대한 수요를 측정 한 것입니다.
Process, Working Set, _ "active"의 총 가상 메모리 사용
페이징 파일, % pagefile 사용중인
메모리, Pages / Sec (필수 메모리 부족을 나타내는 것은 아닙니다) 모두는 않습니다) 가정하는 것처럼 보이지만
메모리, 페이지 출력 / 다른 용도로 사용 가능한 RAM 페이지 프레임에 페이지 파일에 기록 된 초 얼마나 많은 가상 메모리 페이지 매 초마다

메모리, 캐시 바이트
메모리, 풀 비 페이징 바이트
메모리, 풀 페이징 바이트
메모리, 시스템 코드 총 바이트
메모리, 시스템 드라이버 총 바이트

이 합계가 2GB에 가까워지면 일반적으로 32 비트 아키텍처로 인해 성능 문제가 발생합니다

Memory, Available MBytes (메모리, 사용 가능한 MB)-가상 메모리 (새 할당 또는 페이지 파일에서 페이지를 복원)에 대한 요구를 충족시키기 위해 사용 가능한 RAM의 양을 측정합니다.

http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm 참조

마지막 재부팅 이후 해당 서버가 얼마 동안 실행 되었습니까? 불행히도 Windows에 메모리 누수가있는 것은 사실입니다. 즉, 할당 된 메모리가 항상 시스템으로 다시 해제되는 것은 아닙니다. 증상은 정확히 당신이보고있는 것입니다. 아직하지 않았다면 적어도 일주일에 한 번 재부팅하는 것이 좋습니다. 많은 데이터 센터가 매일 Windows를 재부팅하므로 지원 요청이 크게 줄어 듭니다. 물론 가동 중지 시간이 없기 때문에 클러스터를 사용할 때 훨씬 쉽게 수행 할 수 있습니다.

Windows 메모리 통계를 실제로 이해하는 어딘가에 sysadmin이 있다고 말했지만 결코 만난 적이 없습니다.

그러나 일반적으로 오작동하는 프로세스를 찾기가 어렵지 않습니다. Perfmon을 사용하여 핸들 또는 페이지 결함 / 초와 같은 다양한 프로세스 카운터를보십시오.

JR

추가 생각 : 실제로 메모리가 부족하다고 확신합니까? 중요한 것은 페이징을 받고 있는지 여부입니다. 페이징이 없으면 메모리가 부족하지 않습니다. PerfMon을 사용하면 Memory-Pages / sec 카운터를 살펴보십시오.

작업 세트는 실제로 실제 메모리로 표시되는 메모리 비트입니다. 또한 가상 메모리 요금이 부과되고 Windows는 코드 페이지 공유를 수행하며 일부 MFC 덩어리는 메모리 사용량을 복제하지 않고 많은 프로세스와 프로세스간에 공유됩니다. 또한 파일 시스템 캐시를 최대한 크게 유지하려는 Windows의 끊임없는 욕구가 있습니다 (이전 2.5GB 랩톱에서 800MB로 풍선을 보았습니다).

Windows 메모리 관리는 매우 강력합니다. 그러나 Windows가 페이징을 시작하면 문제가 발생하기 때문에 항상 항상 항상 파일 시스템 캐시를위한 공간을 남겨 두어야합니다. 80+ 탭이 최대 1.2gb / 1.2 + gb의 메모리 소비를 발생 시키면 Firefox를 종료하고 다시 시작해야합니다.

또한 Windows는 캐시에있는 페이지와 메모리 / 작업 집합으로 나열된 페이지 사이의 선을 약간 흐리게합니다.