배경
내 질문은 기본적으로 이 질문에 대한 후속 조치입니다.질문그리고답변, 특히 이건논평.
많은 수의 파일을 복사하거나 재동기화해야 할 때마다 시스템의 메모리가 가득 차는 경향이 있으므로 루트로 다음과 같은 스크립트를 실행합니다.
while true ; do echo "syncing" && sync && echo 3 > /proc/sys/vm/drop_caches && echo "done" && sleep 60 ; done ;
질문
- 이것이 어떤 식으로든 시스템에 해를 끼치거나 부정적인 영향을 미치나요? (구체적으로 인용된 리뷰에서 언급된 "위험"은 무엇입니까?)
- 대답이 "아니요"(내가 의심하는 것임)라면 Linux가 기본적으로 이 명령을 자동으로 실행하지 않는 이유는 무엇입니까? (눈에 띄는 변화는 보이지 않았고, 메모리가 부족하지 않은 것만 확인했습니다...)
답변1
캐시를 삭제해도 아무런 소용이 없기 때문입니다. 물건을 잊어버리는 것은 이득이 있는 곳이 아닙니다. 이점은 어쨌든 일어날 메모리를 재사용하는 것입니다. 일부 포인트 데이터가 메모리에서 지워지기 때문입니다.
그러나 이러한 대규모 작업을 실행하면 성능이 저하될 수 있습니다. 데이터가 캐시되었지만 재사용되지 않으면 아무런 이점도 없이 다른 데이터가 제거됩니다.
따라서 캐싱 없이 작업을 실행해야 합니다(불행히도 이 작업을 수행하는 명령이 기억나지 않습니다).
답변2
Linux가 캐시를 자동으로 지우지 않는 이유는 무엇입니까?
그럴 것이다.
ron> free -g
total used free shared buffers cached
Mem: 504 415 88 1 0 352
-/+ buffers/cache: 62 441
Swap: 0 0 0
캐시 메모리는 여전히 사용 가능한 메모리로 간주되어야 합니다.
여유 공간이 0으로 줄어들면 캐시에서 가져옵니다.
이것이 어떤 식으로든 시스템에 해를 끼치거나 부정적인 영향을 미치나요?
해로움 = 아니요. 좀 조사해 echo 3 > /proc/sys/vm/drop_caches보시면 알 수 있을 겁니다비파괴적인작업.
부정적인 영향은 디스크에서 캐시 내용을 읽어야 하므로 성능이 저하된다는 것입니다. 예를 들어, 10GB 데이터 파일을 읽는 C 프로그램을 작성해 보세요. 처음 실행하면 디스크에서 읽기 때문에 속도가 느려지지만 그 이후에는 데이터 파일이 메모리에 캐시되므로 훨씬 빨라집니다. 캐시를 제거하면 데이터 파일을 읽는 다음 프로그램 실행이 첫 번째 실행만큼 느려집니다. 이는 관찰하고 반복하기 쉽습니다.
대답이 '아니오'라면 Linux가 기본적으로 이 명령을 자동으로 실행하지 않는 이유는 무엇입니까?
이러한 일이 발생하는 것을 어떻게, 어디서 목격했는지 자세히 설명해야 합니다. 현재 Linux(예: RHEL/CentOS 7.7)에서는 이에 대해 모르겠습니다. 그러나 이전 Linux(예: 3.0 이전) 몇 년 전 SLES 11.4를 사용했을 때 SuSE 직원이 캐시를 자동으로 삭제하는 코드를 작성하지 않았을 것이라고 확신합니다. 하지만 일부 작업 서버의 경우 우리가 캐시를 구입하여 당시 우리를 위해 SLES를 구성한 사람이 있었습니다. crontab을 사용하여 주기적으로 캐시를 삭제하는 경우, 이 작업이 수행되는 이유는 회색 영역입니다. 나는 이것이 결코 파괴적인 명령이 아니었고 실제로 해를 끼칠 수 없었기 때문에 관리 태도 = 좋은 사고 방식이라고 생각합니다. sles 11.4에서 수동으로 몇 번 수행한 것은 echo 3 > drop_caches문제 해결을 위한 것이었습니다. 궁극적으로 재부팅이 필요한 문제는 실제로 해결되지 않았기 때문입니다.
RHEL 성능 조정 가이드 및 가상 메모리 조정을 확인하세요. Linux 배포판에만 적용되는 것이 아니라 모든 Linux 커널과 관련될 만큼 낮은 수준이 아니라 RHEL에만 적용되는 내용이 얼마나 되는지 모르겠습니다. 또한 커널 2.6에서 3.x, 4.x로 이동하면서 이 영역의 변경 사항이 중요하다고 확신하므로 Linux 커널 릴리스 노트를 읽어 보세요.