Jak sprawić, by zabójca Linux OOM nie zabił mojego procesu?

Jak sprawić, by zabójca Linux OOM nie zabijał moich procesów, gdy pamięć fizyczna jest niska, ale jest dużo przestrzeni wymiany?

Wyłączyłem zabijanie OOM i przesadziłem z sysctl vm.overcommit_memory = 2.

Maszyna wirtualna ma 3 GB całkowicie darmowej niefragmentowanej wymiany, a procesy, które są zabijane przez OOM, mają maksymalne wykorzystanie pamięci poniżej 200 MB.

Wiem, że długoterminowa zamiana będzie straszna z punktu widzenia wydajności, ale muszę teraz użyć tej wymiany, aby przeprowadzić testy funkcjonalne w valgrind, gdzie wymagania dotyczące pamięci są znacznie większe.

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

To jest / 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

Wydaje się to być problemem w połączeniu z dwoma czynnikami:

• Korzystanie z maszyny wirtualnej.
• Możliwy błąd jądra.

Jest to częściowo jedna z linii, która opisuje, dlaczego tak się dzieje:

7 marca 02:43:11 jądro myhost: memcheck-amd64- wywołane oom-killer: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

Druga linia to:

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

| Pierwszy wiersz to maska ​​GFP przypisana do alokacji. Zasadniczo opisuje, co jądro jest dozwolone / nie może zrobić, aby zaspokoić to żądanie. Maska wskazuje kilka standardowych flag. Ostatni bit „2” wskazuje jednak, że przydział pamięci powinien pochodzić ze HighMemstrefy.

Jeśli przyjrzysz się uważnie wynikowi OOM, zobaczysz, że żadna HighMem/Normalstrefa faktycznie nie istnieje.

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(zwykle nazywany także Normalx86_64) ma tendencję do mapowania pamięci dla stref poza standardowymi zakresami 896MiB bezpośrednio jądro dostępne w systemach 32-bitowych. Na x86_64 HighMem/Normalwydaje się obejmować wszystkie strony powyżej 3GiB.

DMA32zawiera strefę używaną dla pamięci, która byłaby dostępna na 32-bitowych urządzeniach DMA, tzn. można adresować je 4-bajtowymi wskaźnikami. Uważam, że DMAdotyczy 16-bitowych urządzeń DMA.

Ogólnie rzecz biorąc, w systemach o niskiej pamięci Normalnie istniałyby, biorąc pod uwagę, że DMA32obejmują one już wszystkie dostępne adresy wirtualne.

Powodem, dla którego zabijasz OOM, jest przydzielenie pamięci dla HighMemstrefy z 0 stronami dostępnymi. Biorąc pod uwagę, że moduł obsługi pamięci nie ma absolutnie żadnego powodu, aby zapewnić, że ta strefa ma strony do wykorzystania przez zamianę, zabijanie innych procesów lub inną sztuczkę, OOM-killer po prostu ją zabija.

Uważam, że jest to spowodowane balonowaniem maszyny wirtualnej hosta podczas uruchamiania. W systemach KVM można ustawić dwie wartości.

• Bieżąca pamięć.
• Dostępna pamięć.

Działa to w ten sposób, że można dodać pamięć na serwerze do dostępnej pamięci. Wasz system otrzymuje aktualną pamięć.

Po uruchomieniu maszyny wirtualnej KVM rozpoczyna się od maksymalnej możliwej do przydzielenia pamięci (dostępnej pamięci). Stopniowo podczas fazy rozruchu systemu KVM odzyskuje tę pamięć za pomocą balonowania, pozostawiając zamiast tego aktualne ustawienie pamięci.

Moim przekonaniem jest to, co się tutaj wydarzyło. Linode pozwala rozszerzyć pamięć, dając znacznie więcej na starcie systemu.

Oznacza to, że istnieje Normal/HighMemstrefa na początku cyklu życia systemu. Kiedy hiperwizor przesuwa balon, normalna strefa słusznie znika z menedżera pamięci. Podejrzewam jednak, że ustawienie flagi, czy wspomniana strefa jest dostępna do alokacji, nie jest usuwane, kiedy powinna. To prowadzi jądro do próby alokacji ze strefy, która nie istnieje.

Jeśli chodzi o rozwiązanie tego problemu, masz dwie opcje.

1. Pokaż to na listach mailingowych jądra, aby zobaczyć, czy to naprawdę jest błąd, oczekiwane zachowanie lub nic wspólnego z tym, co mówię.

2. Żądaj, aby linode ustawiło „dostępną pamięć” w systemie na takie samo przypisanie 1GiB jak „bieżąca pamięć”. W ten sposób system nigdy się nie balonuje i nigdy nie otrzymuje strefy normalnej przy starcie, utrzymując flagę w czystości. Życzę im powodzenia!

Powinieneś być w stanie przetestować, że tak jest, ustawiając własną maszynę wirtualną w ustawieniu KVM dostępnym dla 6GiB, bieżącym dla 1GiB i uruchamiając test przy użyciu tego samego jądra, aby sprawdzić, czy wystąpi powyższe zachowanie. Jeśli tak, zmień ustawienie „dostępne” na równe prądowi 1 GiB i powtórz test.

Robię tutaj wiele wykształconych domysłów i czytam między wierszami, aby uzyskać tę odpowiedź, ale to, co mówię, wydaje się pasować do już zarysowanych faktów.

Sugeruję przetestowanie mojej hipotezy i poinformowanie nas wszystkich o wyniku.

Aby odpowiedzieć na główne pytanie, użyj oom_score_adj(jądro> = 2.6.36) lub dla wcześniejszych jąder (> = 2.6.11) oom_adj, zobacz man proc

/ proc / [pid] / oom_score_adj (od Linuksa 2.6.36) Ten plik może być użyty do dostosowania heurystyki złej użytej do wyboru, który proces zostanie zabity w warunkach braku pamięci ...

/ proc / [pid] / oom_adj (od Linuksa 2.6.11) Za pomocą tego pliku można dostosować wynik używany do wyboru, który proces powinien zostać zabity w sytuacji braku pamięci (OOM) ...

Jest o wiele więcej do przeczytania, ale ustawienie oom_score_adj na -1000 lub oom_adj na -17 pozwoli osiągnąć to, czego chcesz.

Problem w tym, że coś innego zostanie zabite. Być może lepiej byłoby ustalić, dlaczego wywoływana jest OOM i sobie z tym poradzić.

Kilka przemyśleń (z moich komentarzy powyżej) i linki do ciekawych informacji na temat twojej sytuacji:

• Zalecam sprawdzenie, czy 1) możesz adresować więcej niż 3Gb za pomocą obecnego jądra i konfiguracji (i procesora) [ponieważ jeśli 3Gb jest limitem dla twojego systemu i systemu operacyjnego, to go przekraczasz]. 2) zezwalasz na wymianę, a podsystem wymiany jest na swoim miejscu i działa. powodzenia (nie wyjaśnię tego, jak to zależy od twoich ustawień i szczegółów. Wyszukiwarki pomogą). I że nie przepełniasz tabeli jądra (liczba pidów? Ani nic innego (niektóre mogą być ustawione w czasie kompilacji jądra).

• Sprawdź, czy całość (sprzęt lub symulowany sprzęt VM itp.) Ma 64 bity. (patrz na przykład: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). System operacyjny procesora i hosta oraz podsystem VM i VM powinny być włączone w wersji 64-bitowej, w przeciwnym razie nie będziesz mieć prawdziwej 64-bitowej wersji VM

• Kilka dobrych lektur:

  • Jak zdiagnozować przyczyny procesów zabijania zabójców : na tej stronie. Daje fajny link, http://linux-mm.org/OOM_Killer , a inny użytkownik wprowadza narzędzie szczytowe, które może pomóc zdiagnozować, co się dzieje
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 pokazuje drzewo decyzyjne dla OOM (starszej wersji, więc ymmv. Przeczytaj źródło ^^)
  • https://lwn.net/Articles/317814/ : „Oswajanie zabójcy OOM” pokazuje, między innymi, jak stworzyć „nietykalną” grupę i włożyć w nią swój proces
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : pokazuje niektóre typowe ograniczenia jądra
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : to dobra lektura (zmarnowane miejsce z niektórymi metodami alokacji itp.), mimo że jest naprawdę przestarzała (a zatem dotyczy tylko 32- architektury bitów ...)
  • http://bl0rg.krunch.be/oom-frag.html pokazuje kilka powodów, dla których „Zabójca OOM może zostać wywołany, nawet jeśli jest jeszcze dużo dostępnej pamięci”
  • https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : umożliwia sprawdzenie, w jaki sposób system alokuje pamięć
  • https://serverfault.com/a/724518/146493 : doskonała odpowiedź dająca zdeterminowany sposób, aby naprawdę wiedzieć, co się naprawdę wydarzyło (ale ... celował w 32-bitowe pytanie, więc ymmv. Mimo to niesamowita lektura i odpowiedź).

• i na koniec: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html pokazuje sposób, aby zapobiec atakowi OOM na twój proces! ( echo -17 > /proc/PROCESSPID/oom_adj). Może być podatny na zmiany i może być złą rzeczą (powodować inne rodzaje awarii, ponieważ system nie może teraz po prostu zabić głównego przestępcy ...) Należy zachować ostrożność. @iain zauważ, że „oom_adj” jest dla starszych jąder i powinno zostać zastąpione przez „oom_score_adj” w nowszych. Dziękuję Iain)

oprócz wspomnianego oom_score_adjzwiększenia dla omawianego procesu (co prawdopodobnie nie pomoże wiele - sprawiłoby, że PIERWSZE zabiłoby ten proces, ale ponieważ jest to system intensywnie korzystający z pamięci, prawdopodobnie nie odzyska się, dopóki nie zostanie ostatecznie zabity), oto kilka pomysłów do ulepszenia:

• jeśli ustawisz vm.overcommit_memory=2, również dostosuj vm.overcommit_ratiodo może 90 (alternatywnie, ustaw vm.overcommit_memory=0- patrz dokumentacja nadkomitowania jądra )
• zwiększać vm.min_free_kbytes , aby zawsze zachować wolną fizyczną pamięć RAM, a tym samym zmniejszyć szanse, że OOM będzie musiał coś zabić (ale nie przesadzaj, ponieważ OOM natychmiast).
• wzrost vm.swappinessdo 100 (aby łatwiej zamieniać jądro )

Pamiętaj, że jeśli masz za mało pamięci, aby wykonać dane zadanie, nawet jeśli nie robisz OOM, może on (lub nie) stać się BARDZO powolny - pół godziny pracy (w systemie z wystarczającą ilością pamięci RAM) może z łatwością zająć kilka tygodni ( po zastąpieniu pamięci RAM zamienianiem) w ekstremalnych przypadkach, a nawet zawiesić całą maszynę wirtualną. Dzieje się tak zwłaszcza w przypadku wymiany na klasycznych dyskach obrotowych (w przeciwieństwie do dysków SSD) z powodu ogromnych losowych odczytów / zapisów, które są na nich bardzo drogie.

Spróbowałbym włączyć overcommit i sprawdzić, czy to pomoże. Wygląda na to, że proces zawiedzie w forkwywołaniu, które wymaga tyle pamięci wirtualnej, ile miał proces początkowy. overcommit_memory=2nie czyni twojego procesu odpornym na zabójcę OOM, po prostu zapobiega jego uruchomieniu przez przydzielenie zbyt dużej ilości. Inne procesy mogą powodować niepowiązane błędy alokacji (np. Uzyskanie ciągłego bloku pamięci), które nadal wyzwalają zabójcę OOM i usuwają proces.

Alternatywnie (i bardziej na temat), jak sugeruje kilka komentarzy, kup więcej pamięci RAM.

Krótka historia - wypróbuj inną wersję jądra. Mam system, który pokazał błędy OOM w jądrach 4.2.0-x i 4.4.0-x, ale nie w wersji 3.19.0-x.

Długa historia: (nie za długa!) Mam tu wciąż Compaq DC5000 - obecnie z 512 MB pamięci RAM (i część tej, jak 32-128 MB, na wideo na pokładzie ..) NFS, mam do niego podłączony monitor, więc od czasu do czasu się loguję (Ubuntu Classic, brak Unity).

Przez Ubuntu HWE przez długi czas działałem jądro 3.19.x; skończyłoby to jak 200-300 MB rzeczy, ale najwyraźniej były to rzeczy nieużywane, nie byłoby żadnej zamiany z tego, że musiałbym zamienić je później, o ile mogłem powiedzieć.

Jądro 4.2.0-x, a teraz jądro 4.4.0-x, mogę uruchomić gruby zapis NFS, tylko 220 MB do wymiany (tj. 1,3 GB za darmo), i zacznie zabijać OOM. Nie twierdzę, że jest to błąd jądra lub „problem ze strojeniem” (jak rezerwa 64 MB, która normalnie jest w porządku, ale zbyt wysoka w systemie około 400 MB?)

Bez szacunku dla tych, którzy mówią, że to w jakiś sposób łamie tylko dlatego, że oczekuje zamiany; z całym szacunkiem, że się mylisz. Nie będzie to szybkie, ale w kilku systemach 512 MB-1 GB korzystałem z wymiany 1 lub 2 GB. Oczywiście, niektóre rodzaje oprogramowania mlock to trochę pamięci RAM, ale w moim przypadku (ponieważ używam tego samego oprogramowania tylko na innym jądrze), oczywiście tak nie jest.