Portál AbcLinuxu, 10. května 2025 08:12
Řešení dotazu:
V prvom rade zistiť PID
daného procesu a potom pozrieť oom_score
. Myslím si, že OOM ti vypočíta také skóre, že dochádza k nadmernému čerpaniu dostupnej RAM. Iná možnosť je následne pozrieť .xsession-errors
alebo .xsession-errors či tam nie je zmienka o minúti RAM.
Pozor. Tieto nastavenia už môžu narušiť stabilitu. Či systém padne alebo nie rozhoduje náhoda. Použitie na vlastne riziko
Ešte je možnosť nastaviť aby system menej prísne posudzoval alokáciu pamäte. Je to možné urobiť overcommit_memory
a vložiť tam hodnotu 1.
Ak ti nevadí strata dát v danej hre, tak môžeš nastaviť OOM tak aby nehladal, ktorý process spôsobil nedostatok RAM ale rovno ukončil daný process.
earlyoom
To^^^ jen tak na okraj a v nouzi. OOM Killer totiž nefunguje tak, jak většina lidí očekává, že by měl fungovat.
Jinak bych ale doporučoval „investovat“ do RAM, která většinou stojí pět korun padesát. Když sečteš čas a úsilí ve spojitosti s tuhnutím počítače a psaním dotazu sem, možná bys už měl dalších 128 GB, kdybys příslušné úsilí zaměřil „správným“ směrem.
Ano, chlastám i poránu. (Asi tak posledních 10 let, takže slovo už k tomu nepasuje.)
Těžko říct, proč se tady na ABCLinuxu musí poslední dobou každý kec vysvětlovat jako ve školce.
Pointa každému docvakla, doufám: Než bojovat s nedostatkem RAM, je většinou výhodnější koupit si víc RAM.
Obvykle o tom uvažuju takto: Čas vynaložený na boj s nedostatečným hardwarem je promarněný. Jakmile se promarněný čas začne blížit času, za který bych si prací vydělal na upgrade hardwaru, většinou marný boj vzdám a objednám hardware.
Obavám sa, že v prípade väčšiej RAM to nemusí mať požadovaný výsledok. Jednoducho povedané v prípade jedného procesu dôjde k zvýšeniu OOM skóra čo pri spustení OOM má za následok odmietnutie alokácie RAM. Ďalší probém je ako nastaviť oom_adj tak aby bol zmenený hneď pri štarte procesu. Zatial som nenašiel nejaké použitelné riešenie. Nemyslím, že schodná cesta je pracne vyhladavať daný process a zmeniť oom_adj.
Toto sa mne už stalo s chrome a pritom tam mám 16GB ram ale keď to začalo odmietať alokovať RAM tak realne nebolo využité ani 30%. Vinník bol gpu process, ktorý bral veľa RAM čo spôsobilo zvýšenie OOM skóra.
grep -E "" /proc/*/oom_score
free -h |grep Mem | awk '{print $2}' # zistenie velkostiPrejdi na open-source hru Minetest, lebo Minetest je:
Ale jak už jsem psal, earlyoom to řeší docela úspěšně.Psal jsi, že earlyoom něco zabije a proto bych měl obavy, že mi zabije nějaký program ve kterém mám zrovna rozdělanou a neuloženou práci. Proto mě na to téma napadlo, že bych si raději zvolil co chci zabít.
Jinak jak jsem psal výše, z mého pozorování mi přišlo že Windows tenhle problém zvládají lépe, že nikdy nedopustí aby byl swapován vlastní OS. Skoro bych až řekl že u Windows se počítá s tím že poběží na hardwaru s nedostatkem RAM, kdežto v Linuxu se to bere tak že RAM prostě je.
Asi jo, ale mám pocit že došlo k určitému zhoršení, myslím, že třeba na XP se v takové swapovací krizi bylo o dost snazší dočkat, až se otevře Task Manager a tam ten Chrome nebo něco dalšího sejmout. Na W10 už se mi párkrát povedlo, že odezva byla tak v háji, že to prakticky bylo zatuhlé a musel jsem to vypnout.
Je ale možné, že za to u mě může nestandardaní konfigurace (u Windows fakt člověk udělá dobře, když má všechno nastavené co nejvíc defaultně, ono teda asi i na LInuxu) - mám swap na pevnou velikost a ještě jsem ho z důvodů "důchodce má strach z moderní doby" dal na HDD místo SSD. Výhoda je, že nástup většího používání swapu (kupodivu to není při přelezení kapacity RAM, ale spíš až když se víc přiblížíte hranici RAM+SWAP) působí takovou línnější odezvu, takže má člověk zpětnou vazbu a vidí, že si má udělat pořádek předtím, než mu to začne fakt blbnout (to je když jsem na hranici dostupné vituální paměti, tj. RAM+SWAP).
Linux != Windows
takže udělat něco takového by se současnými prostředky dost dobře nebylo možné.Jestli tím současným prostředkem myslíš Xorg, tak to chápu, je to už důchodce, ale aspoň u Waylandu by mohli udělat, aby se dalo spustit "okno" s vysokou prioritou, které by mělo nějak rezervované zdroje a sloužilo by jako "záchranné". Napadá mne ještě toto: - na tty7 běží výchozí Xorg/Wayland - na tty8 by běžel nějaký úplně minimální druhý Xorg/Wayland, na který by se dalo přepnout a při přepnutí by dostal vysokou prioritu (aby v něm plynule fungovala myš nebo alespoň klávesnice) a v němž by byl seznam běžících procesů. Tzn. Ctrl-Alt-F8 by fungovalo jako Ctrl-Alt-Del na Windows.
Ďalej by ten process musel mať vyššiu prioritu v cpu. Keďže alokácia RAM má svoju spotrebu cpu času. Ideálne by to bolo dať na prioritu RT, ale keď sa ti niečo s RT splaší, tak máš obrovsky problém to zastaviť.
na tty8 by běžel nějaký úplně minimální druhý Xorg/Wayland, na který by se dalo přepnout a při přepnutí by dostal vysokou prioritu (aby v něm plynule fungovala myš nebo alespoň klávesnice) a v němž by byl seznam běžících procesů. Tzn. Ctrl-Alt-F8 by fungovalo jako Ctrl-Alt-Del na Windows.Nevymyslaj nove kolo. ;) Na to treba pouzit Klávesa Sys Rq.
na tty8 by běžel nějaký úplně minimální druhý Xorg/Wayland, na který by se dalo přepnout a při přepnutí by dostal vysokou prioritu (aby v něm plynule fungovala myš nebo alespoň klávesnice) a v němž by byl seznam běžících procesů. Tzn. Ctrl-Alt-F8 by fungovalo jako Ctrl-Alt-Del na Windows.Já jsem si na ctrl+alt+delete poslal mate-system-monitor a ještě se mi nepodařilo dostat systém do takového stavu, aby se mi jej nepodařilo vyvolat. A kdyby přeci jen, tak pak tu je textová konzola. Ne, skutečně nechci, aby linux byl dalšími windows. Mimochodem, už jsem viděl W10 ve stavu, kdy přetekla paměť, objevil se smajlík s textem něco se pokazilo a následoval restart. Takže s tím vyjádřením bych byl poněkud opatrnější. Lagovat může jakýkoliv systém. Stačí k tomu špatná konfigurace, neoptimalizovaná aplikace, či nedostačující hardware. Případně i souběh více věcí najednou. Ale všemu se dá poměrně jednoduše předcházet.
Ne, skutečně nechci, aby linux byl dalšími windows.To já taky nechci, ale zase nepředstírejme, že problém neexistuje. Vývojářům občas přistane report o problému s vyčerpanou RAM (jak jsem psal níže). I to, že to tazatel tady řeší je důkazem, že problém existuje a nemá nějaké jednoduché intuitivní řešení. Pokud chceme, aby Linux zůstal jen v rukou technicky pokročilých uživatelů, tak fajn, řešme to přes tty nebo OOM-killer, ale pak by se linuxová komunita neměla divit, že Linux nechtějí používat BFU. Ale je pravda, že se stále rychlejšími NVMe nebude swapování na disk takový problém, jako v minulosti s rotačními HDD.
BFU ani netuší, k čemu opičí trojhmat sloužíTěm, kteří to netuší to lze v případě Windows jednoduše sdělit, ale u Linuxu to nelze sdělit, ale musíš jim dát složitý návod.
Daný nástroj už dávno existuje. Nie je nutné neustále pridavať ďalšie balíčky s približne rovnakou funkčnosťou.
Predpokladám, že si trochu všímaš koľko ram ti ubudne keď pustíš nejakú aplikáciu a zrejme vieš odhadnúť, že aplikácie prestala vykonávať svoju správnu činnosť.
Mne osobne už pár krát zhodilo chrome ale takým spôsobom, že volnej RAM bolo dosť. A pritom som nemal otvoreného toľko, že by bol dôvod na problémy až nakoniec bola hláška o nedostatku RAM v .xsession-errors. Najsť problemový proces je možné cez oom_score. Je možné, že svoju rolu malo aj nastavenie OOM tak, že má zastaviť proces, ktorý spôsobil OOM a nehladal heurestikou.
Myslím, že použiť tty je lepšie, keďže nepotrebuje veľa RAM. V prípade, že už nemôžeš prepnúť, použi Alt+Sysrq+K. Táto skratka zruší všetko čo bolo spustené na danej obrazovke. Prídeš síce o data ale nemusíš reštartovať systém. Ďalej linux má špecialné nastavenie pre minimum volnej RAM pre užívateľa s CAP_SYS_ADMIN čo je root. Z tohto vyplýva, že najefektivnejšie je použiť tty pre svoju nenáročnosť na RAM.
Môže sa použiť pam modul pam_limits.so ale zatial som ho netestoval s grafickým prostredím. Modul umožňuje určitú reguláciu prostredkov.
Predpokladám, že si trochu všímaš koľko ram ti ubudne keď pustíš nejakú aplikáciuVšímám, ale RAM jsem vyčerpal vždy nějakým nechtěným způsobem - chyba ve scriptu, nechtěně jsem spustil více VM... Takže ukazatel volné RAM mi byl jen k tomu, že jsem pochopil co se děje když se začal systém sekat.
nastavenie OOM tak, že má zastaviť proces, ktorý spôsobil OOMPokud bych si to taky tak nastavil, tak to znamená, že když mám např. 6GB volné RAM a spustím VM, která si chce vzít 8GB, tak mi OOM ukončí VM? Zastavit poslední spuštěný proces, který způsobil vyčerpání volné RAM se mi zdá lepší než kdyby heuristika vyhodnotila, že má ukončit třeba rozepsaný LibreOffice. Jak jsem se začetl do archwiki, tak jsem si všiml poznámky:
While the behaviour of the kernel as well as the userspace things under low-memory conditions may improve in the future as discussed on kernel[3] and fedora[4] mailing list...a taky jsem si všiml, že earlyoom je ve výchozí instalací Fedory Workstation od verze 32, takže jde vidět, že to trápí více uživatelů a vývojáři se to snaží nějak řešit.
Zrejme mám riešenie. Síce po pár nutných pokusoch. Celý problém bude v tom, že OOM má najnižšiu hladinu nastavenú značne nízko čo v prípade veľkého GUI prostredia je problém. Mne sa podarilo úspešne vyvolať OOM až keď bola hodnota minimálne pamäte okolo dvoch gigabajtov v premennej min_free_kbytes
a oom_kill_allocating_task = 1
, overcommit_memory = 0
. Samozrejme s značne obsadenou RAM. Výsledok bolo reštart do prihlásovacej obrazovky po pár sekundách.
Výsledok bolo reštart do prihlásovacej obrazovky po pár sekundách.Ten earlyoom, který už jsem zmiňoval, míří výrazně lépe. V mém případě typicky sestřeluje nenažrané taby v Chromiu, ale X session nepadla snad ani jednou.
--prefer REGEX
. Škoda, že tam nejde specifikovat, aby se ukončil největší proces spuštěný třeba za posledních 10 sekund a který je větší jak 500MB. Řešilo by to situaci, kdy uživatel spustí něco náročnějšího na RAM a neuvědomí si, že nemá volnou RAM.
# /etc/default/earlyoom EARLYOOM_ARGS="-r 0 --avoid '(^|/)(Xorg|sshd|dbus-daemon|kdeinit|kded|start_kdeinit|klauncher|krunner)$'"Klidně si to však můžeš upravit, viz kill.c:118.
sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.overcommit_ratio=100
No a pokud se vypne swap: sudo swapoff -a
, a pak spustím Qemu, které si řekne o více RAM než je volná RAM, tak skončí s hláškou: "qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory". V dmesg není žádný záznam "oom". Při použití Qemu je to optimální (pokud bych vůbec nechtěl riskovat swapování), ale horší by to bylo třeba u prohlížeče až by při otevření další záložky došla RAM sudo sysctl -w vm.overcommit_memory=0
sudo sysctl -w vm.overcommit_ratio=50
a swap nechám vypnutý, tak Qemu se i při nedostatku RAM spustí, ale jakmile RAM dojde, tak ho OOM zabije a v dmesg je "oom" záznam.
Zrejme mám riešenie. ... Výsledok bolo reštart do prihlásovacej obrazovky po pár sekundách.Jsem zmaten. Na začátku píšeš, že máš řešení a na konci, že ti to sestřelilo Xko. To se mi nezdá jako dobré řešení.
Je to riešenie v zmysle zmeny minimálného dostupného množstva RAM. Vtedy sa spustí OOM skôr. To že zhodilo viacej procesov je tým, že bolo nastavené zrušiť proces ktorý žiada o alokáciu. V druhom prípade by system dlho prehladaval zoznam procesov, ktoré majú vysokú spotrebu RAM.
Teoreticky by možno stačilo zmeniť minimálne množstvo RAM a tak nechať prejsť zoznam programov, ktoré alokujú veľa RAM. Neviem o osobách ktoré by to takto mali. Jedine vyskúšať. Otázka je aj použité jadro. Myslím, že každé jadro môže reagovať inak.
mkdir /run/useless-mem mount none /run/useless-mem -t ramfs dd if=/dev/zero of=/run/useless-mem/500M bs=1M count=500 rm -i /run/useless-mem/500MAž ti bude docházet paměť, tak jen potvrdíš smazání a máš 500MB paměti volných. Dotaz provádí přímo rm, takže už nebude zdržovat načítání dalšího procesu.
elegantníTakhle bych to tedy nenazval a v bance už vůbec ne. Píšu to v komentářích pod tím článkem. Pokud místo na disku může dojít tak rychle, že si toho monitoring nestačí všimnout, tak zcela jistě dojde i po té, co někdo (kdo a jak si toho všimne? jo aha: A pokud někdo volá...) smaže dummy soubor na disku (a ještě k tomu pouze 4GB - proč není místo toho monitoring nastaven na 40GB zbývajícího volného místa?). Toto prostě není řešení a už jen přítomnost podobných souborů k tomuto účelu ukazuje na rezignaci hledat skutečné řešení, funkční monitoring a snadné přidání dalšího místa. (Nevím, jestli to měli na virtuálech nebo na fyzickém železe, ale tj asi jedno, každopádně v té době mi přidání místa na disku zabralo i s přihlášením na vmware do dvou minut - přidat hw, disk, ok, přidat pv do vg, zvětšit lv, resize2fs - limit jsme měli nastaven tak, že warning přišel cca 2 měsíce před vyčerpáním místa, takže technik měl dost času to udělat.)
a je potřeba server udržet v choduPokud ten server nese tak důležité služby, že nesmí vypadnout, tak je lepší je schovat za nějaké HA řešení a nedoufat v jeden server.
archive_command
) a poté je u sebe smazat (k ničemu dalšímu už jí stejně nejsou). Jinak od verze 10 už to není adresář pg_xlog
, ale pg_wal
, protože některé takyadminy slovo log evokovalo k tomu, že to prostě smazali, protože logy nepotřebují (ano, je to oficiální odůvodnění). A následně zjistili, co to je záloha a proč ji měli mít Nevím nakolik Postrges stejně jako Oracle má možnost definice více archive_log_dest s tím, že by mělo být možné definovat minimální počet úspěšných archivací (zaplnění/neúspěšnost jedné archive_log_destinace snad není důvod pro zastavení DB).V
archive_command
si sám admin definuje, co se má s tím logem stát, takže jestli si to rozkopíruje na 50 míst a jedině potom ohlásí exitcode 0, je to jen na něm. Tj ano, je možné si definovat jakékoliv nakládání s těmi logy.
Netvrdím, že je to len jediný správny postup. Ale myslím si, že jednoduchšie je zmeniť jednú premennú ako sekvenciu príkazov.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.