메모리 요구가 증가 할 때 Linux에서 대용량 디스크 캐시를 해제하지 않음

2.6.31-302 x86-64 커널에서 Ubuntu 실행 전반적인 문제는 '캐시 된'카테고리에 메모리가있어 계속 진행되며 응용 프로그램이 필요할 때도 해제되거나 사용되지 않는다는 것입니다.

여기에 '무료'명령에서 얻는 것이 있습니다. 이것의 어느 것도 언뜻보기에는 평범하지 않습니다.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

누군가가 할 말은 "리눅스는 그 메모리를 자동으로 관리하는 것입니다." 예, 메모리 관리자의 작동 방식을 알고 있습니다. 문제는 그것이 옳은 일을하지 않는다는 것입니다. 여기에서 "캐시 된"1.4GB는 예약되어 사용할 수없는 것으로 보입니다.

Linux에 대한 나의 지식은 3GB가 "무료"라고 말합니다. 그러나 시스템의 행동은 그렇지 않다고 말합니다. 최대 사용량 동안 1.6GB의 실제 사용 가능한 메모리가 소진되면 더 많은 메모리가 필요하고 (첫 번째 열의 '사용 가능'이 0에 가까워지면) OOM 킬러가 호출되고 프로세스가 종료되고 문제가 발생하기 시작합니다. 비록 의 '무료'- / + 버퍼 / 캐시 행이 여전히이 약 1.4 GB '자유'.

핵심 프로세스에서 oom_adj 값을 조정하여 시스템이 무릎을 꿇지 않지만 중요한 프로세스가 종료 되어도 그 시점에 도달하고 싶지 않습니다. 특히 1.4GB가 디스크 캐시를 제거 할 경우 여전히 "사용 가능한"경우가 있습니다.

여기에 무슨 일이 일어나고 있는지 아는 사람이 있습니까? 인터넷에는 Linux 'free'명령에 대한 멍청한 질문과 "여유 여유 메모리가없는 이유"가 넘쳐나고 있기 때문에이 문제에 대해 아무것도 찾을 수 없습니다.

내 머리에 들리는 첫 번째 일은 스왑이 꺼져 있다는 것입니다. 우리는 그것에 대해 단호한 sysadmin을 가지고 있습니다. 그들이 백업되면 설명에 열려 있습니다. 이것이 문제를 일으킬 수 있습니까?

다음은 실행 후 무료입니다 echo 3 > /proc/sys/vm/drop_caches.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

보다시피, 약간의 캐시가 실제로 해제되었지만 약 1.4GB가 "고정"된 것으로 보입니다. 다른 문제는이 값이 시간이 지남에 따라 증가하는 것 같습니다. 다른 서버에서 2.0GB가 멈췄습니다.

나는이 기억을 정말로 되찾고 싶습니다 ... 어떤 도움이라도 가장 감사하겠습니다.

cat /proc/meminfo가치있는 것이 있다면 다음과 같습니다 .

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB

womble의 도움 덕분에 내 질문에 대한 답을 찾았습니다 (원하는 경우 답변을 제출하십시오).

lsof -s 사용중인 파일 핸들을 표시하고 캐시를 차지하는 수 기가 바이트의 mmap'd 로그 파일이있는 것으로 나타났습니다.

로그 로테이션을 구현하면 문제를 완전히 해결하고 더 많은 메모리를 활용할 수 있습니다.

또한 스왑을 다시 활성화하여 향후 OOM 킬러에 문제가 없도록합니다. 감사.

분명히 postgres 는에 쉽게 shared_buffers표시 cached되지 않지만 에 표시 될 수 있습니다 ... 사용 가능한 메모리 (캐시)에도 불구하고 OOM 참조