vmstat -s
Linux 시스템에서 명령을 실행할 때 얻는 통계는 다음과 같습니다.
$ vmstat -s
16305800 total memory
16217112 used memory
9117400 active memory
6689116 inactive memory
88688 free memory
151280 buffer memory
이 명령으로 표시되는 세부 정보 중 일부를 건너뛰었습니다.
나는 용어를 이해합니다. 활성 메모리는 특정 프로세스에서 사용되는 메모리입니다. 비활성 메모리는 더 이상 실행되지 않는 프로세스에 할당된 메모리입니다.
궁금해요. 비활성 메모리가 할당된 프로세스를 가져올 수 있는 방법이 있나요? top
or vmstat
명령은 여전히 사용된 메모리를 활성 메모리와 비활성 메모리의 합계로 표시하고 활성 메모리를 사용하는 프로세스만 볼 수 있기 때문에 어떤 프로세스가 비활성 메모리를 사용하고 있는지는 여전히 나에게 질문입니다 .
답변1
어떤 경우에는 비활성 메모리를 살펴보는 것이 흥미로울 수 있습니다. 예를 들어 비활성 메모리에 대한 활성 메모리의 높은 비율은 메모리 부족을 나타낼 수 있지만 이는 일반적으로 이해하고 관찰하기 쉬운 페이징/스와핑을 동반합니다. 또 다른 시나리오는 시간이 지남에 따라 활성 메모리가 증가하거나 들쭉날쭉해지는 것을 볼 수 있는 것입니다. 이는 비효율적인 소프트웨어에 대한 조기 경고를 제공할 수 있습니다( O(n)
이 시점에서 유형 동작 및 성능 저하를 보이는 순진한 소프트웨어 구현에서 이것을 본 적이 있습니다).
이 파일에는 /proc/kpageflags
각 물리적 메모리 페이지의 64비트 비트맵이 포함되어 있으며 프로그램을 통해 요약을 얻을 수 있습니다.page-types
아마도 커널과 함께 제공될 것입니다.
너의 이해긍정적인그리고비활성그러나 그것은 잘못된 것이다
- 활성 기억"최근" 방문한 페이지입니다
- 비활성 메모리'최근' 방문한 적이 없는 페이지입니다
"최근"은 시간의 절대적인 척도가 아니며 활동 및 기억력에 따라 달라집니다. (무료 책에서 일부 기술적인 세부 사항을 읽을 수 있습니다.)Linux 가상 메모리 관리자 이해,제10장여기 관련) 또는 커널 문서(페이지 매핑.txt).
각 목록은 LRU(다소)로 저장됩니다. 비활성 메모리 페이지는 선제적으로(여유 메모리 페이지가 필요하기 전) 또는 여유 메모리가 구성된 제한보다 낮고 곧 여유 페이지가 필요할 것으로 예상되는 경우 스왑 파일에 쓰기에 좋은 후보입니다.
두 플래그 중 하나는 실행 중인 프로세스에 할당된 페이지에 적용되며, 프로세스가 종료되면 영구 메모리 또는 공유 메모리를 제외한 모든 메모리가 해제되고, 그렇지 않으면 오류로 처리됩니다.
이 낮은 수준의 페이지 태깅에는 PID에 대한 지식이 필요하지 않으므로(어떠한 경우에도 메모리 페이지에는 여러 개의 매핑된 PID가 있을 수 있음) 요청한 데이터를 제공하는 데 필요한 정보가 한 곳에 있지 않습니다.
프로세스별로 이 작업을 수행하려면 가상 주소 범위를 추출하고 /prod/PID/maps
PFN(물리적 페이지)으로 변환한 /proc/PID/pagemap
후 색인을 생성 해야 합니다 /proc/kpageflags
. 이 모든 내용은 pagemap.txt
C 언어에서 약 60~80줄 정도 소요됩니다. VM 시스템 문제를 해결하는 것이 아니라면 이 수치는 그리 흥미롭지 않습니다. 당신이 할 수 있는 한 가지는 각 프로세스에 대한 비활성 페이지와 스왑 지원 페이지를 계산하는 것입니다. 이 숫자는 VSZ(총 가상 머신 크기)에 비해 RSS(상주) 크기가 더 낮은 프로세스를 나타냅니다. 또 다른 방법은 메모리 누수를 추론하는 것일 수 있지만 해당 작업을 위한 더 나은 도구가 있습니다.
답변2
외부 프로그램에는 전혀 의미가 없는 도구가 없습니다.
시스템에서 이를 알아야 하는 유일한 것은 커널의 메모리 핸들러입니다. 커널의 메모리 핸들러는 이를 사용하여 사용 가능한 메모리가 고갈될 때 페이지 아웃(스왑)할 항목을 파악합니다.
우려를 불러일으킬 수 있는 유일한 관련 상황은 교환이 거의 가득 찬 경우입니다. 이런 일이 발생하면 늘리십시오.
비활성 메모리를 조사해야 하는 실제 문제를 본 적이 없습니다.