OOM trotz verfügbarem Speicher (Cache)

12

Wir sind auf den OOM-Killer gestoßen, obwohl fast die Hälfte unseres Speichers für den FS-Cache verwendet wurde. Wir haben einmal pro Minute Speicherstatistiken aufgezeichnet (wie oben angegeben), aber es scheint genügend Verfügbarkeit zu geben.

...

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

...

OOM-Details aus Syslog:

...
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
...

Wir können versuchen, die Auflösung auf ungefähr einmal pro Sekunde zu erhöhen, aber gibt es hier einen Grund für eine OOM? (Wir haben http://bl0rg.krunch.be/oom-frag.html gesehen, aber wir arbeiten mit viel größeren absoluten Speichermengen, von denen die meisten vom FS-Cache des Kernels belegt werden.)

Auch einschlägige Teile unserer postgresql.confunten:

shared_buffers = 6GB
effective_cache_size = 8GB
postgresql oom Yang
quelle
2
Weitere Chat-Diskussion
Yang
Ähm ... 3.2.0-43? Updatezeit. Der OOM-Killer hat im Laufe der Zeit viele (zu viele) Veränderungen durchgemacht. Einige Versionen waren wirklich ziemlich verrückt nach der Verwendung von Shared Memory ... wie PostgreSQL 9.2 und älter shared_buffers.
Craig Ringer
@CraigRinger Leider gibt es noch andere Überlegungen, darunter das Festhalten am Kernel in der Ubuntu 12.04-Distribution für LTS, Kompatibilität, Sicherheitsupdates usw. Wir sind nur interessiert, wenn jemand weiß, was hier passiert - wenn es hilft, tun wir so Ich bin nicht daran interessiert, den Status Quo zu ändern oder das Problem zu lösen. BTW shared_buffersist noch in PG9.3.
Yang
Ja shared_buffersist immer noch in 9.3, aber es ist nicht mehr POSIX Shared Memory in 9.3. Es wurde durch eine anonyme mmap()edRegion ersetzt. Das umgeht einige icky Kernel-Konfigurationsprobleme und Pinning-Probleme, obwohl ich bezweifle, dass der OOM-Killer dadurch weniger verwirrt wird.
Craig Ringer
1
Möglicherweise ein Duplikat von serverfault.com/questions/288319/… , das möglicherweise eine Antwort enthält.
Richvdh

Antworten:

3

Es sieht so aus, als ob Ihnen (und mir in einem Fall mit sehr ähnlichen Symptomen) das Gedächtnis ausgeht und Sie durch die cachedZahl verwirrt wurden .

Es scheint Fälle zu geben, in denen Linux den Cache für große Festplatten nicht freigibt, wenn der Speicherbedarf steigt

Insbesondere (ich verstehe nicht wirklich, warum), kann postgres shared_buffersunter "Cached" (der Seiten-Cache) gemeldet werden. In Ihrem Fall stimmt das 6481852k cachedin topmit dieser Zeile im Protokoll des OOM-Killers überein:

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

(1615243 * 4KB ~ = 6481852k) - Dies bedeutet, dass der Seiten-Cache tatsächlich nicht gelöscht wurde, bevor OOM-Killer aufgerufen wurde.

Es gibt jedoch nur wenige dateibasierte Seiten (ich active_file:98 inactive_file:168gehe davon aus , dass sie mit / proc / meminfo Active (Datei) / Inactive (Datei) vergleichbar sind ), daher handelt es sich nicht um die wegwerfbaren Seiten, die wir kennen und lieben.

Der Beitrag unter https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ zeigt eine Beispielsitzung, in der das Herunterfahren von postgres zu einer Verringerung des "zwischengespeicherten" Werts um die Größe von führt shared_buffers(Scrollen Sie zu "Und das meiste wurde vom Festplatten-Cache gelöscht - wie erwartet, weil es für shared_buffers verwendet wurde." ) - Leider gibt es weder die Version von postgres noch den Kernel an, der für das Experiment verwendet wurde.

Ich verwende 3.13.0-67 x86_64 mit PG 9.3. In 9.3 wurde von Sys V Shared Memory ( shmget) auf anonym mmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork()umgestellt (in 9.4 wurde dies über dynamic_shared_memory_type konfigurierbar ). Ich konnte jedoch keine Erklärung finden, warum diese mmap () im "Cache" angezeigt werden sollen, und warum nur https://access.redhat.com/solutions/406773 , in dem "Cached: Memory in the" steht pagecache (Diskcache und Shared Memory) "

Angesichts der Tatsache, dass es viele Arten von Shared Memory gibt, bin ich sowohl aufgeklärt als auch verwirrt ...

Nickolay
quelle
Nach einigen Jahren ist dies eine viel bessere Antwort, danke. Es gibt immer noch die Frage, warum dies als zwischengespeichert eingestuft wird, aber ich stelle fest, dass dies vorerst akzeptiert wird.
Yang
8

  1. Konfigurieren Sie aus Liebe zu allem Guten auf der Welt den Auslagerungsspeicher auf Ihren Servern .
    Sie brauchen wirklich Swap Space . Ich bin nicht der Einzige, der das sagt , es ist so ziemlich eine universelle Wahrheit hier . (<- Das sind drei Links)
    Sie sollten natürlich über genügend RAM verfügen, damit Ihr Datenbankserver nicht regelmäßig austauscht. Andernfalls erhalten Sie als Lösung Geld (mit dem Sie Ihren Lieferanten beauftragen und mehr RAM erwerben). .

  2. Da Sie nun über ausreichend Arbeitsspeicher verfügen und den Arbeitsspeicher austauschen können, können Sie den OOM-Killer deaktivieren (indem Sie die Speicherüberlastung deaktivieren), wie es Ihnen die Postgres-Mitarbeiter empfehlen .
    (Sie können auch ihre alternative Lösung anwenden und den OOM-Killer anweisen, niemals Postgres zu töten - aber dann spielen Sie nur russisches Roulette mit den restlichen Prozessen Ihres Systems ...)

  3. (Optional) Schreiben Sie eine Antwort zu Server-Fehler, in der erläutert wird, warum das Standardverhalten in den meisten Linux-Distributionen "Schlecht" oder "Falsch" ist und gegen die POSIX-Spezifikation für das Verhalten von malloc () verstößt . Wiederholen Sie dies, bis alle es satt haben, davon zu hören.

Beachten Sie auch, dass der zwischengespeicherte Speicher des Kernels für Postgres (oder jede andere Anwendung) verfügbar ist. Sie sollten ihn in Ihren Berechnungen als freien / verfügbaren Speicher berücksichtigen.

Wenn ich eine Vermutung anstellen müsste, was hier passiert, würde ich sagen, dass Sie eine komplexe Abfrage haben. Postgres fordert RAM zur Ausführung auf und sagt nicht "Ich habe diesen RAM nicht". Linux sagt Postgres "Sicher, du kannst es haben."
Dann , wenn Postgres tatsächlich versucht , zu verwenden , das RAM war es (angeblich) gegeben Linux erkennt es nicht HAVE den RAM es Postgres versprochen (weil es überbelegt ist) - der OOM Killer gesagt wird , um den RAM zu befreien, und pflichtschuldigst tötet das Programm mit der meiste Speicher - Ihr Datenbankserver.

Postgres ist ein gut gestaltetes Programm. Wenn festgestellt wird, dass der angeforderte Arbeitsspeicher nicht verfügbar ist, wird dies ordnungsgemäß verarbeitet (entweder, indem er mit weniger auskommt, oder indem er mit einer Nachricht an den Benutzer abgebrochen wird).

voretaq7
quelle
4
Vielen Dank für die Ausarbeitung von Swap, aber dies beantwortet nicht meine Frage, warum dies überhaupt geschieht . Ja, ich verstehe die Grundvoraussetzung, dass Linux standardmäßig zu viele Commits ausführt, und dass OOM ist, wenn kein RAM mehr vorhanden ist - das hätte ich in meiner ursprünglichen Frage sagen können. Aber die Frage ist, warum es sich einschaltet, wenn ich noch genügend RAM habe (viel davon sitzt nur im FS-Cache)? Angenommen, ich bin nicht einmal daran interessiert, irgendetwas zu ändern - dass der OOM-Killer in Ordnung ist, solange ich verstehe, warum er ausgelöst wird.
Yang
2
Nach Überprüfung der Links gibt es leider eine Reihe von Behauptungen ohne Belege oder konkrete technische Erklärungen. Es gibt sicherlich viele Linux-Umgebungen, in denen Swap nicht einmal eine Option ist (Beispiel: Suchen Sie nicht weiter als nach einer Live-CD, auf der es noch keine lokale Swap-Partition gibt, die wiederverwendet werden kann). Wir sind darüber hinaus nicht daran interessiert, aufgrund unserer eigenen Erfahrungen und unseres Umfelds ein Tauschgeschäft zu ermöglichen - wir hätten lieber das OOM. Eine Antwort auf die ursprüngliche Frage wäre willkommen.
Yang
1
@ Yang Ich gehe davon aus, dass Sie, wenn Sie einen Server für Postgres erstellen, den Empfehlungen des Postgres-Projekts folgen möchten. Meine Antwort lautet: Tu, was sie dir sagen (schalte den OOM-Killer aus). Wenn Sie abwarten möchten, ob Ihnen jemand eine andere Antwort bietet, können Sie dies auf jeden Fall tun, aber ich kann Ihnen keine andere Lösung anbieten. Meiner Meinung nach ist der OOM-Killer schlecht, falsch und verstößt gegen POSIX. Auf einem Desktop / einer Arbeitsstation mag dies akzeptabel sein, aber das Deaktivieren auf Servern ist laut IMO das Richtige.
Voretaq7
2
Ich bin auf einem Server mit Swap auf diese Situation gestoßen, und nachdem der verfügbare Speicher + Swap ausgelastet war, wurde der OOM-Killer anstelle des Kernels verwendet, der den "zwischengespeicherten" Speicher zurückfordert, der offensichtlich irgendwie gesperrt war. Ich habe das Problem nie gelöst, aber die ursprüngliche Frage von @ Yang wird hier nicht beantwortet.
Patrick
2
Swap ist nicht die Antwort, es lässt das Problem erst später auftauchen. Sie brauchen Swap, wenn der RAM voll ist und Sie brauchen OOM Killer, wenn RAM + Swap voll ist. Wenn die Menge an Swap gleich Null ist, brauchen Sie OOM Killer früher, aber Sie können OOM Killer mit Swap nicht vermeiden.
Mikko Rantalainen