Linux OOM katilinin işlemimi öldürmemesi nasıl sağlanır?

Linux OOM katilinin fiziksel bellek az olduğunda ancak takas alanı varken süreçlerimi öldürmemesini nasıl sağlayabilirim?

OOM cinayetini devre dışı bıraktım ve sysctl vm.overcommit_memory = 2 ile aşırı görev yaptım.

Sanal Makinede 3 GB tamamen ücretsiz parçalanmamış takas vardır ve OOM'un öldürdüğü işlemler 200 MB'tan daha az maksimum bellek kullanır.

Uzun süreli takas işleminin performans için korkunç olacağını biliyorum, ancak bellek gereksinimlerinin çok daha büyük olduğu yerlerde geçerli olan sınamaları test etmek için şu anda kullanmam gerekiyor.

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

Bu / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

Bu iki faktörün kombinasyonunda sorun gibi görünüyor:

• Sanal bir makine kullanma.
• Muhtemel bir çekirdek böceği.

Bu kısmen bunun neden olduğunu açıklayan satırlardan biridir:

7 Mart 02:43:11 myhost çekirdeği: memcheck-amd64- oom-killer'ı çağırdı: gfp_mask = 0x24002c2, sipariş = 0, oom_score_adj = 0

Diğer satır şudur:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

Üste Geri Bildirim Ver Neden İlk satır, ayırma için atanan GFP maskesidir. Temel olarak, bu talebi yerine getirmek için çekirdeğin neye izin verildiğini / izin verilmeyeceğini açıklar. Maske bir grup standart bayrağı gösterir. Son bit, '2' ise bellek tahsisinin HighMembölgeden gelmesi gerektiğini gösterir .

OOM çıkışına yakından bakarsanız, HighMem/Normalgerçekte bölge olmadığını göreceksiniz .

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem(genel olarak Normalx86_64'te de denir ), standart 896MiB aralığının dışındaki bölgeler için 32 bit sistemlerde doğrudan erişilebilen çekirdeği alanlarını haritalama eğilimindedir. X86_64 üzerinde HighMem/Normalboyutunda 3GiB üzerindeki tüm sayfaları kapsayacak şekilde görünüyor.

DMA3232 bit DMA aygıtlarında erişilebilecek bellek için kullanılan bir bölge içerir; bu, 4 baytlık işaretçilerle bunları adresleyebilirsiniz. DMA16 bitlik DMA cihazları için olduğuna inanıyorum .

Genel olarak konuşursak, zaten mevcut tüm sanal adresleri kapsayan Normalverilen düşük bellek sistemlerinde mevcut olmaz DMA32.

OOM'u öldürmenizin sebebi HighMem, 0 sayfalık bir bölge için bir hafıza tahsisi olmasıdır . Bellek yetersizliği işleyicisinin, bu bölgeyi değiştirerek, başka işlemleri veya başka bir numarayla öldürerek kullanabileceği sayfalara sahip olmasını sağlamanın kesinlikle bir yolu olmadığı göz önüne alındığında, OOM-katil onu öldürür.

Bunun ana bilgisayardaki VM'in açılışta patlamasına neden olduğuna inanıyorum. KVM sistemlerinde ayarlayabileceğiniz iki değer vardır.

• Geçerli hafıza
• Mevcut hafıza.

Bunun işe yarayacağı yol, sunucunuza bellekte kullanılabilir belleğe kadar sıcak ekleyebilmenizdir. Bununla birlikte, sisteminize aslında mevcut bellek verilir.

Bir KVM VM başlatıldığında, verilmesi mümkün olan maksimum bellek dağılımı (mevcut bellek) ile başlar. Sistemin önyükleme aşaması boyunca KVM yavaş yavaş bu balonu kullanarak balonları kullanarak geri çeker, bunun yerine sahip olduğunuz mevcut bellek ayarıyla sizi bırakır.

Benim inancım, burada olanlar. Linode, belleği başlatarak sistem başlangıcında size daha fazlasını vermenizi sağlar.

Bu Normal/HighMem, sistem ömrünün başında bir bölge olduğu anlamına gelir . Hiper yönetici onu havaya uçurduğunda normal bölge haklı olarak bellek yöneticisinden kaybolur. Ama bölge olduğu gelen ayırmaya müsait olup olmadığının bayrak ayarı şüpheli değil ne zaman olması gerektiği temizlenir. Bu, çekirdeğin var olmayan bir bölgeden tahsis etmeye çalışmasına neden olur.

Bunu çözmek için iki seçeneğiniz var.

1. Bunun gerçekten bir hata mı, beklenen bir davranış mı yoksa söylediklerimle bir ilgisi olup olmadığını görmek için bunu çekirdek posta listelerine getirin.

2. Bu linode'un sistemdeki 'kullanılabilir belleği' 'mevcut bellek' ile aynı 1GiB ataması olarak ayarlamasını isteyin. Böylelikle sistem hiçbir zaman havaya uçmaz ve önyüklemede Normal bir bölge olmaz, bayrağını temiz tutar. Onları bunu yapma konusunda iyi şanslar!

Bu durumun, kendi VM'nizi 6GiB'ye kadar mevcut olan KVM ayarında ayarlayarak, 1GiB'ye kadar akım ayarlayarak ve yukarıda gördüğünüz davranışın olup olmadığını görmek için aynı çekirdeği kullanarak testinizi çalıştırarak test edebilmelisiniz. Varsa, 'mevcut' ayarını 1GiB akıma eşit olacak şekilde değiştirin ve testi tekrarlayın.

Burada bir sürü eğitimli tahminler yapıyorum ve bu cevabı bulmak için satırlar arasında biraz okuma yapıyorum, ancak söylediklerim daha önce belirtilen gerçeklere uyacak gibi görünüyor.

Hipotezimi test etmeyi ve sonuçların hepimize bildirilmesini öneririm.

Kullanabilmesisi başlık soruya cevap vermek için oom_score_adj(çekirdek> = 2.6.36) veya önceki çekirdekler (> = 2.6.11) için oom_adj, erkek bakınız proc

/ proc / [pid] / oom_score_adj (Linux 2.6.36’dan beri) Bu dosya, bellek dışı koşullarda hangi sürecin öleceğini seçmek için kullanılan kötülük sezgiselini ayarlamak için kullanılabilir ...

/ proc / [pid] / oom_adj (Linux 2.6.11’den beri) Bu dosya, yetersiz bellek (OOM) durumunda hangi sürecin ölmesi gerektiğini seçmek için kullanılan puanı ayarlamak için kullanılabilir ...

Okuyacak daha çok şey var, ancak oom_score_adj - -1000 veya oom_adj - -17 olarak ayarlanması istediğiniz şeyi başaracak.

Sorun, başka bir şeyin öldürülecek olmasıdır. Belki de OOM'in neden çağrıldığını belirlemek ve bununla ilgilenmek daha iyi olacaktır.

Bazı düşünceler (yukarıdaki yorumlardan) ve interresting ile ilgili bağlantılar durumunuzla ilgili okuyor:

• 1) mevcut çekirdeğiniz ve config (& cpu) ile 3Gb'den daha fazla adres alabileceğinizi kontrol etmenizi tavsiye ederim. 2) takas yapmanıza izin veriyorsanız ve takas alt sistemi yerinde ve çalışıyor. iyi şanslar (Ayarlarınıza ve özelliklere bağlı olarak nasıl açıklayacağım. Arama motorları yardımcı olacaktır). VE bir çekirdek masasını taşmadığınızı (nb of pids? Veya başka bir şey (bazıları çekirdek derleme zamanında ayarlanabilir).

• Her şeyin (donanım veya vm'nin simülasyonlu donanımı vb.) 64 bit olduğunu kontrol edin. (bakınız örneğin: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Cpu ve ana bilgisayar işletim sistemi & vm alt sistemi ve vm işletim sistemi 64 bit etkin olmalıdır, aksi takdirde gerçek bir 64 bit vm olmaz

• Bazı iyi okur:

  • Oom-katil öldürme işlemlerinin nedenleri nasıl teşhis edilir : Güzel bir bağlantı verir: http://linux-mm.org/OOM_Killer ve başka bir kullanıcı ne olduğunu teşhis etmeye yardımcı olabilecek atop aracını tanıtır
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12, OOM için karar ağacını gösterir (daha eski bir versiyonun, yani ymmv.
  • https://lwn.net/Articles/317814/ : "OOM katilinin evcilleştirilmesi", diğerlerinin yanı sıra "yenilmez" bir grup oluşturmanın ve sürecine nasıl katıldığın gösteriyor
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : bazı genel çekirdek limitlerini gösterir
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : gerçekten tarihli olmasına rağmen iyi bir okumadır (bazı ayırma yöntemleriyle israf edilen boş alan). bit mimarileri ...)
  • http://bl0rg.krunch.be/oom-frag.html , "OOM katili hala yeterli miktarda bellek varken bile çağırılabilir" nedenlerini gösteriyor
  • https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : sisteminizin belleği nasıl ayırdığını kontrol etmenin bir yolunu sunar
  • https://serverfault.com/a/724518/146493 : gerçekten ne olduğunu bilmek için ayrıntılı bir yol gösteren mükemmel cevap (ama ... 32-bit bir soruyu hedef aldı, bu yüzden ymmv. Yine de inanılmaz bir okuma ve cevap).

• ve son olarak: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html , prosesinizin oom katili tarafından hedef alınmasını önlemenin bir yolunu gösterir! ( echo -17 > /proc/PROCESSPID/oom_adj). Değişikliklere eğilimli olabilir ve kötü bir şey olabilir (sistem artık ana suçluyu basitçe öldüremediğinden başka türden arızalara neden olabilir ...) Dikkatli kullanın. @iain, "oom_adj" nin daha yaşlı çekirdekler için olduğunu ve yenilerde "oom_score_adj" ile değiştirilmesi gerektiğini not edin. Teşekkürler, Iain)

oom_score_adjBununla birlikte, söz konusu sürecin artmasıyla birlikte (ki bu muhtemelen pek de yardımcı olmayacaktır - bu sürecin İLK öldürülme olasılığını azaltacaktır, ancak bu sadece hafızada yoğun olan işlem sistemi muhtemelen sonuçlanana kadar iyileşmeyecektir. öldürüldü), işte titremek için birkaç fikir:

• Ayarladıysanız vm.overcommit_memory=2, vm.overcommit_ratiobelki 90'a da çimdik (alternatif olarak, ayarla vm.overcommit_memory=0- çekirdek overcommit belgelerine bakın )
• vm.min_free_kbytesher zaman bazı fiziksel RAM'leri serbest tutmak ve dolayısıyla OOM'un bir şeyi öldürme ihtiyacı olasılığını azaltmak için artar (ancak anında OOM olacağı için aşırıya kaçmayın).
• artırmak vm.swappiness(yapmak için 100 daha kolay bir şekilde çekirdek takası )

Eldeki görevi gerçekleştirmek için çok az belleğiniz varsa, OOM olmasanız bile, son derece yavaş olabileceğine (veya olmayabilir), yarım saatlik bir işin (yeterli RAM'li sistemde) kolayca birkaç hafta sürebileceğini unutmayın. RAM takas ile değiştirilirse) aşırı durumlarda tamamlamak veya tüm VM'yi asmak için. Bu, özellikle takas, üzerinde çok pahalı olan devasa rastgele okuma / yazmalardan dolayı (SSD'lerin aksine) klasik dönme disklerinde olması durumunda geçerlidir.

Fazla ödemeyi etkinleştirmeye ve bunun yardımcı olup olmadığını görmeye çalışırım. İşleminiz fork, ilk işlemde olduğu kadar sanal bellek gerektiren bir aramada başarısız görünüyor . overcommit_memory=2Prosesinizi OOM katiline karşı bağışıklık kazanmaz, sadece çok fazla tahsis ederek prosesinizin tetiklemesini önler. Diğer işlemler, hala OOM katilini tetikleyen ve işleminizi elden çıkaran alakasız tahsis hataları (örneğin, bitişik bir bellek bloğunun alınması) üretebilir.

Alternatif olarak (ve konuya daha fazlası), bazı yorumların önerdiği gibi, daha fazla RAM satın alın.

Kısa hikaye - Farklı bir çekirdek sürümünü deneyin. 4.2.0-x ve 4.4.0-x çekirdekleri ile OOM hataları gösteren, ancak 3.19.0-x ile olmayan bir sistemim var.

Uzun hikaye: (çok uzun değil!) Burada hala hizmette olan bir Compaq DC5000'im var - şu anda 512 MB RAM (ve bunun bir kısmı, 32-128 MB gibi, yerleşik videoya veriliyor ..) NFS, bağlı bir monitörüm var, bu yüzden ara sıra oturum açacağım (Ubuntu Classic, Unity.)

Ubuntu HWE aracılığıyla bir süredir 3.19.x çekirdeği çalıştırıyordum; 200-300 MB'lık bir şey gibi sonuçlanacaktı, ama görünüşe göre kullanılmayan şeylerdi, söyleyebileceğim kadarıyla değiştirmesi gereken herhangi bir takas faaliyeti olmazdı.

4.2.0-x çekirdeği ve şimdi 4.4.0-x çekirdeği, takas içine sadece 220MB (yani 1.3GB ücretsiz) yazmak için tıknaz bir NFS yazmaya başlayabilirim (ve 1.3GB ücretsiz) ve OOM'u öldürmeye başlayacaktır. Çekirdek hatası mı yoksa "ayarlama sorunu" mu olduğunu iddia etmeyeceğim (normalde iyi olan 64 MB'lık bir yedek gibi, ancak ~ 400MB veya daha yüksek bir sistemde çok yüksek?)

Takas kullanmayı umduğundan dolayı bir şekilde kırıldığını söyleyenlere saygısızlık etmek yok; tüm saygımla yanılıyorsun. Hızlı olmayacak, ancak birkaç 512MB-1GB sistemdeki takas yerine 1 veya 2GB kullandım. Elbette bazı yazılım mlock'ları bir grup RAM'dir, fakat benim durumumda (aynı yazılımı sadece farklı bir çekirdekte çalıştırdığımdan beri) durum açıkça böyle değil.