Pokud vím, povedlo se memory leak najít a opravit, probíhá testování. Takže snad pravidelný restart shellu nebude brzo potřeba.
No o tom čtu každé vydání že se opravily další a další, ale nemám ten pocit, že by tam bylo nějaké zásadní zlepšení.
Je to přesně jak říká covex, mám na obstarožním ThinkPadu s 2GiB RAM i3wm a uptime klidně 100 dní aniž bych musel něco řešit. GNOME Shell musím každý druhý den restartovat kombem Alt+F2 + r, jinak si vezme klidně 30+ % z 16GiB RAM. Po restartu bere nějakých 4 až 5 % paměti, což je úlet. Nedostalo se mi to naštěstí tak daleko, že by se uswapoval a musel bych resetnout, nedostalo, ale i tak je to nemilé. Člověk to potom musí i hlídat, když nahodí pár virtuálek v práci, jinak by to fakt mohlo sežrat i swap.
I přes to nedám na GNOME Shell na desktopu dopustit, ale tohle by měla být priorita pro vývojáře, než předělávat Nautilus na sto způsobů.
covex: nevím o tom, že by se dal ten aktivní horní roh vypnout v rámci nastavení, ale, ačkoliv je to úlet, je na to extension v repech gnome-shell-extension-no-topleft-hot-corner a když si člověk Dash vytáhne z aktivit do Docku přes gnome-shell-extension-dash-to-dock je to podle mě ideální kombinace.
Ano, také mám na ThinkPadu 16GB RAM a řeším stejný problém. Uptime mám klidně 14 dnů, jen zamknu, nevypínám, ale Gnome shell musím občas restartovat, protože sežere dost paměti.
Na vypnutí levého horního rohu existuje Gnome shell extenstion https://extensions.gnome.org/extension/118/no-topleft-hot-corner/
Ono je to trošku nefér srovnávat něco, co dělá čistě jenom správu oken a maximálně vykreslí jednoduchý panel s menu s GNOME Shellem. GNOME Shell není prostý správce oken, ale do značné míry i aplikační vrstva. Umí pokročilé vyhledávání v různých zdrojích, které samo o sobě konzumuje docela dost paměti, aby bylo rychlé, má v sobě kalendářový backend, aby mohl zobrazovat akce v kalendáři a upozorňovat na ně atd.
GNOME Shell je napsaný v JavaScriptu, což je super z pohledu rozšířitelnosti, žádný jiný desktop nejde upravovat do takové míry jako GNOME Shell, ale použití JavaScriptu není optimální zase z pohledu spotřeby paměti. Už jenom tím, že hledat memory leaky v JS kódu nad GJS není opravdu jednoduchá záležitost. No a pak jsou tu samotná rozšíření, kdy kterékoliv z nich může přinést obrovské množství další funkcionality (např. GSConnect běží celou implementaci KDE Connect v Shellu), která bere další množství paměti, a taky kterékoliv rozšíření může způsobit memory leak.
Uvažuje se o tom, že by se GNOME Shell přepsal do něčeho jiného (padaly návrhy třeba na Rust), ale to budou fóra zase plná lidí plačících nad koncem neomezeného rozšiřování a upravování. Můžeme se bavit o tom, jestli má GNOME Shell zřát 200 nebo 300 MB, ale IceWM nebo i3 to prostě nikdy nebude.
K tomu hot corneru: dřív se tam implementovalo to, že člověk musel vytvořit “tlak” na hranu obrazovky, aby se to gesto vykonalo. Je ale možné, že se to stalo obětí přechodu na Wayland. Původní řešení totiž záviselo na Xorg a pro Wayland by se to muselo celé přepsat.
1 Like
Pravda, nikdo snad nečeká, že to bude brát par desítek MiB v paměti, ale několik GiB a stále narůstat, to není v pořádku.
Pokud to roste do GB, tak ti IMHO není chyba v GNOME Shellu. Viděl jsem pár relativně máločetných chyb v ovladači, které způsobovaly také leaky, ale ve většině případů za to může nějaké špatně napsané rozšíření. Já mám GNOME Shell zapnutý druhý den a bere mi v paměti 380 MB z 16 GB. Nemám ale zapnuté žádné rozšíření.
No nemám jich zase tolik, ale v rámci testování můžu vyzkoušet. Hlavně to jsou všechno rozšíření z repositářů, žádné z extensions.gnome.org
Nemyslím si, že by ta rozšíření procházela nějakým podrobným review. Aby se dostala na extensions.gnome.org, tak se na ně někdo musí podívat, ale tam se maximálně řeší, aby to nezpůsobovalo pády a neobsahovalo to nějaký škodlivý kód. Do repozitářů Fedory se pak dostane rozšíření, které už typicky na extensions.gnome.org je, a v package review už se řeší hlavně to, aby to bylo dobře zabalené.
Navíc u obou platí, že se dělá jenom úvodní review. Následné změny jsou plně v kompetenci správce rozšíření/balíčku. Často se stává, že rozšíření dobře fungovalo s verzí GNOME Shellu XY a s verzí XY+1 způsobuje pády. Na extensions.gnome.org sice musí správce rozšíření explicitně uvést, že je rozšíření s novou verzí kompatibilní a ideálně by to měl i o testovat, ale pochybuju, že to někdo dělá to takové hloubky, aby sledoval i spotřebu paměti.
Jinak nepopírám úplně, že za určitých situací může spotřeba paměti GS narůst do opravdu velkých rozměrů. Např. se ví, že GS neuvolňuje z paměti obsah notifikací, takže pokud pošleš hodně notifikací třeba s náhledem hudební alba, může to naskákat vysoko. Ale aby to šlo do GB, musí to člověk dělat opravdu intenzivně. To je pravděpodobnější chyba v rozšíření nebo ovladači grafické karty.
Na jednu stranu se rozšíření pro GNOME Shell bere jako velká feature a výhoda, na druhou stranu to způsobuje problémy od memory leaků až po pády celého prostředí. Já chápu, že není moc jak ovlivnit, co za rozšíření kdo splácá, ale na druhou stranu neexistuje žádné rozlišení těch, co jsou nějak kvalitní (podporované když to tak řeknu) a co je na vlastní nebezpečí. A ruku na srdce, kdybych nemohl použít některá rozšíření které používám, tedy bych byl odkázán na vanilla GNOME Shell, tak bych GNOME Shell nepoužíval, přitom mi stačí ke štěstí opravdu hrstka rozšíření (přesněji 4, slovy čtyři).
V rámci odhalení těch memory leaků, co se mi dějí, jsem si teď všechny rozšíření vypnul, a připadám si jako “nahý”. Nevidím ikonky v oznamovací oblasti (hlavně tedy Slack), nevidím stav systémových prostředků, nevidím dash, takže nemám absolutní přehled o aplikacích/oknech, ne alespoň tak pohodlný a musím přes win klávesu do Aktivit, přitom na širokoúhlých monitorech si ten dash úplně říká o to, aby na boční straně hověl.
Ovladač grafické karty bych asi vyloučil (v mém případě alespoň), děje se to jak na Intelu tak na nVidii (binární).
Vytvořil jsem onen návod, jak nainstalovat minimalistickou instalaci GNOME Shell.
3 Likes
Nesmírně děkuju za návod!
A musím dodat, že svět je opravdu malý. Několik dní jsem se snažil přijít na to, jak se “jmenujete” pane “vain” Pamatoval jsem si před léty jenom ikonu 
A nevěděl jsem na jakém forum to bylo. A už tenkrát to bylo asi Gnome na začátku jste psal o nenažranosti a nějaké vychytávky, ale nemohl jsem si vzpomenout - od vás vlastně mám i Dash Dock.
A musím se vším souhlasit. Já také nechci po Gnome zázraky a také na rovinu říkám, že bez Dash bych to nepoužíval. Jednu dobu jsem měl Xfce pak i i3wm ale nějak se mi to Gnome líbí zvlášť s Dash.
Takže jaký závěr z toho bude - asi ten, že to budu muset restartit jako Windows, aby to nějak fungovalo.
Nedělám na to žádný zvěrstva. Blbé jenom je, že když potřebuju virtualku, tak mám problém s ukradenou pamětí od Gnome.
Btw Dash Dock si primo rika, aby byl by default v instalaci Gnome…
Tak tedy zdravím a jsem rád že se návod i líbí a že Dash to Dock doplněk vyhovuje, on je to opravdu dobře udělaný doplněk se skvělou konfigurovatelností. Byli si toho vědomi i pánové z Ubuntu, když se rozhodli zahodit Unity a přejít na GNOME Shell, spojili se s vývojářem Dash to Dock a onen dock v Ubuntu je vlastně Canonicalem nějak upravený originální Dash to Dock.
Ty memory leaky v GNOME Shellu začínám teď trochu víc sledovat, po tom, co psal Sešívaný a něco na tom bude, myslím ohledně těch ovladačů grafických karet, protože v práci se mi to neprojevuje tolik (Intel) jako doma (nVidia). Budu muset ještě vyzkoušet různé kombinace nouveau ovladač vs. binární, xorg vs. wayland a podobně. Nikdy mě to nenapadlo, že by to mohlo být něčím takovým.
Teď jsem zkoušel konečně na ostro nainstalovat podle návodu “vaina” a doslova čumím, jak to běží jako z praku. SUPER práce. Tohle jsem potřeboval. Já vlastně spoustu tich aplikací by default nepotřebuju a tohle je ideál.
To mi připomnělo Vy jste určitě měl i funkční stránky, kde jste měl návod na owncloud … je to tak, že? Takže tak dlouho se už “známe”
Jeste otazka spis pro zajimavost - jaky je rozdil v prosteri Cinnamon ve Fedore a jinych distrech? Dneska jsem cetl zpravu o tom, jak je v Mintu to a to noveho. To jedou separtne jen pro Mint? Diky
Rozdíl bude asi jen ve verzích. Na Fedoře mám teď 3.8.4. U Mintu nevím - nebyla tam verze?
Me by zajimalo kolik lidi/projektu tu upravitelnost GS vyuziva - podle me maximalne ty rozsireni, jenze cim jich bude vic tim to bude neudrzovatelnejsi a nekontrolovatelnejsi - to je totiz stejny pribeh jako Mozilla a XUL, ktery umoznoval vsechno, nasledne prisli na to ze se tim daji delat “strasne” veci a tak to ted pracne zakazali, coz plno lidi nastvalo.
Veškerá upravitelnost se dělá přes ta rozšíření. Ta nejsou nic jiného než patche kódu GS. A používají se opravdu hodně. Takové Ubuntu jich má předinstalovaných hned několik. Skoro každý uživatel si taky nainstaluje nějaké.
Je to holt klasický případ rozhodnutí, které před 10 lety vypadalo dobře. Pojďme to napsat v JavaScriptu, bude se to jednoduše vyvíjet a může se do toho zapojit řada lidí, protože JS je dost používaný jazyk. Pak se ukázalo, že se to dá za běhu patchovat a skvěle upravovat a vznikla rozšíření. Uběhlo pár let, kdy to se rozšíření natolik zpopularizovala, že jich existuje několik stovek a používá je skoro každý a přechodem na Wayland se obnažil problém s jejich stabilitou kvůli další nedokonalosti architektury (běh GS a Mutteru v jednom procesu). Při pádu GS na Xorgu totiž jenom problikne, na Waylandu člověk přijde o celé sezení a otevřené aplikace.
Řešení? Těžko říct. Omezit možnosti rozšíření by byl hodně nepopulární krok. Pomohlo by rozdělení GS a Mutteru do samostatných procesů. O tom se uvažuje, ale je to hodně práce.