Názory k článku
Řešení problémů se systemd-oomd v Ubuntu 22.04?

Som rad ze mame na vyber... Na gentoo, bez systemd, s wayland a sway, tieto problemy nepozorujem :) Je mi jasne ze nie kazdy to ma tak ako ja a ma uplne ine poziadavky.

Mno, ja jedu na Kubuntu 22.04, Chrome mam z ofic repo Google, tzn bez snapu, a pohoda. Nic samovolne nechcipa, problem nepozoruju. Je ale fakt ze instaluju system pres preseed, pripadne debootstrap, protoze mam rootfs na zfs.

To je takové řešení z bláta do louže. Tak to místo Chrome sestřelí něco jiného. Kdo posoudí, co je důležité?

Chápu vyjímku pro gnome-shell, ale i u něj pokud se zbláznil gnome-shell, tak je prostě potřeba sestřelit gnome-shell. Ale Chrome nebo VSCode teda nechápu ani trochu.

Já třeba používám vlastní oom-killer, který zabíjí právě a jen Chrome, protože u mně to býval jediný viník (resp. nějaká vypatlaná webovka). Ten jsem si teda napsal kdysi dávno, když jsem měl "jen" 4GB a teď se aktivuje sotva jednou za rok, ale prostě sestřeluje toho, kdo si to "zaslouží".

Problém je, že systemd-oomd teď shazuje procesy, když to ještě ani zdaleka není potřeba a že o tom nedá vědět. (A že Linux dovoluje overcommit, který ani náhodou nedokáže uspokojit.) To je potřeba poladit.

overcommit se dá nastavit / zakázat.

Bohužel v praxi ne, prakticky žádná z "moderních" aplikací se ani nespustí. Prohlížeče, cokoliv Qt, atd.

Souhlas: Chrome si o sestřelení obvykle dost koleduje.
Na to, že to má být jen prohlížeč, se chová, jako by velel celému systému. Jen málo aplikací je ve vytěžování zdrojů tak důsledných...

Na druhou stranu jen málo aplikací umí to co Chrome.

No... IMHO má Chrome opravdu umět jen prohlížet webové stránky a nikoliv snažit se dělat všechno možné, počínaje přehráváním videa, a zdaleka nekonče péčí o moje blaho rozhodováním, co je pro mne dobré a co nikoliv; je naprosto neřiditelný a s každou další versí mne přesvědčuje, že potřebuji sdílet profil napříč zařízeními, synchronisovat data, hlídat zlobivé weby a čert-ví-co-ještě... Je jasné, že na to potřebuje prostředky víc než půkyl systému. A já si přitom jen chci přečíst články na rootu...

Tak používej jiný prohlížeč a nebreč tu :) Třeba lynx by mohl být to pravé pro tebe.

Povedz mi.....

https://bugs.chromium.org/p/chromium/issues/detail?id=1283726#c_ts1641756113

4GB jeden tab,... už som bol aj v stave že s 20 tabmi v Chrome + Discord a nič iné, a využitých som mal cez 30GB pamäte.

BTW nadherne zakonecna diskuze - kdy lack of activity ze strany vyvojaru konci jako wont fix. Typicka opensource komunita, (ve skutecnosti maskovany support, ktery se snazi pouze "zakaznika" poslat do zadele).

A jak to asi mají vyřešit, když to M. neumí nijak nasimulovat? Tohle je tak obecně a amatérsky (asi všichni vývojáři mají zájem číst na screenshotu texty ve slovenštině) zadaný report, že se s ním nic dělat nedá.

Proč vůbec nenastaví ZRAM a když dojde RAM, tak to začne provádět kompresi a vleze se do paměti víc, systém bude pomalejší systém, ale to aspoň uživateli dá takový signál "Něco se děje, nee, nemůžeš mít na tomto HW 300 záložek chrome"
Jasně záleží, jestli použijí zstd nebo lzo-rle.

Proč by mi mělo něco v systému rozhodovat, co se zabije? To bylo na Windows pořád, jsem hrál, zaplnilo se 6GB z 8GB a zabilo to hru a hláškou "Došla paměť" jsem na to koukal, že co to má být, když mám pořád volné 2GB.

To je další pokus, jak z Ubuntu vytvořit Windows?

protože pokud už se něco pokazí, z vlastní zkušenosti ZRAM většinou naopak zhorší situaci. Místo zabití aplikace se systém ještě bude chvíli trápit kompresí a teprve potom přijde smrt.

Na Windows a macOS to oddálí problém. Komprese se skutečně zapne, až když RAM dochází. Ne jako na Linuxu, že RAM komprimuje vždy, nebo nikdy.

zram se normálně používá jako swap. Tedy dokud je dost RAM, nekomprimuje se.

Myslím že normální hranice je 50% využití (cache se nepočítá). Pak se začíná "swapovat" do zramu, tedy bez použití disku, ale jinak se to chová jako obvyklý swap, takže se zase komprimují jen nepoužívané stránky anebo když je opravdu nedostatek paměti. A když ani to nestačí, dojde na swapování na disk, pokud bylo nakonfigurováno. Dohromady mi to funguje moc pěkně, ale na Ubuntu to vyzkoušeno nemám ;-)

Ta hranice se dá nastavit, avšak stále si stojím za svým - je lepší, když se systém zpomaluje, než když zamrzne a hotovo.

Možná by stačila hláška "Blížíš se limitu kapacity RAM, zavři něco"

Připadne mi nesmysl, aby OS úplně za uživatele řešil to, že do 8GB RAM nenacpeš data, která mají 12GB.

Pak to zabije něco, co se nemá zabít o práce je fuč a člověk je jen nasraný.

Systemd je RH srcka (jedna z mnoha, namatkou pridam avahi a pulse). Je naprosto zbytecna (protoze restart sluzby i zavislosti lze resit konkretnim init scriptem) a slouzi jen jedinemu cili. Tim je virtualizace a cloud - tam potrebujete o jednotky vterin rychlejsi start, tam se chcete vyhnout konfiguraci OS a prostredi, tam nechcete zadnou variabilitu v nastaveni zakladnich sluzeb (dns, ntp, dhcp ...), ktere systemd tak rad "pozira"

Zabijeni procesu kvuli RAM je opet nejvice vyuzitelne v cloudech a ve virtualizaci, kde chybi swap a RAM je stale tou nejdrazsi polozkou v cene.

Doufam, ze plany RH nakonec tak nejak zhati kontejnerizace (kde bezi jeden proces, pamet si limituji cgroups a restart provadi kontejnerizace), a od tohohle paskvilu bude konecne klid. Protoze na desktopu nejaky systemd NIKDO NEPOTREBUJE

Kdyz chci wrkstation na hry, staci mi windows. Kdyz na praci, mam radsi linux - ale nechci, aby mi z nej nejaky nablbly prechytraly vecne nedodelany systemd delal windows. Neni duvod.

Zív...

Trollovat se musí umět.

Taky. Ať už na desktopu, na serveru, v cloud nebo na mobilu, skripty jsou paskvil a neměly by se používat. Shell je ten nejvíc error prone programovací jazyk na světě a představa, že neustále běhá s právy roota a nějak se horko těžko snaží dohánět chybějící funkcionalituy, které má OS mít od základu, v tom nevidím žádnou hodnotu hodnou udržování.

mas vsude start systemu bez initrd (kterej obsahuje desitky shell scriptu), vsechny crony (ktere jsou z casti shell scripty) mas prepsane do systemd timer's ? grub menu si vytvaris rucne? (protoze update-grub je sada shell scriptu) atd, atd... proste takoveto vykriky jsou "vtipne" kdyz nevis co v systemu vlastne mas ;-)

Samozřejmě, že vím, co mám, a to neznamená, že to je nutně dobře. Sám jsem cron nepoužil už minimálně 7 let. Distro na některé věci ještě používá crontab a /etc/cron.d... ale to se automaticky přepisuje do cron timerů, což ho ovšem samo o sobě nedělá o nic lepší, než klasický cron. To, že už nejsou init skripty, pidfiles a podobné krámy jenom oceňuju.

update-grub, grubby, apod sú čisté peklo. Každý si to robí ako chce, a keď niekde nastane problém, ani srnka netuší kde to odladiť.

Najnovšie ostree (základ Fedora Silverblue) spúšťanie generátora niekde ukrýva a user sa nedostane ani len k tomu, aby vedel kedy sa to spúšťa. Laďte potom niečo.

Pritom bootloader ani nejaký komplikovaný config ani nepotrebuje. Taký systemd-boot si vystačí s jednoduchými ini súbormi, ktoré obsahujú všetko potrebné a môžu byť priamo v balíčku s jadrom, netreba ich nejako generovať.

Klíčovým problémem nejsou skripty, systemd by možná šel vyrobit i skriptováním. Tím klíčovým problémem je, že každý z těch skriptů je originál, nic není standardizováno, každý dělá něco jiného a jinak - spouštění, zastavování, hlídání, logování, možná závislosti (nebo taky ne), ...

s OOMK byly vždycky jen problemy, buď reaguje moc brzo nebo moc pozdě. Já se setkal s tím druhým. I na mašině, která nemá swap dochází "k odswapování" mapované paměti, pokud jde o R/O paměť, tak bez zápisu na disk. I tak pak dochází k "uswapování" stroje, protože místo zabíjení procesů jsou nechávány v běhu, ale jejich stránky jsou odstraňovány ve prospěch požadovaného volného místa, jenže pokud ty procesy běží, je vysoce pravděpodobné, že záhy budou potřeba znovu natahovány do paměti (čímž se smaže něco jiného) - a OOMK - je spí dál. Způsob, jakým se to snaží řešit je rovnák na ohýbák. Opravdu je těžké poznat, zda již došla paměť, nebo se to vyřeší odstraněním nedůležitých cache.

Tohle se mi bohužel děje i na Androidu, kdy tamní OOMK odmítá ukončit nafouknutý chrome, takže foreground aplikace je pomalejší, než na osmibitech a často vyskakuje okénko, že nereaguje.

Současný stav se mi prostě nelíbí, řešit by se to mělo. Jestli to řešit takhle si ale nejsem jist.

Ten Chrome na Androidu je v popředí, nebo v pozadí? Appky v pozadí by měl systém zabíjet (a mně to dělá).

Z meho pohledu je v pozadi. Ale s tim jak chrome pridava ruzne sluzby casto zustane vetsi cast bezet