사용 가능한 메모리 (캐시)에도 불구하고 OOM

우리는 거의 절반의 메모리가 FS 캐시에 사용되고 있음에도 불구하고 OOM 킬러를 만났습니다. 우리는 1 분에 한 번 메모리 통계를 기록하고 있지만 (위에서보고 한 바와 같이) 많은 가용성이있는 것 같습니다.

...

Mem:  15339640k total, 15268304k used,    71336k free,     3152k buffers
Swap:        0k total,        0k used,        0k free,  6608384k cached

Mem:  15339640k total, 14855280k used,   484360k free,    13748k buffers
Swap:        0k total,        0k used,        0k free,  6481852k cached

[OOM killer: postgres killed]

Mem:  15339640k total,  8212200k used,  7127440k free,    32776k buffers
Swap:        0k total,        0k used,        0k free,  2394444k cached

...

syslog의 OOM 세부 사항 :

...
Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:25 db kernel: [11209156.840469] wal-e cpuset=/ mems_allowed=0
Jun 10 05:45:25 db kernel: [11209156.840474] Pid: 7963, comm: wal-e Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:25 db kernel: [11209156.840477] Call Trace:
Jun 10 05:45:25 db kernel: [11209156.840498]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:25 db kernel: [11209156.840502]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:25 db kernel: [11209156.840506]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
Jun 10 05:45:25 db kernel: [11209156.840511]  [<ffffffff8111f823>] __alloc_pages_nodemask+0x8c3/0x8e0
Jun 10 05:45:25 db kernel: [11209156.840520]  [<ffffffff81216e00>] ? noalloc_get_block_write+0x30/0x30
Jun 10 05:45:25 db kernel: [11209156.840528]  [<ffffffff811566c6>] alloc_pages_current+0xb6/0x120
Jun 10 05:45:25 db kernel: [11209156.840534]  [<ffffffff81116637>] __page_cache_alloc+0xb7/0xd0
Jun 10 05:45:25 db kernel: [11209156.840539]  [<ffffffff81118602>] filemap_fault+0x212/0x3c0
Jun 10 05:45:25 db kernel: [11209156.840553]  [<ffffffff81138c32>] __do_fault+0x72/0x550
Jun 10 05:45:25 db kernel: [11209156.840557]  [<ffffffff8113c2ea>] handle_pte_fault+0xfa/0x200
Jun 10 05:45:25 db kernel: [11209156.840562]  [<ffffffff8100638e>] ? xen_pmd_val+0xe/0x10
Jun 10 05:45:25 db kernel: [11209156.840567]  [<ffffffff81005309>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Jun 10 05:45:25 db kernel: [11209156.840571]  [<ffffffff8113d559>] handle_mm_fault+0x269/0x370
Jun 10 05:45:25 db kernel: [11209156.840576]  [<ffffffff8100a56d>] ? xen_force_evtchn_callback+0xd/0x10
Jun 10 05:45:25 db kernel: [11209156.840581]  [<ffffffff8100ad42>] ? check_events+0x12/0x20
Jun 10 05:45:25 db kernel: [11209156.840589]  [<ffffffff8165b3cb>] do_page_fault+0x14b/0x520
Jun 10 05:45:25 db kernel: [11209156.840594]  [<ffffffff81160d64>] ? kmem_cache_free+0x104/0x110
Jun 10 05:45:25 db kernel: [11209156.840600]  [<ffffffff811ba2c8>] ? ep_remove+0xa8/0xc0
Jun 10 05:45:25 db kernel: [11209156.840604]  [<ffffffff811bb133>] ? sys_epoll_ctl+0xb3/0x3d0
Jun 10 05:45:25 db kernel: [11209156.840614]  [<ffffffff81658035>] page_fault+0x25/0x30
Jun 10 05:45:25 db kernel: [11209156.840617] Mem-Info:
Jun 10 05:45:25 db kernel: [11209156.840618] Node 0 DMA per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840622] CPU    0: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840624] CPU    1: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840627] CPU    2: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840629] CPU    3: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840631] Node 0 DMA32 per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840634] CPU    0: hi:  186, btch:  31 usd:  30
Jun 10 05:45:25 db kernel: [11209156.840637] CPU    1: hi:  186, btch:  31 usd:  47
Jun 10 05:45:25 db kernel: [11209156.840639] CPU    2: hi:  186, btch:  31 usd:  15
Jun 10 05:45:25 db kernel: [11209156.840641] CPU    3: hi:  186, btch:  31 usd:   2
Jun 10 05:45:25 db kernel: [11209156.840643] Node 0 Normal per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840646] CPU    0: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840648] CPU    1: hi:  186, btch:  31 usd:  14
Jun 10 05:45:25 db kernel: [11209156.840650] CPU    2: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840653] CPU    3: hi:  186, btch:  31 usd:   1
Jun 10 05:45:25 db kernel: [11209156.840658] active_anon:3616567 inactive_anon:4798 isolated_anon:0
Jun 10 05:45:25 db kernel: [11209156.840660]  active_file:98 inactive_file:168 isolated_file:20
Jun 10 05:45:25 db kernel: [11209156.840661]  unevictable:1597 dirty:73 writeback:0 unstable:0
Jun 10 05:45:25 db kernel: [11209156.840662]  free:16921 slab_reclaimable:17631 slab_unreclaimable:7534
Jun 10 05:45:25 db kernel: [11209156.840663]  mapped:1614529 shmem:1613928 pagetables:124012 bounce:0
Jun 10 05:45:25 db kernel: [11209156.840666] Node 0 DMA free:7888kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:7632kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840681] lowmem_reserve[]: 0 4016 15112 15112
Jun 10 05:45:25 db kernel: [11209156.840686] Node 0 DMA32 free:48368kB min:4176kB low:5220kB high:6264kB active_anon:3776804kB inactive_anon:28kB active_file:0kB inactive_file:20kB unevictable:932kB isolated(anon):0kB isolated(file):0kB present:4112640kB mlocked:932kB dirty:0kB writeback:0kB mapped:1458536kB shmem:1458632kB slab_reclaimable:17604kB slab_unreclaimable:8088kB kernel_stack:1872kB pagetables:190616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:437 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840698] lowmem_reserve[]: 0 0 11095 11095
Jun 10 05:45:25 db kernel: [11209156.840703] Node 0 Normal free:11428kB min:11548kB low:14432kB high:17320kB active_anon:10689464kB inactive_anon:19164kB active_file:528kB inactive_file:652kB unevictable:5456kB isolated(anon):0kB isolated(file):80kB present:11362176kB mlocked:5456kB dirty:292kB writeback:0kB mapped:4999580kB shmem:4997080kB slab_reclaimable:52920kB slab_unreclaimable:22048kB kernel_stack:2584kB pagetables:305432kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1974 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840715] lowmem_reserve[]: 0 0 0 0
Jun 10 05:45:25 db kernel: [11209156.840720] Node 0 DMA: 2*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 0*4096kB = 7888kB
Jun 10 05:45:25 db kernel: [11209156.840752] Node 0 DMA32: 5813*4kB 2636*8kB 114*16kB 15*32kB 5*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 48372kB
Jun 10 05:45:25 db kernel: [11209156.840776] Node 0 Normal: 1888*4kB 10*8kB 46*16kB 4*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 11760kB
Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages
Jun 10 05:45:25 db kernel: [11209156.840790] 0 pages in swap cache
Jun 10 05:45:25 db kernel: [11209156.840801] Swap cache stats: add 0, delete 0, find 0/0
Jun 10 05:45:25 db kernel: [11209156.840803] Free swap  = 0kB
Jun 10 05:45:25 db kernel: [11209156.840805] Total swap = 0kB
Jun 10 05:45:25 db kernel: [11209156.909794] 3934192 pages RAM
Jun 10 05:45:25 db kernel: [11209156.909804] 99282 pages reserved
Jun 10 05:45:25 db kernel: [11209156.909809] 18899146 pages shared
Jun 10 05:45:25 db kernel: [11209156.909811] 2198511 pages non-shared
Jun 10 05:45:25 db kernel: [11209156.909817] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
Jun 10 05:45:25 db kernel: [11209156.909835] [  332]     0   332     4308      109   1       0             0 upstart-udev-br
Jun 10 05:45:25 db kernel: [11209156.909845] [  346]     0   346     5384      271   2     -17         -1000 udevd
Jun 10 05:45:25 db kernel: [11209156.909851] [  408]     0   408     5364      174   2     -17         -1000 udevd
...
Jun 10 05:45:25 db kernel: [11209156.910703] [ 7963]   111  7963    17456     2966   0       0             0 wal-e
Jun 10 05:45:25 db kernel: [11209156.910707] [ 7968]   111  7968  1639372     2351   3       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910711] [ 7969]   111  7969  1639371     1934   2       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910716] Out of memory: Kill process 12443 (postgres) score 418 or sacrifice child
Jun 10 05:45:25 db kernel: [11209156.910733] Killed process 12443 (postgres) total-vm:6555152kB, anon-rss:4600kB, file-rss:6396572kB
Jun 10 05:45:30 db kernel: [11209159.293083] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:31 db kernel: [11209159.293091] postgres cpuset=/ mems_allowed=0
Jun 10 05:45:31 db kernel: [11209159.293095] Pid: 6508, comm: postgres Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:31 db kernel: [11209159.293098] Call Trace:
Jun 10 05:45:31 db kernel: [11209159.293111]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:31 db kernel: [11209159.293115]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:31 db kernel: [11209159.293119]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
...

우리는 이것들의 해상도를 초당 약 한 번 정도 증가시킬 수 있지만 여기서 OOM에 대한 이유가 있습니까? (우리는 http://bl0rg.krunch.be/oom-frag.html을 보았지만 훨씬 더 큰 절대 메모리 양으로 작업하고 있으며, 대부분은 커널의 FS 캐시에서 사용됩니다.)

postgresql.conf아래 의 관련 부분도 포함 합니다.

shared_buffers = 6GB
effective_cache_size = 8GB

postgresql oom

— 양
소스

관련 채팅 토론

— Yang

음 ... 3.2.0-43? 업데이트 시간. OOM 킬러는 시간이 지남에 따라 (너무 많은) 변화를 겪었습니다. 일부 버전은 PostgreSQL 9.2 및 그 이전 버전과 같은 공유 메모리 사용을 고려하는 데있어 상당히 죽었습니다 shared_buffers.

— Craig Ringer 2018 년

@CraigRinger 불행히도 LTS, 호환성, 보안 업데이트 등에 대한 Ubuntu 12.04 배포판의 커널 고정과 같은 다른 고려 사항이 있습니다. 여기에서 발생하는 상황을 설명하는 방법을 알고 있다면 관심이 있습니다. 현상 유지 / 문제 해결에 관심이 없습니다. BTW shared_buffers는 여전히 PG9.3입니다.

— 양

예 shared_buffers는 여전히 9.3에 있지만 더 이상 9.3의 POSIX 공유 메모리 가 아닙니다 . 익명의 mmap()ed지역 으로 대체되었습니다 . 그것은 엉뚱한 커널 구성 문제와 고정 문제를 해결하지만 OOM 킬러를 덜 혼란스럽게 만들지 않을 것입니다.

— Craig Ringer 2016 년

아마도 serverfault.com/questions/288319/… 의 복제본 일 가능성이 있습니다.

— richvdh

답변:

당신 (그리고 매우 비슷한 증상이있는 경우)에 실제로 메모리가 부족하고 cached숫자에 의해 혼란스러워 보입니다 .

메모리 요구가 증가 할 때 Linux가 큰 디스크 캐시를 해제하지 않는 경우 가 있습니다.

특히 (왜 그런지 잘 모르겠습니다) postgres shared_buffers는 "Cached"(페이지 캐시)에보고 될 수 있습니다. 귀하의 경우에는 6481852k cached인은 top움 킬러의 로그에서이 라인을 일치 :

Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages

(1615243 * 4KB ~ = 6481852k)-OOM-killer를 호출하기 전에 페이지 캐시가 실제로 삭제되지 않았 음을 의미합니다.

그러나 파일 백업 페이지는 거의 없으며 ( active_file:98 inactive_file:168/ proc / meminfo의 Active (file) / Inactive (file) 과 유사 하다고 가정 ) 우리가 알고 사랑하는 폐기 가능한 페이지가 아닙니다.

https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ 의 포스트는 postgres를 종료하면 "캐시 된"크기가 줄어드는 세션의 예를 보여줍니다. shared_buffers( " 스크롤은 대부분 shared_buffers에 사용 되었기 때문에 디스크 캐시에서 나왔습니다." )-불행히도 postgres 버전이나 실험에 사용 된 커널을 나타내지는 않습니다.

PG 9.3에서 3.13.0-67 x86_64를 사용하고 있습니다. 9.3에서는 Sys V 공유 메모리 ( shmget) 사용을 익명으로 전환했습니다mmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() (9.4에서는 dynamic_shared_memory_type을 통해 구성 가능 ). 그러나 나는 단지 이들의 mmap ()가의 "캐시"에 표시 해야하는 이유에 왜 어떠한 설명을 찾을 수 없습니다 https://access.redhat.com/solutions/406773 에서 메모리 : 그 말한다 "캐시 pagecache (디스크 캐시 및 공유 메모리) "

가 있음을 감안할 때 공유 메모리의 많은 종류를 내가 모두 계몽과 혼동하고있어 ...

— 니콜라이
소스

몇 년 후, 이것은 훨씬 더 나은 대답입니다, 감사합니다. 왜 이것이 캐시 된 것으로 간주되는지에 대한 의문이 있지만 지금은 이것을 승인 된 것으로 표시하고 있습니다.

— Yang

세계의 모든 것을 좋아하려면 서버에서 스왑 공간을 구성하십시오 .
당신은 정말 스왑 공간이 필요합니다 . 나는 그렇게 말하는 유일한 사람이 아닙니다 , 그것은 여기에 거의 보편적 인 진실 입니다. (<-이것들은 세 개의 링크입니다)
물론 돈이 아닌 경우 데이터베이스 서버 가 정기적으로 교환하지 않을 만큼 충분한 RAM이 있어야합니다. .
이제 충분한 RAM이 있고 문제가 발생하면 사용할 수 있도록 스왑하기 때문에 Postgres 직원이 지시 한대로 메모리 오버 커밋을 비활성화하여 OOM 킬러를 비활성화 할 수 있습니다.
(대체 솔루션을 적용하고 OOM-Killer에 Postgres를 절대로 죽이지 말라고 지시 할 수는 있지만 나머지 시스템 프로세스와 함께 러시아어 룰렛을 재생하고 있습니다 ...)
(선택 사항) 대부분의 Linux 배포에서 기본 동작이 나쁜 이유와 잘못된 이유를 자세하게 설명하고 malloc () 동작 방식에 대한 POSIX 사양을 위반하는 서버 오류에 대한 답변을 작성하십시오 . 모든 사람이 그것에 대해 듣지 않을 때까지 반복하십시오.

또한 커널의 캐시 된 메모리는 postgres (또는 다른 응용 프로그램)에서 사용할 수 있습니다. 계산시 사용 가능한 / 사용 가능한 메모리로 고려해야합니다.

여기서 무슨 일이 일어나고 있는지 추측 해야하는 경우 복잡한 쿼리가 있다고 가정하고 Postgres는 RAM을 실행하도록 요청하고 "RAM이 없습니다"라고 말하지 않고 Linux가 Postgres에 " 넌 그것을 가질 수있어."
포스트 그레스 실제로하려고 그런 경우에 사용 이 있던 RAM을했다고 보여 주어 리눅스는하지 않습니다 실현 가질 움 킬러가 RAM을 확보하라고하고 충실하게 사용하여 프로그램을 죽인다 - (이 오버 커밋 있기 때문에)이 포스트 그레스을 약속 RAM을 가장 많은 메모리-데이터베이스 서버.

Postgres는 잘 설계된 프로그램입니다. 그것이 RAM을 가질 수 없다고 말하면 요청하는 RAM을 우아하게 처리합니다 (적은 작업을 수행하거나 사용자에게 메시지를 중단하여).

— voretaq7
소스

스왑에 대한 정교함에 감사드립니다. 그러나 이것이 왜 이런 일이 처음 발생하는지에 대한 내 질문에는 대답하지 않습니다 . 예, Linux가 기본적으로 초과 커밋하고 OOM이 RAM을 벗어날 때의 기본 전제를 이해합니다. 원래 질문에서 이것을 많이 언급 할 수있었습니다. 그러나 문제는 여전히 충분한 RAM이있을 때 왜 발생합니까 (대부분 FS 캐시에 앉아있는 것입니까)? OOM 킬러가 트리거되는 이유를 이해하는 한 OOM 킬러는 괜찮습니다.

— 양

링크를 검토 한 후 안타깝게도 근거 증거 나 구체적인 기술적 설명이없는 여러 주장이 있습니다. 스왑이 옵션이 아닌 많은 Linux 환경이 있습니다 (예 : 재사용 할 기존 로컬 스왑 파티션이없는 라이브 CD 이상을 보지 마십시오). 우리는 또한 우리 자신의 경험과 환경을 바탕으로 스왑을 활성화하는 데 관심이 없습니다. 오히려 OOM을 원할 것입니다. 원래 질문에 대한 답변을 부탁드립니다.

— 양

@ 양 나는 Postgres 용 서버를 구축하는 경우 Postgres 프로젝트의 권장 사항을 따르기를 원한다고 가정합니다. 내 대답은 그들이 당신에게 말한 것을하는 것입니다 (OOM 킬러를 차단하십시오). 누군가가 당신에게 다른 대답을 제공하고 있는지 확인하고 싶다면 분명히 그렇게 할 수는 있지만 다른 해결책을 제공하는 것은 불편합니다. 제 생각에 OOM 킬러는 나쁘고 잘못되었으며 POSIX를 위반합니다. 데스크탑 / worstation에서는 허용되지만 서버에서 비활성화하는 것은 IMO, 올바른 일입니다.

— voretaq7 7

스왑이있는 서버 에서이 상황을 가로 질러 가용 메모리 + 스왑을 포화시킨 후 커널이 "캐시 된"메모리를 회수하는 대신 OOM 킬러가 사용되었습니다. 나는 문제를 결코 해결하지 못했지만 @Yang의 원래 질문에 대해서는 대답하지 않았습니다.

— Patrick

스왑은 답이 아니며 나중에 문제가 발생합니다. RAM이 가득 차면 스왑이 필요하고 RAM + 스왑이 가득 차면 OOM Killer가 필요합니다. 스왑 양이 0이면 OOM Killer가 더 빨리 필요하지만 스왑이있는 OOM Killer는 피할 수 없습니다.

— Mikko Rantalainen