Linux에서 캐시를 삭제하는 이유는 무엇입니까?

서버에는 자정에 캐시를 버리는 습관이 있습니다.

sync; echo 3 > /proc/sys/vm/drop_caches

코드를 실행할 때 많은 RAM을 확보하는 것처럼 보이지만 실제로 그렇게해야합니다. RAM을 낭비하지 않습니까?

당신은 100 % 정확합니다. RAM을 비우는 것은 좋은 습관 이 아닙니다 . 이것은화물 컬트 시스템 관리의 예일 것입니다.

예. 캐시를 지우면 RAM이 비워 지지만 커널은 캐시가 아닌 디스크에서 파일을 찾아 성능 문제를 일으킬 수 있습니다.

일반적으로 커널은 사용 가능한 RAM이 고갈되면 캐시를 지 웁니다. pdflush를 사용하여 오염 된 내용을 디스크에 자주 씁니다.

이와 같이 캐시를 삭제하는 이유는 디스크 성능을 벤치마킹하기위한 것이며 이것이 존재하는 유일한 이유입니다.

I / O 집약적 벤치 마크를 실행할 때 시도하는 다양한 설정이 모두 실제로 디스크 I / O를 수행하고 있는지 확인하려고하므로 Linux를 사용하면 전체 재부팅이 아닌 캐시를 삭제할 수 있습니다.

설명서 에서 인용하려면 :

이 파일은 다양한 커널 캐시 (inodes, dentries, pagecache 등)의 증가를 제어하는 ​​수단이 아닙니다. 이러한 오브젝트는 시스템의 다른 곳에 메모리가 필요할 때 커널에 의해 자동으로 재생됩니다.

이 파일을 사용하면 성능 문제가 발생할 수 있습니다. 캐시 된 객체를 삭제하기 때문에 특히 사용량이 많은 경우 삭제 된 객체를 재생성하는 데 상당한 양의 I / O 및 CPU가 필요할 수 있습니다. 이 때문에 테스트 또는 디버깅 환경 외부에서 사용하지 않는 것이 좋습니다.

여기서 기본 개념은 그리 나쁘지 않을 것입니다 (매우 순진하고 오해의 소지가 있습니다) : 캐시 된 파일이있을 수 있습니다.이 파일은 가까운 장래에 액세스 할 가능성이 거의 없습니다 (예 : 로그 파일). 이러한 "eat up"램은 나중에 OS에서 필요에 따라 한 가지 방법으로 해제해야합니다.

swappiness, 파일 액세스 패턴, 메모리 할당 패턴 및 더 예측할 수없는 많은 설정에 따라 이러한 캐시를 해제하지 않으면 나중에 다시 사용하도록 강제 될 수 있습니다. 사용되지 않은 메모리 풀에서 메모리 할당 최악의 경우 리눅스의 swappiness 설정으로 인해 프로그램 메모리가 스왑 아웃됩니다. 리눅스는 해당 파일이 프로그램 메모리보다 가까운 장래에 사용될 가능성이 높기 때문입니다.

내 환경에서 리눅스는 종종 잘못 추측하고 대부분의 유럽 증권 거래소 (약 0900 현지 시간)가 시작될 때 서버는 하루에 한 번만 수행하는 작업을 시작하며 쓰기 때문에 이전에 스왑 된 메모리를 스왑해야합니다. 로그 파일, 압축, 복사 등이 스왑 아웃 지점까지 캐시를 채우고있었습니다.

그러나 드롭하면이 문제에 대한 솔루션이 캐시됩니까? 분명히 아닙니다. 여기서 해결책은 리눅스에게 모르는 것을 알리는 것입니다. 이러한 파일은 더 이상 사용되지 않을 것입니다. 이것은 posix_fadvise()cmd 줄 도구와 같은 vmtouch것을 사용하거나 캐시 파일뿐만 아니라 사물을 조사하는 데 사용할 수 있는 작성 응용 프로그램으로 수행 할 수 있습니다 .

이렇게하면 더 이상 필요하지 않은 데이터를 캐시에서 제거하고 캐시해야 할 내용을 유지할 수 있습니다. 모든 캐시를 삭제하면 디스크에서 많은 내용을 다시 읽어야하기 때문입니다. 그리고 최악의 순간에 : 필요할 때; 응용 프로그램에서 눈에 띄고 종종 허용되지 않는 지연이 발생합니다.

갖추어야 할 것은 메모리 사용 패턴 (예 : 무언가가 교환되는 경우)을 모니터링 한 다음 그에 따라 분석하고 그에 따라 행동하는 시스템입니다. 해결책은 vtouch를 사용하여 하루 종일 큰 파일을 제거하는 것입니다. 서버의 일일 최대 사용량이 그저이기 때문에 더 많은 램을 추가하는 것일 수도 있습니다.

드롭 캐시가 여러 가상 머신을 시작할 때 유용한 것으로 나타났습니다. 또는 일부 데이터베이스 서버와 같이 큰 페이지를 사용하는 다른 것.

Linux의 큰 페이지는 종종 페이지에 넣을 2MB의 연속적인 실제 RAM을 찾기 위해 RAM을 조각 모음해야합니다. 모든 파일 캐시를 비우면이 프로세스가 매우 쉬워집니다.

그러나 나는 매일 밤마다 파일 캐시를 삭제 해야하는 좋은 이유가 없다는 점에서 대부분의 다른 답변에 동의합니다.

이것은 실제로 문제를 찾을 수있는 기술이나 경험이없는 사람이 없을 때 시스템을 안정화시키는 방법으로 설립되었을 수 있습니다.

자원 확보

캐시를 삭제하면 기본적으로 일부 리소스가 비워 지지만 시스템이 실제로 수행하려는 작업을 수행하기가 더 어려워지는 부작용이 있습니다. 시스템이 실제로 가능한 것보다 빠른 속도로 디스크 스왑 파티션에서 읽고 쓰려고 시도하는 경우 캐시를 주기적으로 삭제하면 증상 이 완화 될 수 있지만 원인 을 치료할 수는 없습니다 .

기억은 무엇입니까?

캐시 삭제가 작동하는 것처럼 보이는 많은 메모리 소비의 원인을 판별해야합니다. 이것은 잘못 구성되었거나 잘못 사용 된 서버 프로세스가 많기 때문에 발생할 수 있습니다. 예를 들어, 한 서버에서 Magento 웹 사이트가 15 분 간격으로 특정 방문자 수에 도달했을 때 메모리 사용률이 최대로 증가하는 것을 목격했습니다. 이는 너무 많은 프로세스가 동시에 실행될 수 있도록 Apache가 구성 되었기 때문입니다. 많은 메모리를 사용하는 프로세스가 너무 많습니다 (마 젠토는 때때로 짐승입니다) = 스와핑.

결론

그것이 필요한 것이라고 가정하지 마십시오. 그 이유가 무엇인지 알아 내고 적극적으로 행동하고 다른 사람들이 잘못 제안한 경우 시스템을 비활성화하고 시스템을 관찰하십시오. 실제 문제가 무엇인지 배우고 수정하십시오.

Linux / m68k에는 실제로 커널 버그가있어 kswapd가 미쳐서 100 % CPU를 소비합니다 (데비안 바이너리 패키지 자동 작성기-벌고 빌드 – 이미 실행 중과 같은 다른 CPU 바인딩 작업이있는 경우 50 %). 몇 시간마다이 특정 명령을 실행하면 항상 그런 것은 아닙니다.

말하자면 ... 귀하의 서버는 아마도 m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) 시스템이 아닙니다 .-)

이 경우, 줄에 넣은 사람은 의심 스럽거나 기껏해야 구식 조언을 따르거나 RAM을 어떻게 잘못 사용 해야하는지에 대한 아이디어를 얻었습니다 (현대적인 생각은 실제로 "무료 RAM은 RAM 낭비입니다"라고 말하고 캐싱을 제안합니다) 또는 다른 곳에서 문제가 해결되었다는 사실을 발견했습니다 (적절한 수정 방법을 찾기에는 너무 게으름).

한 가지 이유는 사이트에서 사용 가능한 램의 양을 확인하고 사용 가능한 램이 특정 비율 아래로 떨어지면 관리자에게 경고를 보내는 일종의 모니터링을 실행하는 것일 수 있습니다. 해당 모니터링 도구가 여유 램 계산에 캐시를 포함하지 않을 정도로 바보 인 경우 잘못된 경고를 보낼 수 있습니다. 캐시를 정기적으로 비우면 이러한 경고가 표시되지 않으면 서 "실제"램이 부족한 경우에도 도구가이를 알 수 있습니다.

물론, 이런 종류의 상황에서 실제 해결책은 모니터링 도구를 수정하여 프리 램 계산에 캐시를 포함시키는 것입니다. 프로세스가 디스크에 액세스 할 때 캐시가 빠르게 다시 채워 지므로 캐시 정리는 해결 방법 일뿐 아니라 잘못된 방법이기도합니다.

따라서 내 가정이 사실이더라도 캐시 정리는 의미가 없으며 기본 문제를 해결할 수있는 능력이없는 사람이 해결할 수 있습니다.

야간 크론 작업에서이를 수행하는 한 가지 그럴듯한 이유를 생각할 수 있습니다.

대규모 시스템에서는 메모리 조각화를 제거 할 수 있도록 캐시를 주기적으로 삭제하는 것이 유용 할 수 있습니다.

커널 투명 hugepage 지원은 작은 페이지를 hugepages로 통합하기 위해 주기적으로 메모리를 스윕합니다. 변성 된 조건에서 이로 인해 시스템이 1 ~ 2 분 정도 일시 중지 될 수 있습니다 (이에 대한 나의 경험은 RHEL6에 있었으며, 개선 되었기를 바랍니다). 캐시를 삭제하면 hugepage 스위퍼가 작업 할 공간이 생길 수 있습니다.

이것이 투명한 hugepages를 비활성화하는 좋은 이유라고 주장 할 수 있습니다. OTOH 당신은 투명한 hugepages의 전반적인 성능 향상이 가치가 있고 하루에 한 번 캐시를 잃는 가격을 지불 할 가치가 있다고 생각할 것입니다.

나는 cron 일이 아니지만 당신이 그것을하고 싶은 또 다른 이유를 생각했습니다. 가상화 시스템이 VM을 새 하드웨어로 마이그레이션하기 직전에이 작업을 수행하는 것이 좋습니다. 새 호스트에 복사 할 메모리 내용이 적습니다. 물론 스토리지에서 읽어야 할 것이지만, 아마도 그 절충점을 고려할 것입니다.

virt 소프트웨어가 실제로이 작업을 수행하는지 알 수 없습니다.

내 두 센트를 추가하기 만하면 : 시스템 은 이러한 메모리 페이지가 캐시임을 잘 알고 있으며 응용 프로그램이 메모리를 요청할 때 필요한만큼 많이 떨어집니다.

관련 설정은 /proc/sys/vm/swappiness새 메모리 할당 중에 커널에게 메모리 캐시를 삭제하거나 "유휴"할당 된 메모리 페이지를 교환하도록 지시합니다.

문제는 2014 년이지만, 숨겨진 centos 6.8 백엔드에서 오늘날까지 문제가 발생하므로 누군가에게 여전히 유용 할 수 있습니다.

https://github.com/zfsonlinux/zfs/issues/1548 은 zfs 관련 문제를 설명합니다. nfs가 zfs 위에 사용될 경우 파일의 inode가 커널의 inode 캐시에서 삭제되지 않기 때문에 디스크 공간은 삭제 된 파일에 대해 여유 공간을 확보하지 못합니다.

버그 스레드에서 인용하기 위해 behlendorf, 2015 년 1 월 6 일은 다음과 같이 썼습니다.

현재 추측은 어떤 이유로 NFS 서버가 캐시 된 버전의 파일 핸들을 유지하고 있다는 것입니다. NFS 서버가이 파일 핸들을 삭제할 때까지 ZFS는이 파일을 링크 해제 할 수 없습니다. 일부 가벼운 테스트에 따르면 서버에서 캐시를 삭제하면 공간이 올바르게 비워지는 시점에서이 참조가 삭제됩니다 (NFS 파일 핸들과 같이). 메모리 압력으로 인해 메모리가 떨어질 수도 있습니다.

즉, 야간 에코 3> / proc / sys / vm / drop_caches는 zfs를 재구성하기위한 가동 중지 시간을 원하지 않는 경우 해당 버그에 대한 가장 쉬운 수정입니다.

화물 관리가 아닐 수도 있지만 디버깅이 꽤 좋은 이유입니다.

이는 일반적으로 각 CPU (소켓)가 모든 메모리에 투명하게 액세스 할 수 있지만 병렬 HPC 응용 프로그램과 관련하여 다른 소켓의 메모리보다 빠르게 자체 메모리에 액세스 할 수있는 NUMA (비 균일 메모리 액세스) 시스템에서 의미가있을 수 있습니다.

많은 간단한 병렬 응용 프로그램은 단일 프로세스에서 파일 I / O를 수행하는 경향이 있으므로 디스크 캐시에 할당 된 단일 NUMA 노드에서 많은 양의 메모리를 종료하는 반면 다른 NUMA 노드에서는 메모리가 대부분 비어있을 수 있습니다. 이러한 상황에서 내가 아는 한 Linux 커널의 캐시 회수 프로세스는 여전히 NUMA를 인식하지 못하므로 캐시에 할당 된 메모리가있는 NUMA 노드에서 실행되는 프로세스는 다른 NUMA 노드에 메모리를 할당해야합니다. 다른 노드에 사용 가능한 RAM이 있으면 성능이 저하됩니다.

그러나 HPC 시스템에서는 cron을 사용하여 특정 시간이 아니라 새 사용자 작업을 시작하기 전에 캐시를 정리하는 것이 더 현명합니다.

비 병렬 응용 프로그램의 경우이 문제가 발생하지 않습니다.

페이지 캐시가 상당히 크면 (현재 스왑 사용량보다 훨씬 큰 경우) 스왑 인 및 스왑 아웃이 차례로 발생하면 캐시를 삭제해야 할 때입니다. 우분투 16.04LTS를 실행하는 MariaDB 데이터베이스 서버 중 하나에서 메모리 사용량이 증가하는 경우를 보았고 Linux는 사용되지 않은 페이지 캐시를 제거하는 대신 스왑 사용량을 늘리기로 선택했습니다. TokuDB가 비활성화해야하기 때문에 시스템에서 투명 거대한 페이지가 이미 비활성화되었습니다. 어쨌든 그것은 버그가 아니지만 리눅스가 여전히이 동작을 수행하는 것은 나에게 수수께끼입니다. 다양한 소스는 애플리케이션이 요청했을 때 리눅스가 페이지 캐시를 제거한다고 밝혔다.

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

그러나 현실은 그렇게 간단하지 않습니다. 해결 방법은 다음 중 하나입니다.

1. 드롭 캐시를 주기적으로 실행
2. 필요할 때 드롭 캐시 실행 (활동 스왑 아웃을 위해 vmstat 1을 사용하여 모니터링)
3. dd 또는 python-fadvise와 같은 유틸리티를 사용하여 캐시에서 특정 파일 (아파치 로그 파일 등)을 제거하도록 Linux에 조언하십시오. https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache를 참조 하십시오.

dd run 예 :

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

python-fadvise 예제 :

pyadvise -d /var/log/apache2/access_log.1

PAE 커널에서 16GB의 RAM이 실행되는 데스크톱 시스템이 있습니다. 1 ~ 2 시간 후 캐시 성능을 떨어 뜨릴 때까지 디스크 성능이 크게 저하되어 간단히 cron에 넣습니다. 이것이 PAE 커널에 문제가 있는지 또는 메모리가 많으면 캐시 구현이 너무 느리다는 것을 모르겠습니다.