많은 사람들이 그것을 사용합니다.ps_mem.py프로세스가 사용하는 RAM의 양을 확인하는 스크립트입니다. 이 경우 스크립트의 결과는 다음과 같습니다.
---------------------------------
278.4 MiB
=================================
따라서 전체 시스템은 278.4MiB를 사용하지만 free완전히 다른 것을 표현합니다.
# free
total used free shared buff/cache available
Mem: 1.8G 756M 980M 57M 131M 1.0G
Swap: 2.5G 11M 2.5G
Total: 4.3G 767M 3.4G
따라서 여기서 시스템은 756M을 사용합니다. 캐싱도 아니고 임시 파일 때문도 아닙니다.
나는 또한 다음을 시도했습니다.
# echo "3" > /proc/sys/vm/drop_caches
변화가 있는지 확인했지만 아무것도 바뀌지 않았습니다.
그렇다면 어떤 이유로 점유된 페이지를 어떻게 해제합니까? 그 공간이 무엇이며 왜 사용되는지, 어떻게 복원하는지 전혀 모릅니다. 현재 유일한 옵션은 시스템을 재부팅하는 것입니다.
나머지 과정을 볼 수 있는 사진입니다. 이를 토대로 RAM 활용도를 설명할 수 있나요?
답변1
가상 메모리 관리(모두 가능한 한 최소한의 메모리를 사용하는 것을 목표로 함)의 복잡성으로 인해 실제로 사용되는 RAM의 양을 확인하는 것은 사실상 불가능합니다. 바라보다이 링크.
따라서 Python 스크립트가 보고하는 내용이 무엇이든 실제 상태를 반영하지 않습니다.
캐시된 콘텐츠는 실제로 무료입니다. 걱정하지 마세요. 캐시를 삭제해도 실제로는 아무 것도 해제되지 않으며 필요할 때 커널이 재사용할 페이지를 새로 고칠 뿐입니다.
무료로 보고되는 것은 시스템에 대한 커널의 지식입니다. 커널이 메모리를 서비스하고 있으므로 이는 잘못된 것일 수 없습니다. 그러나 공유 메모리(라이브러리), 쓰기 시 복사 메모리(포크 후 터치된 페이지만 실제로 복제됨), 초기화되지 않은( 제로화) 페이지, 로드된 프로그램 코드(공유), RAM에 해당하지 않는 가상 메모리, 교체된 페이지, 프로세스 간 공유 메모리, 커널 메모리(커널 모듈에 의해 예약됨), 커널 메모리(메인 커널 자체), 페이지 테이블 포함) 등
요점은... 커널이 페이지를 사용된 것으로 보고하는 경우 해당 페이지를 어떤 용도로 사용해야 한다는 것입니다. 일부 메모리를 비우려면 어딘가에서 메모리를 가져와야 합니다. 실행 중인 모든 프로세스, 모듈 및 커널 자체에는 지금 필요하지 않을 수 있는 일부 메모리를 비우기 위한 메커니즘이 있을 수 있으며 나중에 다시 로드됩니다(응용 프로그램에 따라 다름). 프로그래머는 이를 수행하는 데 필요한 복잡성을 확인합니다. 그러나 새로운 메모리가 필요하면 커널이 이를 처리합니다. 더 많은 메모리를 요청하면 파일 시스템 캐시가 삭제되고, 사용 중인 경우 오래된 페이지를 스왑에 푸시하고, zram 등을 사용하면 페이지가 압축됩니다... 마지막으로 메모리가 부족하면 공간이 있으면 OOM Killer는 시스템이 정지되는 것을 방지하기 위해 죽일 무언가를 찾습니다. 그러나 내부에서 일어나는 일보다 자신이 더 잘 안다고 생각하기에는 그 과정이 너무 복잡합니다.