Kullanılabilir belleğe (önbellek) rağmen OOM


12

Hafızamızın neredeyse yarısının FS önbelleği için kullanılmasına rağmen OOM katili ile karşılaşıyoruz. Bellek istatistiklerini dakikada bir kez (en üstte bildirildiği gibi) kaydediyoruz, ancak çok fazla kullanılabilirlik var gibi görünüyor.

...

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'dan OOM ayrıntıları:

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

Bunların çözünürlüğünü kabaca saniyede bir artırmayı deneyebiliriz, ancak burada bir OOM için herhangi bir neden var mı? ( Http://bl0rg.krunch.be/oom-frag.html adresini gördük, ancak çoğunun çekirdeğin FS önbelleği tarafından alınan çok daha büyük mutlak bellek miktarıyla çalışıyoruz.)

postgresql.confAşağıdakilerin ilgili bölümlerini de içerir :

shared_buffers = 6GB
effective_cache_size = 8GB


Um ... 3.2.0-43? Güncelleme zamanı. OOM katili zamanla birçok (çok fazla) değişiklik geçirdi. Bazı sürümler, PostgreSQL 9.2 ve daha eski sürümlerde olduğu gibi, paylaşılan bellek kullanımını hesaba katma konusunda oldukça beyin ölmüştü shared_buffers.
Craig Ringer

@CraigRinger Ne yazık ki LTS için Ubuntu 12.04 dağıtımındaki çekirdeğe bağlı kalmak, uyumluluk, güvenlik güncellemeleri, vb. Gibi başka hususlar da var. statükoyu değiştirmek / problemi ortadan kaldırmakla ilgilenmiyor. BTW shared_buffershala PG9.3'te.
Yang

Evet shared_buffershala 9.3'te, ancak artık 9.3'te POSIX paylaşılan belleği değil . Anonim bir mmap()edbölge ile değiştirildi . Bu bazı çekirdek çekirdek yapılandırma sorunları ve sabitleme sorunları, ancak OOM katili daha az karışık hale getirecek şüpheliyim alır.
Craig Ringer

1
Muhtemelen olası bir cevabı olan bir serverfault.com/questions/288319/… kopyası .
richvdh

Yanıtlar:


4

Görünüşe göre (ve çok benzer semptomları olan bir vakada) gerçekten hafızamız bitti ve cachedsayı ile karıştırıldım .

Görünüşe göre, bellek talebi arttığında Linux büyük disk önbelleğini serbest bırakmıyor

Özellikle (gerçekten neden anlamıyorum), postgres ' shared_buffers"Önbellek" (sayfa önbelleği) altında rapor edilebilir. Senin durumunda 6481852k cachedyılında topOOM-Katilin günlüğüne bu satırı ile eşleşir:

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

(1615243 * 4KB ~ = 6481852k) - bu, sayfa önbelleğinin gerçekten OOM-katilini çağırmadan önce bırakılmadığı anlamına gelir.

Yine de birkaç dosya destekli sayfa var (sanırım active_file:98 inactive_file:168/ proc / meminfo'nun Aktif (dosya) / Aktif Değil (dosya) ), bu yüzden bildiğimiz ve sevdiğimiz anlaşılabilir sayfalar değil.

Https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ adresindeki yazı, postgres kapatmanın "önbelleğe alınmış" boyutuna göre küçültülmesine yol açtığı örnek bir oturum gösteriyor shared_buffers(kaydırın "Ve çoğu disk önbelleğinden çıktı - beklendiği gibi, shared_buffers için kullanıldığından." ) - maalesef postgres sürümünü veya deneme için kullanılan çekirdeği belirtmiyor.

PG 9.3 ile 3.13.0-67 x86_64 kullanıyorum. 9.3'te Sys V paylaşılan belleğini ( shmget) anonimmmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() hale getirdiler (9.4'te dynamic_shared_memory_type ile yapılandırılabilir hale geldi ). Ama sadece bu mmap () s "önbelleğe alınmış" gösterilmesini gerekiyordu neden ve niçin olarak herhangi bir açıklama bulamadık https://access.redhat.com/solutions/406773 Bellek: belirtiyor "Önbellek pagecache (Diskcache ve Paylaşılan Bellek) "

Hem paylaşılan hem de kafam karışan birçok çeşit bellek olduğu göz önüne alındığında ...


Birkaç yıl sonra, bu çok daha iyi bir cevap, teşekkürler. Bunun neden önbelleğe alınmış olarak açıklandığı sorusu hala var, ancak şimdilik kabul edildiğini işaretliyorum.
Yang

8
  1. Dünyadaki her şeyin sevgisi için sunucularınızda takas alanı yapılandırın .
    Gerçekten takas alanına ihtiyacınız var . Bunu söyleyen tek kişi ben değilim , burası neredeyse evrensel bir gerçek . (<- Bunlar üç bağlantı)
    Tabii ki veritabanı sunucunuzun düzenli olarak takas etmeyecek kadar RAM'e sahip olmalısınız - eğer çözüm yoksa para (tedarikçinizi alırsınız ve daha fazla RAM almak için kullanırsınız) .

  2. Artık yeterli RAM'iniz olduğundan ve bir şeyler ters giderse kullanmak için takas olduğundan , Postgres kullanıcılarının size söylediği gibi OOM katilini devre dışı bırakabilirsiniz (bellek fazla çalışmasını devre dışı bırakarak) .
    (Alternatif çözümlerini de uygulayabilir ve OOM-Killer'e Postgres'i asla öldürmemesini söyleyebilirsiniz - ancak daha sonra sisteminizin geri kalanıyla Rus Ruleti oynuyorsunuz ...)

  3. (isteğe bağlı) Çoğu Linux dağıtımındaki varsayılan davranışın neden Kötü, Yanlış olduğunu ve malloc () 'un nasıl davranması gerektiği konusunda POSIX belirtimini ihlal ettiğini belirten Sunucu Hatası üzerine bir yanıt yazın . Herkes bunu duymaktan bıkana kadar tekrarlayın.


Ayrıca çekirdeğin önbelleğe alınmış belleğinin postgres (veya başka bir uygulama) tarafından kullanılabileceğini unutmayın - hesaplamalarınızda boş / kullanılabilir bellek olarak değerlendirmelisiniz.

Burada neler olduğuna dair bir tahminde bulunmak zorunda kalsaydım, karmaşık bir sorgunuz olduğunu söyleyebilirim, Postgres bunu yürütmek için RAM'i istiyor ve "O RAM'im yok" demek yerine Postgres'e diyor. alabilirsin."
Postgres aslında çalışır Sonra zaman kullanmak öyleydi RAM (iddiaya göre) verilen Linux o olmadığını fark eder VAR OOM katil RAM boşaltmak için söylenir ve aldatılan kullanarak programı öldürür - (o overcommitted çünkü) o Postgres vaat RAM en fazla bellek - veritabanı sunucunuz.

Postgres iyi tasarlanmış bir programdır. RAM'e sahip olamayacağı söylendiğinde, istediği gibi bunu zarif bir şekilde ele alacaktır (daha azıyla yapmak veya kullanıcıya bir mesajla iptal etmek).


4
Takas konusundaki ayrıntılar için teşekkürler, ancak bu ilk etapta neden gerçekleştiği sorusuna cevap vermiyor . Evet, Linux'un varsayılan olarak fazla işlediği ve OOM'un RAM dışında olduğumuz zaman olduğu temel önermesini anlıyorum - orijinal sorumda bu kadarını ifade edebilirdim. Ama soru şu ki , hala yeterince RAM'im olduğunda (çoğu FS önbelleğinde oturuyor) neden tekme atıyor ? Hiçbir şeyi değiştirmekle ilgilenmediğimi varsayalım - neden tetiklendiğini anladığım kadarıyla OOM katili iyi.
Yang

2
Bağlantıları inceledikten sonra maalesef kanıtları veya somut teknik açıklamaları desteklemeyen bazı iddialar var. Kesinlikle takasın bir seçenek olmadığı birçok Linux ortamı vardır (örnek: zaten yeniden kullanılacak mevcut bir yerel takas bölümünün olmadığı bir Canlı CD'den başka bir yere bakmayın). Ayrıca kendi deneyimlerimize ve çevremize dayalı bir swappiness sağlamakla da ilgilenmiyoruz - OOM'ye sahip olmayı tercih ederiz. Orijinal soruya bir cevap takdir edilecektir.
Yang

1
@Yang Postgres için bir sunucu oluşturuyorsanız Postgres projesinin önerilerini takip etmek isteyeceğinizi varsayıyorum. Cevabım size söylediklerini yapmak (OOM katilini kapatın). Beklemek ve birisinin size farklı bir cevap sunup sunmadığını görmek istiyorsanız, bunu yapmakta kesinlikle özgürsünüz, ancak başka bir çözüm sunmaktan çekinmiyorum - Bence OOM katili Kötü, Yanlış ve POSIX'i ihlal ediyor. Bir masaüstü / worstation üzerinde kabul edilebilir, ancak sunucularda devre dışı bırakmak IMO, Yapılacak Doğru Şey.
voretaq7

2
Ben takas olan bir sunucu üzerinde bu durum boyunca çalıştım ve kullanılabilir bellek + takas doygunluk sonra açıkça bir şekilde kilitli olan "önbellek" bellek geri alma çekirdek yerine OOM katil kullanıldı. Sorunu hiç çözmedim, ama @ Yang'ın orijinal sorusu burada cevaplanmadı.
Patrick

2
Takas cevap değildir, sadece problemin daha sonra ortaya çıkmasını sağlar. RAM dolduğunda takas gerekir ve RAM + takas dolduğunda OOM Killer gerekir. Takas miktarı sıfırsa, OOM Killer'e daha erken ihtiyacınız olur, ancak takasla OOM Killer'den kaçınamazsınız.
Mikko Rantalainen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.