태그 보관물: cache

cache

Linux에서 캐시를 삭제하는 이유는 무엇입니까? > /proc/sys/vm/drop_caches 코드를 실행할 때 많은

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

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 낭비입니다”라고 말하고 캐싱을 제안합니다) 또는 다른 곳에서 문제가 해결되었다는 사실을 발견했습니다 (적절한 수정 방법을 찾기에는 너무 게으름).