프로덕션 환경에서는 drop 캐시 명령을 실행하여 echo 3 > /proc/sys/vm/drop_cachesRAM을 확보합니다. 그러나 캐시를 삭제하는 것은 좋은 습관이 아니며 프로세스에 더 많은 메모리가 필요하고 해당 메모리를 사용할 수 없는 경우 OS가 캐시를 지우고 그에 따라 메모리를 할당하기 때문에 별로 도움이 되지 않는다는 것을 알았습니다.
기술적 가치도 있다쓸 수 있는명령을 실행하기 전과 후의 메모리는 drop_caches동일해야 합니다.
하지만 몇 가지 테스트를 실행했을 때 캐시를 삭제하면 여유 RAM을 확보하는 데 도움이 된다는 사실을 발견했습니다.
free -h-캐시를 삭제하기 전에
total used free shared buff/cache available
Mem: 7.6G 4.2G 524M 306M 2.9G 2.8G
Swap: 4.0G 439M 3.6G
free-h-캐시 삭제 후
total used free shared buff/cache available
Mem: 7.6G 3.3G 3.8G 306M 452M 3.8G
Swap: 4.0G 439M 3.6G
우리가 볼 수 있듯이쓸 수 있는메모리가 1GB 증가하고 더 흥미로운 점은사용된메모리가 거의 1GB 정도 줄어듭니다. 이것이 내가 매우 혼란스러워하는 부분입니다. drop_cache명령을 그냥 지워서는 안됩니까 cached memory? 일부 실행 중인 프로세스(예:사용된메모리)
누군가 이것을 설명할 수 있나요?
- 명령은 어떻게
echo 3 > /proc/sys/vm/drop_caches작동하나요? - free 명령에서 사용 가능한 메모리를 계산하는 방법(사용 가능한 메모리 분석)
편집 후
내 질문 중 하나가 아직 답변되지 않았습니다.
기술적으로 drop_caches 명령 실행 전과 실행 후 사용 가능한 메모리 값은 동일해야 합니다.
우리가 논의한 것처럼,쓸 수 있는메모리에는 회수 가능한 슬래브 객체가 포함됩니다.
예, 재활용 가능한 슬래브 객체는 프리, 버퍼 또는 캐시에 포함되어 있지 않으므로 결국 사용된다는 의미입니다. "사용 가능"의 정의에는 명시적으로 포함되어 있으므로 거기에도 포함됩니다.
하지만 실행하면 echo 2 > /proc/sys/vm/drop_caches회수 가능한 슬랩 객체(디렉토리 및 inode 포함)가 해제됩니다.
캐시를 삭제하기 전에
total used free shared buff/cache available
Mem: 7.6G 4.2G 397M 331M 3.0G 2.7G
Swap: 4.0G 429M 3.6G
캐시 삭제 후
total used free shared buff/cache available
Mem: 7.6G 3.3G 3.8G 331M 483M 3.8G
Swap: 4.0G 429M 3.6G
우리가 여기서 보는 것처럼쓸 수 있는캐시 삭제 후 메모리가 늘어났는데 이미 사용하고 있으니 echo 2그냥 무료네요 reclaimable slab objects. ~처럼쓸 수 있는메모리에는 항상 reclaimable slab objects런타임 시 echo 2 > /proc/sys/vm/drop_caches변경되어서는 안 되는 값이 포함되어 있습니다.쓸 수 있는메모리.
하지만 내 경우에는 그렇지 않습니다.