☰

버퍼/캐시를 줄이는 방법

tag-icon • tag-icon rhel mysql cache ram buffer
버퍼/캐시를 줄이는 방법

모니터링 시스템은 내 컴퓨터가 RAM 사용 임계값에 도달/위반하고 있음을 계속 경고합니다.15GB.

나는 약간의 독서를 통해 명백한 RAM 활용이 실제로는 아니며 서버 성능을 향상시키기 위해 디스크 I/O 작업의 캐싱/버퍼링에 추가 RAM이 사용된다는 것을 알게 되었습니다. 저는 이 서버에서 MySQL을 실행하고 있는데 이것이 유일하게 실행되는 서비스입니다.

  • 그렇다면 임계값을 위반하지 않도록 디스크 I/O 캐시/버퍼 RAM을 어떻게 줄일 수 있습니까? 이것이 Linux 문제가 아니라 MySQL 문제일 수 있습니까?

이것이 출력이다free -gt

[root@ipk ~]# free -gt
             total       used       free     shared    buffers     cached
Mem:            15         15          0          0          0          9
-/+ buffers/cache:          5         10
Swap:            5          0          5
Total:          21         15          6

Linux 버전은 다음과 같습니다.

[root@ipk ~]# uname -rmo
2.6.32-220.el6.x86_64 x86_64 GNU/Linux

답변1

귀하는 우리의 의견이나 우리가 "공식"으로 링크한 다양한 페이지를 받아들이지 않는 것 같으니 아마도 공식 Red Hat문서당신을 설득할 것입니다:

이 예에서 사용 가능한 총 메모리는 4040360KB입니다. 264224KB는 프로세스에 사용할 수 있고 3776136KB는 다른 응용 프로그램에 사용할 수 있습니다.28160KB를 사용할 수 있다는 첫 번째 줄에 혼동하지 마세요!사용량 데이터를 보면 대부분의 메모리 사용량이 버퍼와 캐시에 사용된다는 것을 알 수 있습니다.Linux는 버퍼(파일 시스템 메타데이터) 및 캐시(파일 또는 블록 장치의 실제 내용이 포함된 페이지)에 사용 가능한 메모리를 사용하여 디스크 작업 속도를 높이기 위해 항상 RAM을 사용하려고 시도합니다.이는 디스크 정보가 이미 메모리에 있으므로 I/O 작업이 절약되므로 시스템 실행 속도를 높이는 데 도움이 됩니다.Oracle과 같은 프로그램이나 애플리케이션에 공간이 필요한 경우 Linux는 버퍼와 캐시를 확보하여 애플리케이션에서 메모리를 사용할 수 있도록 합니다.시스템이 한동안 실행된 경우 일반적으로 "유휴" 필드 아래 첫 번째 줄에 작은 숫자가 표시됩니다.

답변2

다 좋은데, 메모리 요청을 하고 이를 디스크 캐시가 해제해야 하는 항목에 매핑하는 사이의 대기 시간은 어떻습니까? 물론 작거나 눈에 띄지 않는다고 말할 수도 있겠지만, 이 과정에서 추가된 0.0000001초가 신경쓰일 수도 있습니다. 내 RAM이 어떻게 사용되는지 결정하는 사람은 누구입니까?

이러한 지연 시간을 경험하고 싶지 않다면 어떻게 해야 합니까? 아마도 내 앱이 드라이브에서 더 느리게 로드되는 것은 문제가 되지 않지만 디스크 캐시에서 매핑되지 않은 메모리가 지연되지 않고 즉시 RAM을 차지하기를 원할 수도 있습니다.

디스크 캐시에 사용되는 RAM의 양을 제한하는 방법은 무엇입니까? 이 일을 할 수 있는 방법이 없다고 말하지 마세요.

고쳐 쓰다: 방법을 찾았습니다.

echo 3 | sudo tee /proc/sys/vm/drop_caches

a를 실행하십시오: free -m위의 확인을 실행한 후. 효과가있다.

답변3

모니터링에서 실제로 어떤 측정항목을 사용하는지 알고 있나요? 최신 Linux 커널의 경우 기본적으로 다음을 따라야 합니다 MemAvailable.

$ grep MemAvailable: /proc/meminfo 
MemAvailable:   11747552 kB

왜냐하면 Free, Cache 및 Buffers는 자신이 무엇을 하고 있는지 실제로 알지 않는 한 아무 의미가 없기 때문입니다. 버퍼와 캐시는 동일하며 모든 공유 메모리를 포함합니다. 예를 들어 PostgreSQL을 실행하고 shared_buffers해당 값을 10GB로 구성하면 버퍼/캐시 값은 10GB 증가하고 메모리는서비스 중단다른 모든 것은 커널에 의해 처리됩니다. 그냥 추가 Free하고 추가 할 수 있다고 말하는 사람은 Cache과거 시스템이나 필요한 경우 실제로 모든 캐시를 삭제할 수 있는 특별한 경우에 대해 이야기하는 것입니다.

최신 커널은 바로 이러한 이유로 사용 가능한 메모리를 계산합니다. 커널 버전과 실행 파일이 모두 충분히 새로운 경우 free출력은 다음과 같아야 합니다.

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          31807        6161        5097         970       20547       11471
Swap:          1590          51        1538

마지막 열을 참고하세요 available. 이것이 당신이 집중해야 할 가치입니다. 위의 예에서는 5GB의 여유 공간과 20GB의 캐시를 보여줍니다. 일반적인 목적에서는 이를 무시하세요. 갑자기 15GB의 RAM이 필요한 프로그램을 실행한다면 캐시가 삭제되는 것이 아니라 OOM Killer가 조치를 취했다고 가정합니다.

내 경험에 따르면 "사용 가능"이 0에 도달하면 시스템은 여전히 ​​정상적으로 응답할 수 있지만 커널이 아는 한 시스템은 속도를 늦출 위험이 없이 더 이상 로드를 처리할 수 없습니다.

의미가 있는 또 다른 값은 Committed_AS실제 RAM을 초과하면 시스템의 메모리가 부족해질 수 있지만 실제 결과는 실행하는 프로그램에 따라 다릅니다. fork()호출하지만 메모리를 더럽히지 않는 대규모 프로그램을 실행하면 아마도 괜찮을 것입니다. Linux 메모리 관리의 CoW 기능 덕분입니다. 예를 들어,

$ grep -E 'MemTotal:|Committed_AS:' /proc/meminfo 
MemTotal:       32570620 kB
Committed_AS:   20839784 kB

이 예에서는 MemTotal음수 값이 Committed_AS가까울 뿐인데 MemAvailable믿기지 않습니다. 일반적인 작업 부하의 경우 OOM Killer는 일반적으로 응용 프로그램이 Committed_AS약 130% 이상에 도달 MemTotal하면 응용 프로그램을 종료하기 시작합니다 . 물론 스왑을 많이 추가하면 OOM Killer가 활성화되지 않지만 스왑으로 인해 시스템 속도가 느려집니다.

관련 정보