Як змусити вбивцю Linux OOM не вбити мого процесу?

Як змусити вбивцю Linux OOM не вбивати мої процеси, коли фізична пам’ять мало, але є достатньо місця для обміну?

Я вимкнув вбивство OOM і перевищив програму sysctl vm.overcommit_memory = 2.

У VM є 3 ГБ абсолютно безкоштовного нефрагментованого свопу, а процеси, які вбиваються OOM, мають максимум використання пам'яті менше 200 МБ.

Я знаю, що тривалий обмін буде жахливим для продуктивності, але мені потрібно скористатися свопом зараз, щоб зробити функціональне тестування на вальдрінд, де вимоги до пам'яті значно більші.

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

Це / 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

Це, мабуть, є проблемою у поєднанні двох факторів:

• Використання віртуальної машини.
• Можлива помилка ядра.

Частково це один із рядків, який описує, чому це відбувається:

7 березня 02:43:11 myhost kernel: memcheck-amd64 - викликав oom-killer: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

Інший рядок такий:

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

| Перший рядок - це маска GFP, призначена для розподілу. В основному це описує те, що ядро ​​дозволено / заборонено робити для задоволення цього запиту. Маска вказує купу стандартних прапорів. Останній біт, "2", однак вказує на те, що розподіл пам'яті повинен відбуватися із HighMemзони.

Якщо придивитися уважно до виходу OOM, ви побачите, що жодної HighMem/Normalзони насправді не існує.

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(як правило, також називається Normalx86_64) має тенденцію до відображення пам'яті для зон поза стандартними діапазонами 896MiB, безпосередньо ядрами, доступними для 32-бітових систем. На x86_64 HighMem/Normalсхоже, що охоплює всі сторінки розміром вище 3GiB.

DMA32містить зону, яка використовується для пам’яті, яка була б доступною на 32-бітних пристроях DMA, тобто ви можете адресувати їх за допомогою 4-х байт-покажчиків. Я вважаю, що DMAце для 16-бітних пристроїв DMA.

Взагалі кажучи, системи з низькою пам’яттю Normalне існували б, враховуючи, що вже DMA32охоплені всі наявні віртуальні адреси.

Причина, через яку ви вбиваєте OOM, полягає в тому, що є виділення пам’яті для HighMemзони з 0 сторінками. Враховуючи, що обробник пам'яті не має жодного способу задовольнити використання цієї зони для використання сторінок, замінюючи їх, вбиваючи інші процеси чи будь-який інший трюк, вбивця OOM просто вбиває його.

Я вважаю, що це спричинено повітряним кулею VM на завантаженні. У системах KVM ви можете встановити два значення.

• Поточна пам'ять.
• Наявна пам'ять.

Як це працює, це те, що ви можете гаряче додавати пам'ять на ваш сервер до доступної пам'яті. Однак вашій системі фактично надається поточна пам'ять.

Коли KVM VM завантажується, він починається з максимально можливого виділення пам'яті (наявної пам'яті). Поступово під час фази завантаження системи KVM відновлює цю пам'ять, використовуючи її на повітряній кулі, залишаючи натомість поточний параметр пам'яті, який у вас є.

Моє переконання, що тут сталося. Linode дозволяють розширити пам’ять, даючи набагато більше при запуску системи.

Це означає, що Normal/HighMemна початку життя системи є зона. Коли гіпервізор надуває повітря, нормальна зона справедливо зникає з диспетчера пам'яті. Але я підозрюю, що встановлення прапора, чи є згадана зона доступною для виділення, не очищено, коли слід. Це призводить ядро ​​до спроби виділення із зони, яка не існує.

У плані вирішення цього питання у вас є два варіанти.

1. Виведіть це на списки розсилки ядра, щоб побачити, чи справді це помилка, очікувана поведінка чи взагалі нічого спільного з тим, що я говорю.

2. Попросіть, щоб лінод встановив, що "доступна пам'ять" в системі є таким же призначенням 1GiB, як "поточна пам'ять". Таким чином, система ніколи не повітряні кулі і ніколи не отримує Звичайну зону під час завантаження, зберігаючи прапор чітким. Удачі, змусивши їх зробити це!

Ви маєте змогу перевірити, що це так, встановивши власну віртуальну машину в налаштуваннях KVM, доступної для 6GiB, поточної до 1GiB, та запустивши тест, використовуючи те саме ядро, щоб побачити, чи відбувається така поведінка, яку ви бачите вище. Якщо це так, змініть налаштування "доступно" на рівний 1GiB струму і повторіть тест.

Я роблю тут купу освічених здогадок і читаю між рядками, щоб дещо придумати цю відповідь, але те, що я говорю, схоже, вже відповідає викладеним фактам.

Я пропоную перевірити свою гіпотезу та дати нам усім знати результат.

Для того, щоб відповісти на ваше запитання заголовка, використання oom_score_adj(ядра> = 2.6.36) або для більш ранніх ядер (> = 2.6.11) oom_adj, см людини прок

/ proc / [pid] / oom_score_adj (з Linux 2.6.36) Цей файл можна використовувати для регулювання евристики поганих евристик, які використовуються для вибору того, який процес загине в умовах поза пам'яттю ...

/ proc / [pid] / oom_adj (з Linux 2.6.11) Цей файл можна використовувати для налаштування балів, які використовуються для вибору того, який процес повинен бути вбитий у ситуації з пам'яттю (OOM) ...

Є ще багато чого читати, але встановлення oom_score_adj на -1000 або oom_adj на -17 допоможе досягти того, що ви хочете.

Біда в тому, що щось інше буде вбито. Можливо, було б краще визначити, чому МОМ звертається до цього і вирішувати це.

Кілька думок (з моїх коментарів вище) та посилань на заперечення читає про вашу ситуацію:

• Я рекомендую переконатися, що 1) ви можете звертатися до більш ніж 3 Гб за допомогою свого поточного ядра & config (& cpu) [тому що, якщо 3Gb є лімітом для вашої системи & os, ви перевищуєте його]. 2) що ви дозволяєте здійснювати заміну, і підсистема заміни працює і працює. удачі (я не поясню, як, оскільки це залежить від ваших налаштувань і особливостей. пошукові системи допоможуть). І що ви не переповнюєте таблицю ядра (nb pids? Або щось інше (деякі можуть бути встановлені під час компіляції ядра).

• Переконайтеся, що вся справа (апаратне забезпечення або модельоване обладнання vm тощо) має 64 біт. (див. наприклад: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Підсистема cpu & host OS & vm & vm OS повинна бути включена 64-бітною, інакше у вас не буде справжнього 64-бітного vm

• Деякі хороші цифри:

  • Як діагностувати причини процесів вбивства, що вбивають смерть : на цьому самому сайті. Надає приємне посилання http://linux-mm.org/OOM_Killer , а інший користувач представляє інструмент зверху, який може допомогти діагностувати, що відбувається
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 показано дерево рішень для ООМ (старішої версії, тому ymmv. Прочитайте джерело ^^)
  • https://lwn.net/Articles/317814/ : "Приборкання вбивці OOM", серед іншого, показує, як створити "неприйнятну" групу і розмістити в ній свій процес.
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : показує деякі загальні обмеження ядра
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : це хороше зчитування (витрачений простір з деякими методами виділення тощо), хоча він справді датований (і, таким чином, містить лише 32- бітові архітектури ...)
  • http://bl0rg.krunch.be/oom-frag.html показує деякі причини, через які "Вбивця OOM може викликатися навіть тоді, коли пам'яті ще багато"
  • https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : дає змогу перевірити, як ваша система розподіляє пам'ять
  • https://serverfault.com/a/724518/146493 : відмінна відповідь, що дає детальний спосіб дізнатися, що дійсно сталося (але ... націлене на 32-розрядне запитання, так ymmv. Хоча все-таки неймовірне прочитання та відповідь).

• і нарешті: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html показано спосіб запобігти націлюванню на ваш процес вбивцею oom! ( echo -17 > /proc/PROCESSPID/oom_adj). Можливо, схильний до змін і може бути поганим (спричинить інші збої, оскільки система тепер не може просто вбити головного правопорушника ...) Використовуйте обережно. @iain зауважте, що "oom_adj" призначений для старих ядер, і його слід замінити на "oom_score_adj" у нових. Дякую, Іайн)

окрім згаданого oom_score_adjпосилення для розглянутого процесу (який, ймовірно, не допоможе багато - це зробить меншою ймовірність того, що цей процес буде вбитий ПЕРШИЙ, але оскільки це лише процес, що займає пам'ять, процес процес, ймовірно, не відновиться, поки він остаточно вбито), ось кілька ідей для налаштування:

• якщо ви встановите vm.overcommit_memory=2, також налаштуйте vm.overcommit_ratioна 90 (можливо, встановіть vm.overcommit_memory=0- див. документи ядра із перевиключенням )
• збільшити vm.min_free_kbytes, щоб завжди залишати фізичну оперативну пам'ять вільною і, таким чином, зменшувати шанси, щоб ОМВ потребував чогось вбити (але не перестарайтеся, оскільки це буде миттєво OOM).
• збільшити vm.swappinessдо 100 (щоб зручніше міняти ядро )

Зауважте, що якщо у вас занадто мало пам’яті для виконання завдання, навіть якщо ви не OOM, це може (або не може) стати НАЙКРАЙНО повільним - півгодинна робота (у системі з достатньою кількістю оперативної пам’яті) може зайняти кілька тижнів ( коли оперативна пам'ять замінена свопом), щоб завершити в крайніх випадках, або навіть повісити цілий VM. Особливо це стосується випадків, коли своп відбувається на класичних обертових дисках (на відміну від SSD) через масивні випадкові читання / записи, які на них дуже дорогі.

Я б спробував увімкнути перевиконання та побачити, чи це допомагає. Здається, ваш процес не працює під час forkдзвінка, для чого потрібна стільки віртуальної пам'яті, скільки і початкового процесу. overcommit_memory=2не робить ваш процес незахищеним від вбивці OOM, він просто заважає вашому процесу запускати його, виділяючи занадто багато. Інші процеси можуть спричинити непов’язані помилки розподілу (наприклад, отримання суміжного блоку пам'яті), які все ще запускають кілера OOM та позбавляють вашого процесу.

Як альтернатива (і ще більше), як свідчить декілька коментарів, купуйте більше оперативної пам’яті.

Коротка історія - спробуйте іншу версію ядра. У мене є система, яка показувала помилки OOM з ядрами 4.2.0-x та 4.4.0-x, але не з 3.19.0-x.

Довга історія: (не надто довго!) У мене тут ще є Compaq DC5000 - наразі 512 Мб оперативної пам’яті (і деяку частину цього, наприклад 32-128 МБ, надають на бортове відео ..) NFS, у мене є підключений до нього монітор, тому час від часу я входжу в нього (Ubuntu Classic, немає Unity.)

Через Ubuntu HWE я добре працював з ядром 3.19.x; в кінцевому підсумку він міняється як 200-300 Мб речей, але, мабуть, це були невикористані речі, не було б жодної активності свопінгу з цього, щоб пізніше поміняти його, наскільки я міг сказати.

Ядро 4.2.0-x, а тепер ядро ​​4.4.0-x, я можу запустити кумедний запис NFS до нього, лише 220 МБ в своп (тобто 1,3 ГБ безкоштовно), і воно почне OOM вбивати речі. Я не стверджую, що це помилка в ядрі або "проблема налаштування" (наприклад, резерв на 64 Мб, як правило, нормально, але занадто високо в системі ~ 400 Мб або близько того?)

Не зважайте на тих, хто каже, що це якось зламається лише тому, що він розраховує використовувати своп; з усією повагою ви помиляєтесь. Це не буде швидко, але я використовував 1 або 2 ГБ в свопі на декількох системах 512 МБ-1 ГБ. Звичайно, деякі типи програмного забезпечення mlock - це велика кількість оперативної пам'яті, але в моєму випадку (оскільки я використовую те саме програмне забезпечення лише на іншому ядрі), це явно не так.