LINUX.ORG.RU
Форум — General  

Эффективная борьба с зависаниями по исчерпании памяти?

 , , , ,


4

5

В последние дни вроде как активизировались обсуждения на тему зависаний линукса при нехватке памяти. Но сейчас на дворе 2019, почему на такую серьёзную проблему никто не обращает внимания уже больше 20 лет? Неужели она не решаемая?

Вроде как появились какие-то студентоподелки вроде earlyoom (вызывающие system() на сырые команды пришедшие через dbus или что-то такое там), но разве нельзя решить эту проблему средствами того же systemd?

Вот вам кусочек из лога, система ушла подумать и не вернулась. В ядре были включены все возможные счётчики, таймеры реагирующие на зависания и всё такое, в логе ничего не появилось от момента зависания до вызова manual oom. Готово для продакшена.

[126549.382913] sysrq: SysRq : Manual OOM execution
[126549.382990] Mem-Info:
[126549.382994] active_anon:1907880 inactive_anon:18992 isolated_anon:0
                 active_file:635 inactive_file:1258 isolated_file:0
                 unevictable:1 dirty:0 writeback:0 unstable:0
                 slab_reclaimable:4522 slab_unreclaimable:15053
                 mapped:65700 shmem:19656 pagetables:6750 bounce:0
                 free:14265 free_pcp:1481 free_cma:0
[126549.382996] Node 0 active_anon:7631520kB inactive_anon:75968kB active_file:2540kB inactive_file:5032kB unevictable:4kB isolated(anon):0kB isolated(file):0kB mapped:262800kB dirty:0kB writeback:0kB shmem:78624kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[126549.382998] DMA free:15900kB min:20kB low:32kB high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15996kB managed:15900kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[126549.382998] lowmem_reserve[]: 0 2982 7935 7935
[126549.383002] DMA32 free:27064kB min:4280kB low:7332kB high:10384kB active_anon:2897840kB inactive_anon:28604kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:3119804kB managed:3054044kB mlocked:0kB kernel_stack:720kB pagetables:7968kB bounce:0kB free_pcp:4264kB local_pcp:1328kB free_cma:0kB
[126549.383002] lowmem_reserve[]: 0 0 4952 4952
[126549.383006] Normal free:14096kB min:7108kB low:12176kB high:17244kB active_anon:4733680kB inactive_anon:47364kB active_file:2172kB inactive_file:4324kB unevictable:4kB writepending:0kB present:5234688kB managed:5075588kB mlocked:4kB kernel_stack:3824kB pagetables:19032kB bounce:0kB free_pcp:1660kB local_pcp:16kB free_cma:0kB
[126549.383006] lowmem_reserve[]: 0 0 0 0
[126549.383007] DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15900kB
[126549.383014] DMA32: 182*4kB (UME) 60*8kB (UME) 82*16kB (UME) 83*32kB (UME) 128*64kB (UME) 65*128kB (UME) 17*256kB (UM) 2*512kB (U) 0*1024kB 0*2048kB 0*4096kB = 27064kB
[126549.383021] Normal: 779*4kB (UME) 239*8kB (UME) 149*16kB (UME) 115*32kB (UME) 43*64kB (UE) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13844kB
[126549.383027] 21739 total pagecache pages
[126549.383027] 2092622 pages RAM
[126549.383027] 0 pages HighMem/MovableOnly
[126549.383028] 56239 pages reserved
[126549.383028] Tasks state (memory values in pages):
[126549.383028] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[126549.383031] [    550]     0   550     3752      337    53248        0             0 udevd
[126549.383032] [   1372]     0  1372      627       14    32768        0             0 busybox
[126549.383033] [   1506]     0  1506    54386      306    69632        0             0 rsyslogd
[126549.383034] [   1537]     0  1537      662       30    45056        0             0 rasdaemon
[126549.383035] [   1668]     0  1668    19558       86    53248        0             0 chronyd
[126549.383036] [   1698]     0  1698     2241      200    49152        0             0 crond
[126549.383037] [   1764]     0  1764      975      100    45056        0             0 login
[126549.383038] [   1765]     0  1765      975      100    45056        0             0 login
[126549.383039] [   1766]     0  1766     1993       30    53248        0             0 agetty
[126549.383040] [   1767]     0  1767     1993       29    49152        0             0 agetty
[126549.383041] [   1768]     0  1768     1993       30    53248        0             0 agetty
[126549.383042] [   1769]     0  1769     1993       29    49152        0             0 agetty
[126549.383043] [   1771]     0  1771     2442      168    57344        0             0 bash
[126549.383044] [   2038]  1000  2038     2407      143    57344        0             0 bash
[126549.383045] [   3819]     0  3819    34164      306   118784        0             0 sddm
[126549.383046] [  25344]     0 25344    57765    18947   331776        0             0 X
[126549.383048] [  25362]     0 25362    13354      308   102400        0             0 sddm-helper
[126549.383049] [  25366]  1000 25366    68432     1053   241664        0             0 kwalletd5
[126549.383050] [  25367]  1000 25367     2317       77    57344        0             0 startkde
[126549.383051] [  25373]  1000 25373     1143       70    45056        0             0 dbus-launch
[126549.383051] [  25374]  1000 25374     1227      293    45056        0             0 dbus-daemon
[126549.383052] [  25398]  1000 25398      561       22    40960        0             0 start_kdeinit
[126549.383053] [  25399]  1000 25399    24169      749   176128        0             0 kdeinit5
[126549.383054] [  25400]  1000 25400    68126     1123   233472        0             0 klauncher
[126549.383055] [  25403]  1000 25403   147607     3503   319488        0             0 kded5
[126549.383056] [  25409]  1000 25409    67982     1056   233472        0             0 kaccess
[126549.383057] [  25418]  1000 25418    68083     1367   233472        0             0 kglobalaccel5
[126549.383058] [  25422]  1000 25422    11436      133    81920        0             0 kwrapper5
[126549.383059] [  25423]  1000 25423    88283     1272   253952        0             0 ksmserver
[126549.383060] [  25429]  1000 25429    55222      475   151552        0             0 kscreen_backend
[126549.383061] [  25436]  1000 25436   128268     7376   430080        0             0 krunner
[126549.383062] [  25438]  1000 25438   291634    42985   897024        0             0 plasmashell
[126549.383063] [  25446]  1000 25446    38475      535   159744        0             0 xembedsniproxy
[126549.383064] [  25449]  1000 25449    57216      531   172032        0             0 gmenudbusmenupr
[126549.383065] [  25455]  1000 25455    81168      970   217088        0             0 org_kde_powerde
[126549.383066] [  25469]  1000 25469   135246      963   241664        0             0 kactivitymanage
[126549.383067] [  25693]  1000 25693    83725     5711   368640        0             0 konsole
[126549.383068] [  25696]  1000 25696     2407      151    61440        0             0 bash
[126549.383069] [  30544]  1000 30544     2407      156    57344        0             0 bash
[126549.383070] [   3640]  1000  3640    95579     8042   360448        0             0 thumbnail.so
[126549.383071] [  14305]  1000 14305   749453    94288  1695744        0             0 falkon
[126549.383072] [  14310]  1000 14310    67726     1633   348160        0             0 QtWebEngineProc
[126549.383073] [  14345]  1000 14345   499805   107824  4390912        0           300 QtWebEngineProc
[126549.383074] [  14518]  1000 14518   870434    33733   987136        0             0 kwin_x11
[126549.383075] [  14720]  1000 14720   442839    21406  2011136        0           300 QtWebEngineProc
[126549.383076] [  14880]  1000 14880     2348       85    57344        0             0 ex.sh
[126549.383077] [  14882]  1000 14882  2440872  1572825 13651968        0             0 java
[126549.383078] [  14951]  1000 14951   469635    35992  3039232        0           300 QtWebEngineProc
[126549.383079] Out of memory: Kill process 14882 (java) score 773 or sacrifice child
[126549.383136] Killed process 14882 (java) total-vm:9763488kB, anon-rss:6281980kB, file-rss:9252kB, shmem-rss:68kB
[126549.494043] oom_reaper: reaped process 14882 (java), now anon-rss:0kB, file-rss:30532kB, shmem-rss:68kB

 ← 1 2 →
Ответ на: комментарий от anonymous

Ах да, на нём кде стоит. Сидел на крысе, но та медленней работала и памяти столько же сколько и кеды жрала.

anonymous
()
Ответ на: комментарий от pon4ik

Гайд скорее сюда, что куда писать и что настраивать. Чтобы оно само потом работало.

Скажем помещаем все браузеры в группу которую первой грохать, жабу во вторую очередь, и компиляторы в третью (сразу после линкеров). Виртуалки где-нибудь в конце, сразу перед иксами, и чтобы остальное вообще мать его никогда не трогало ядро — там каких-то 3 мегабайта на крон с логером и dhcpc их не надо трогать никогда.

И ещё желательно ограничить QoS для диска, чтобы не мог 1 процесс выжирать всю полосу. Своп не своп там, видосики важнее чем свопящийся компилятор. В венде насколько я припоминаю это всё давно решено.

anonymous
()
Ответ на: комментарий от hakavlad

Ух ты! Сколько полезных нулей.

Зачем же ж ты целых 6Гб памяти купил? Мог бы купить самую маленькую планку и помножить на 100 :3

aidaho ★★★★★
()
Последнее исправление: aidaho (всего исправлений: 1)
Ответ на: комментарий от aidaho

Я всегда удивлялся сколько же данный в памяти являются нулями или прочим подобным мусором. В принципе это может работать, зависит от юзкейса.

anonymous
()
Ответ на: комментарий от ya-betmen

Насмешил.

Объясни свою позицию аргументированно, плиз. Прихдилось ли вам на практике сталкиваться с факапами earlyoom, или это основано лишь на предположении, что это «студенческая поделка».

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Объясни свою позицию

Легко. Напиши конфиг компа и сколько раз в год ты сталкивался с зависаниями вызванными оомкиллером до того как ты стал использовать ерлиом.

ya-betmen ★★★★★
()
Ответ на: комментарий от Nastishka

Что не так с головой у всех этих людей, которые на вопрос «как бы сделать так, чтоб система не зависала на неопределенное время при исчерпании памяти» на серьезных щщах дают ответ, так или иначе сводящийся к «добавить памяти»?

shatsky ★★
()

Похоже, что весь софт, включая системд и дисплейный сервер, написан так, что постоянно неявно обращается к накопителю, и работает быстро только до тех пор, пока есть где закэшировать все, к чему он обращается. Вопрос сводится к тому, возможно ли написать нечто, что будет гарантированно удерживать в кэше все ресурсы всех процессов среды, необходимой для того, чтобы пользователь мог убить что-то отожравшее память. Возможно, копировать составляющие эту среду пакеты со всеми зависимостями на смонтированный оверлеем рамдиск.

shatsky ★★
()
Ответ на: комментарий от shatsky

Вопрос сводится к тому, возможно ли написать нечто, что будет гарантированно удерживать в кэше все ресурсы всех процессов среды, необходимой для того, чтобы пользователь мог убить что-то отожравшее память.

Можно. Уже пишу.

Принцип простой: когда доступная память почти исчерпана морозим нахрен user.slice. Симптомы после заморозки: курсом легкуо шевелится, остальное замерзло. Увидев симптомы последнего, юзер лонинится в tty2 и убивает свинью. Ожидайте этот функционал в nohang v0.3.

удерживать в кэше все ресурсы всех процессов среды, необходимой для того, чтобы пользователь мог убить что-то отожравшее память

Для этого всего лишь достаточно иметь некоторый небольшой объем доступной памяти.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Неплохо, но далеко от идеала. Идеал с точки зрения обычного пользователя:

  • оболочка (UI запуска/переключения программ) остается жива;
  • можно открыть диспетчер задач и убить любые процессы;
  • остальные запущенные приложения заморожены (но их можно попытаться закрыть и оболочка предложит их убить), при попытке запустить новые оболочка сообщает об отсутствии свободной памяти.
shatsky ★★
()
Ответ на: комментарий от shatsky

оболочка (UI запуска/переключения программ) остается жива

можно открыть диспетчер задач и убить любые процессы;

Реализуется введением белого списка прог, которые нельзя морозить. Единого универсальног решения не получится, рабочие столы у всех разные. Хотя можно из коробки некоторые варианты предложить.

hakavlad ★★★
()
Ответ на: комментарий от ya-betmen

Напиши конфиг компа и сколько раз в год ты сталкивался с зависаниями

Регулярно сталкивался, если не следил за потреблением. После нескольких случаев ввел в привычку постоянное поглядвание за системный монитор.

Памяти 6 гиг, свопТотал=0.

И ты так и не объяснил чем плох юзерспейсный киллер.

hakavlad ★★★
()
Ответ на: комментарий от ya-betmen

Поверь, с 6 гигами это будет каждые 3 часа, если повезёт. 8 уже с запасом, но тоже браузер вторым приложением не откроешь уже. С 8 нужен своп хотя бы 4 гига.

anonymous
()
Ответ на: комментарий от ya-betmen

1 раз в год это регулярно, 0.5 раза в год это тоже регулярно. Так сколько?

Да хоть каждый час, если не сдерживать себя.

hakavlad ★★★
()
Ответ на: комментарий от anonymous

У меня на одной из ноутов именно 6. На нем живут браузер и жаба с нетбинсом.

ya-betmen ★★★★★
()
Ответ на: комментарий от bender

Alt-SysRQ-f жи, только вот иногда (у меня где-то раз в год) виснет так, что оно даже на magic keys не откликается, какой уж там tty switch.

balsoft ★★
()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от balsoft

виснет так

Вероятно, это что-то другое, например кривой видеодрайвер, возможно баг в нём проявляется только при нехватке памяти.

anonymous
()
Ответ на: комментарий от anonymous

Не исключено, но там даже Alt-SysRQ-b ничего не делает :( Было бы интересно попытаться как-то оживить систему из того состояния, но раз в год можно и ресет тыкнуть, этож десктоп.

balsoft ★★
()
Ответ на: комментарий от anonymous

Ну не знаю, у меня после апгрейда до 32ГБ пока ни разу не приходил OOM killer, хотя аптайм месяцами и это десктоп. На 16ГБ раз в месяц приходилось ручками Alt-SysRQ-f

balsoft ★★
()
Ответ на: комментарий от balsoft

На 16ГБ раз в месяц приходилось

Даже столько почти ни у кого нет. А к тому времени как будет, 32х будет недостаточно.

anonymous
()
Ответ на: комментарий от aidaho

«Возьмём машину с 2Гб памяти и удвоенным zram swap.»

Почему удвоенным ? разве нет возможности сделать размер свопа столько, сколько нужно ?

anonymous
()
Ответ на: комментарий от anonymous

Так хотел юзернейм, которому я отвечал.

aidaho ★★★★★
()
Ответ на: комментарий от linuxnewbie

Я конечно могу попробовать сделать своп на флешке

Его ещё в файле можно сделать вообще-то.

AS ★★★★★
()
21 февраля 2020 г.
Ответ на: комментарий от ya-betmen

Теоретически пси с что-то может сделать

Не теоретически, а уже на практике реализовано:

https://www.youtube.com/watch?v=Y6GJqFE_ke4

Корректирующие действия выполняются при активном своппинге с заморозкой гуя.

anonymous
()

разве нельзя решить эту проблему средствами того же systemd?

Можно, Лёня уже делает systemd-oomd. Это не шутка.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
General