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
← Swap на разделе VS swap в файле. SSD. BTRFS.
aufs проверка файла →

 ← 1 2

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

Вспомнил 12309

K29
()

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

Сначала обращают, потом свыкаются. Да и легче памяти докупить, чем там в недрах разбираться.

turtle_bazon ★★★★★
()

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

Нет. Теоретически пси с что-то может сделать, но если захотят возиться ради мизерного процента людей с отключенным свопом.

ya-betmen ★★★★★
()

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

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

Своп выключен в ядре, его некуда положить. С ним аналогичная картина когда он кончается (и он будет кончаться), только помноженная на то, что линукс начинает сношать диск. Планирую использовать zram для неактивных страниц.

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

Ваша система вынесла страницы page cache (которые clean), в которых лежат заммапленные библиотеки, которые снова начинают грузиться при каждом переключении процессов.

Если бы у вас был свап, то... В вашем случае в свап улетело бы процентов 70-80 от вашей жабы, и система продолжила бы работать.

Но у вас свопа нет - вы его отключили и отстрелили себе ногу. Ну, на самом деле не ногу, но близко к тому.

Nastishka ★★★★★
()

Тут самое эффективное средство - удвоение рамы. Кстати, сколько у вас ее прям сейчас?

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

Хм, ну правда ведь, когда компилятор начинает линковать вебкиты никакой своп не спасает. Я конечно могу попробовать сделать своп на флешке, только у меня имеются некоторые сомнения на тему производительности (и жизнеспособности) такого варианта уже сейчас.

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

В общем случае это решается промежуточной частичной линковкой, ну типа как в ядре.

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

что это за баг 12309

Много историй ходило в своё время. Считалось, что если набрать в «Ну погоди» 1000 пойманых яиц, то тебе покажут мультик. Некоторые говорили, что если в Super Mario суметь перепрыгнуть шест с флагом, то в замке окажется принцесса. Иногда утверждалось, что, начав копировать в линуксе файл на флешку, можно встретить баг 12309. Никто не видел ни первого, ни второго, ни третьего, но легенды ходят до сих пор.

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

Своп выключен в ядре, его некуда положить.

Гуглите демон swapspace. Он как раз предназначен для таких ситуаций.

Система с одним лишь свопом на zram не сильно отличается от системы без swap вообще.
Ровно те же проблемы придут в гости чуточку позже.

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

Оно немножко мертво. Предлагаете положить файл подкачки в облако? Будет шустрее усб2.

Основные надежды на zram я возлагаю в связи с тем, что протекают в первую очередь нули и мусорные данные, которые отлично сжимаются. Следовательно, можно иметь 10-кратный прирост памяти из ниоткуда и я хочу этим воспользоваться.

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

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

Оно немножко мертво

Работать перестало от того, что по средам не релизят новые версии?

Следовательно, можно иметь 10-кратный прирост памяти из ниоткуда и я хочу этим воспользоваться.

Всё даже близко не так.
Пока ядро потихоньку кладёт туда мало используемые страницы, реальный коэффициент сжатия бывает 3.5 и даже порой 3.8.

Когда с памятью действительно плохо и в своп посыпется всё подряд, 2.5 можно считать за успех.
Будет ближе к двум.

Вторая загвоздка: чем меньше у машины памяти, тем меньше для неё эффект от zram.

Если взять две машины, с 2Гб и 32Гб, и обеим выдать по свопу на zram с размером 50% от ОЗУ, и приняв 3, как чересчур оптимистичный коэффициент, то:

1я машина с забитым zram будет иметь 2-(2/2/3) = 1.6(6) Гб свободной памяти
2я: 32-(32/2/3) = 26.6(6) Гб, что не только очевидно намного больше в абсолютном выражении, но и в относительном тоже непропорционально больше разницы в ОЗУ машин.


Богатые от субсидий получают больше профита, чем бедные.

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

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

zswap в теории лучше и полезнее и zram и обычного свопа без выкрутасов.

На практике реализация почему-то вышла хуже.

aidaho ★★★★★
()

какие-то студентоподелки вроде earlyoom

Напоминаю, что ядро - это студентоподелка, в которой не решена проблема зависания при нехватке памяти.

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

если захотят возиться ради мизерного процента людей с отключенным свопом

Своп не спасает от дедлоков. Фейсбук использовал своп, этого оказалось недостаточно, пришлось разработать oomd.

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

Своп выключен в ядре, его некуда положить

Положи в zram, там можно найти сотни гигабайт свободного месчта для сжатия нулей

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

Система с одним лишь свопом на zram не сильно отличается от системы без swap вообще. Ровно те же проблемы придут в гости чуточку позже.

Наглая ложь, если дело касается запуска браузеров на десктопе. Делаем zram disksize = 2 MemTotal, и эффект будет прекрасен. Сжатие в 3-5 раз будет обеспечено, сжатие быстрое.

чуточку позже

Только если zram disksize маленький.

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

Я не шучу. Браузеры прекрасно сжимаются. Кроме того, у кого-то может еще более лучше сжимаемые данные есть, поэтому 2MemTotal это вовсе не много. Имея 6 гиг рам, запросто вгонял еще 12 гиг в своп, забивая память реальными жирными профилями браузеров. Нет никаких причин делать zram disksize меньше MemTotal.

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

Нет никаких причин делать zram disksize меньше MemTotal.

Например, чтобы осталась память для, собственно, программ?

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

zbud

Однажды zbud с пулсайзом 20% (дефолт) показал даже худший результат, чем своп на HDD без сжатия. Юзай z3fold/zsmalloc с большим размером пула.

hakavlad ★★★
()

активизировались обсуждения на тему зависаний линукса при нехватке памяти

Вот он ваш типичный линукс.

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

Возьмём машину с 2Гб памяти и удвоенным zram swap.
Нафантазируем ей коэффициент сжатия 3.
Остаётся аж 670 сферических Мб оперативки.

От это перемога. Как много памяти то стало!
Теперь можно заняться бесконечным переливанием страниц из zram, и обратно.

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

Ты прям описал работу процесорного кэша.

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

А тем временем, например, sched autogroup был принят в ядро.

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

Теперь можно заняться бесконечным переливанием страниц из zram, и обратно.

Таки да! При этом не испытывая больших тормозов как при медленом свопе на HDD.

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

/proc/meminfo может с этим сделать то же самое, что и psi

Отлично, покажи мне как из /proc/meminfo получить то же самое что и из /proc/pressure/io.

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

Не то же самое, но смысл тот же: метрики оттуда дают возможность предотвратить зависания при исчерпании.

cat /proc/meminfo | grep MemAvailable

cat /proc/meminfo | grep SwapFree

Этого достаточно для успешной работы earlyoom.

А пси - опасная и непредсказуемая штука, см https://github.com/hakavlad/nohang/issues/25#issuecomment-521390412

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

Своп тоже не резиновый. Он тоже ложится, если память течёт. Даже когда он 100 гигов +

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

Третий я и сейчас вижу. Правда копировать надо с NTFS на exFAT. Работает надёжно как швейцарские часы.

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

Я не шучу. Браузеры прекрасно сжимаются. Кроме того, у кого-то может еще более лучше сжимаемые данные есть, поэтому 2MemTotal это вовсе не много

Ага, конечно. А если у тебя Pentium 4 на 478 сокете с 1.5 Гб ОЗУ? Представь, как сильно просядет производительность CPU.

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

Представь, как сильно просядет производительность CPU.

Не больше, чем из-за медленного io.

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

У меня есть такой, вполне ничего. Два камня на выбор, первый на 1.7ггц и второй на 3ггц, тот что на 3 фулхд видосики тянет только когда видеокарта декодирует (т.е. никаких 10 битных h264) или максимум 720p@30 на процессоре. В целом вполне достаточно для всего, скриптоты поменьше и браузер на 2 гигах не запустишь одновременно с каким-нибудь софтом. Ну и это, софт иногда просит всякие simd которых там нет.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Swap на разделе VS swap в файле. SSD. BTRFS.
General
aufs проверка файла →