plasmashell 6.1Gb memóriát használ

Fórumok

A héten már másodjára kellett újraindítanom a shellt, mert több mint 6Gb memóriát használ. 

$kquitapp5 plasmashell && kstart plasmashell
$plasmashell &

Újraindítás után 140Mb. Frissítés nincs egyenlőre. Az az érdekes, hogy mind a két alkalommal 6 Gb felett vettem észre, tehát nem láttam 3-4 Gb-os foglalást.
Tapasztaltatok hasonlót ?
KDE Neon User Edition, Plasma 5.22.3 , Qt 5.15.3, Wayland.
 

Hozzászólások

Az újabb mindig jobb™.

A memória azért van, hogy kihasználjuk™.

Innovációra™ szükség van, máskülönben visszafejlődünk™ a kőkorszakba™.

Nem, még™ véletlenül™ sem azért eszik sokat, mert babzsákfejlesztőék túlkényelmesedtek az 1 TB SSD-s, 64 GB RAM-os, 8 magos CPU-s, 12. generációs erőműveiken...

Helyesen: Nem, még™ véletlenül™ sem azért eszik sokat, mert babzsákfejlesztőék túlkényelmesedtek az 1 TB SSD-s, 64 GB RAM-os, 8 magos CPU-s, 12. generációs erőműveiken... vagy csak és van egy memory leak.

Tipikus esete annak, amikor a babzsákfejlesztő megszokta a modern™, 21. századi™, bloated keretrendszertől, hogy memóriát is kezel helyette.

hogy memóriát is kezel helyette

sőt mint tudjuk micoservice világ óta univerzális megoldás a restart :), ha a restart nem működik akkor visszaállunk az előző verzióra, hátha az el bír indulni.

Ez egyesek fejében úgy csapódik le, hogy ha pl egyre durvább memóriaszivárgás van akkor annak a megoldása, hogy sűrűbben indítod újra a szolgáltatást :D. (Megtörtént eset, teljesen komoly fejjel állította a szakértő úr.) Az, hogy esetleg megnézzék mi és miért szivárog abszolút nem szerepelt a tervek között. Mire égető lesz a probléma az illető már egy másik cégnél hinti a fost.

Igaz ez csak egy memory leak, de amúgy igazad van. Én azért sem támogatom, hogy használjunk bloatot, mert hiába 8 magos, meg 64 gigás gép, és fut rajta jó sebességgel a bloat, ha a pehelysúlyú megoldásokkal vetjük össze, azok azonos hardveren mindig gyorsabbak. Tehát ami egy KDE alatt 5 mp. alatt tölt be, egy soványabb ablakkezelős, minimalista rendszeren 1 mp. alatt lesz, ha nem ütközik bele valami bottleneckbe.

Az is igaz, hogy a KDE már régóta bloat, már jó 13 éve, a 4-es bekajált 1 giga RAM-ot, ha fullos, ha kivesznek belőle ezt-azt, akkor se sokkal marad alatta. Utoljára a KDE3 / Trinity volt az, ami még nem volt elszállt memóriaigényű. De nem csak grafikus felületekre igaz, egy vim sebességéhez sose fog felnőni egy Emacs se, nem hogy egy Visual Studio Code vagy Atom. Az mpv hardverigényének a közelében sem lesz soha a VLC, Totem, stb.. Azért vannak műfajok, ahol a bloat nem hagyható el sajnos: böngészők, játékok és launchereik, nagy vizuális szerkesztős megoldások (kép, videóvágás, stb.), ott nem nagyon lehet vele mit kezdeni. Nem is mindig a verzió újdonságától függ, bár alapvetően a bloatosodó szoftverek a verziók előrehaladtával tovább bloatosodnak. A baj szerintem nem is annyira a babzsákfejlesztőkkel van, hanem az öltönyös-nyakkendős multis menedzserekkel, akik a Powerpoint slideshow-ikban megálmodnak mindenféle csodálatos bullshitet, lehetetlen határidőket és célkitűzéseket, amiknek igazából szakmailag sose lesz értelme, de azért le lesz erőltetve mindenki torkán. Sőt, ma már sok user ezt a szopatást Stockholm-szindróma keretében igényli is, ha valami nem szép színes ikonos, végletekig lebutított, nem kér combos hardvert, az már gyanús, már amatőr, már nem lehet jó, mert nem integrálódik a többi bloat webes szutyokba, stb..

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem, ez a legjobb eset, hogy csak egyszer indul. Általában szükség van restartra, ha más nem, egy update miatt. Én se bootolok sokszor, napi 1-2, néha frissítésnél 3, de az már elég ritka. De már egy indulásnál sem mindegy, hogy eléd pattan a rendszer, és mindjárt dolgozhatsz, vagy még el kell menni wc-re, vagy kávé lefő, mire nekikezdesz annak, aminek akartál. Mondom, azt még megérteném, ha az SSD drága lenne, de használtan ilyen 7-10 ezer forintért mennek 120-250 giga között, újonnan sem sokkal drágábbak, 8-15 ezer a 120-250 gigás, 20k környéke a 500 gigás, 30k környéke az 1 terás, használtan olcsóbb. Azért nehogy valakinek ennyin múljon, főleg, ha dolgozik rajta, meg pénzt keres vele.

Meg mint írtam, nem csak a munkára használt szoftver indulása, hanem a többi is, leállási idők, indexelés, windowson háttérben vírusszkennelés, defrag, keresés, update, kutyafüle is teljesen más dimenzió lesz, azért a sok kis várakozási idő erre-arra a nap végén meredeken összeadódik. Hiszen ma már a rendszerek nagyon komplexek, nem csak a kernel, meg a munkaeszközöd fut, hanem egy csomó extra szolgáltatás, köztes absztrakciós réteg, lib, ezek mind tekerhetik a lemezt a háttérben, és ha HDD van a rendszer alatt, ennyitől csúnyán le tud térdelni. Ma már a HDD nagyon szűk keresztmetszet, és még annyiból is megéri az SSD, hogy ha HDD-ről használod a rendszert, akkor hiába vannak ott a sok giga RAM, meg a sok magos/szálas proci, el lesz pocsékolva, nem tudod kihasználni, mert a rendszer állandóan a lassú HDD-re fog várakozni tétlenül, durván bottleneckbe ütközöl. Már csak emaitt megéri SSD-re váltani, hogy a géped teljes potenciálját ki tudd hajtani. Sokan inkább pénzt pocsékolnak, lassúnak érzik a régi gépet, ezért vesznek helyette újat, holott a régi is teljesen használható lenne, csak egy SSD kéne bele, meg újrahúzni az OS-t, és máris szárnyalna, de azt hiszik, hogy a gép lassú, elavult. Ilyenkor sokszor jobban megéri az SSD-re upgrade, mint új gépet venni. Szerinte itt még a HUP-on is meglepődne sok ember, hogy egy 9-12 éves 1-2. genes Core i gép milyen durván gyors, ha HDD helyett egy SSD-vel (meg minimálisan elég RAM-mal) meg van támogatva, legyen az akár egy olcsó használt SATA2-es HDD, vagy valami rém olcsó 120 gigás SATA3, az ember a szemének nem hisz, mikor a bootidő lemegy 1-2 percről 5-8 másodpercre, és nem csak a boot gyorsabb ennyivel rajta, hanem arányosan minden művelet, ami lemez I/O-t igényel valamilyen szinten.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ilyenkor sokszor jobban megéri az SSD-re upgrade, mint új gépet venni. Szerinte itt még a HUP-on is meglepődne sok ember, hogy egy 9-12 éves 1-2. genes Core i gép milyen durván gyors, ha HDD helyett egy SSD-vel (meg minimálisan elég RAM-mal) meg van támogatva,

Tanusíthatom. Feleségem Core2Duo gépe kapott egy SSD-t, 8GB RAM-ot, és tökéletesen használható, gyors gép lett belőle.

Én a Gnome-al szívok, az tud meghízni + ilyenkor a teljesítmény is szépen lassan elfogy, teszem azt 3D-s alkalmazások 15-20 fps-el futnak a 60 fps helyett.

Szerintem adj fel bugticket-et, és kérj segítséget, hogy milyen plusz infó kellene nekik, hogy javítani tudják.

ez most VIRT vagy RES?

neked aztan fura humorod van...

Azert virt-ben sem illik... Oke, en is hasznaltam ilyen sztenderd java-minosegu fosadekokat ahol az volt a normalis hogy virt-ben megette a fizikai memoria ketszereset de egyebkent res-ben meg 25-30% korul mozgott viszonylag kiszamithatoan. De azert ne ez legyem mar  a sztenderd :)

Oke, en is hasznaltam ilyen sztenderd java-minosegu fosadekokat ahol az volt a normalis hogy virt-ben megette a fizikai memoria ketszereset de egyebkent res-ben meg 25-30% korul mozgott viszonylag kiszamithatoan.

Ahol törődnek a teljesítménnyel, az by design ilyen, egyszerűen azért, hogy gyorsabb legyen a futása, ettől nem lesz kevesebb szabad memóriád, olvass utána, hogy miért van így és akkor nem fogsz ez miatt mormogni.

Mondjuk a "teljesitmeny" es a "jython" szavakat egy mondatban nem feltetlen hasznalnam. Lassu volt mint a bun, azert is kellett parhuzamositanom ;) Es kb igy jott ki aranyaiban a matek: 16 jvm futott parhuzamosan, mindegyik  kapott 16g memoriat - kevesebbnel hisztikezett. Igy a 128 giga fizikai ram keteszereset ette meg virtualisan a varazsprogram, de a gep alapjaraton hasznalhato maradt mert a fizikai memoria csak kb 1/3-ig telt be. Neha szerencsetlenebb csillagzat eseteben felig, extrem esetben talan 1x volt csontta fagyas mikor nem vart jellegu adatkupacot daralt be.

De ja, az mondjuk egy megnyugtato featura volt hogy a jvm nem szivott annal tobb ram-ot igy virt-ben sem mint amennyit mondtunk neki. Legalabb ennyi!

Ja, el lehet baszni, főleg, ha az ember nem ért hozzá, amit csinál, ami Python esetén igen gyakori, hogy halvány fogalmuk nincs a skálázódásról vagy a teljesítményről, ilyenkor szokott jönni a Jython, mint mert lényegesen gyorsabb, mint a Python és lényegesen egyszerűbb, mint a CPython.

De ez messzire vezet és messze van abban a tekintetben, hogy miért sok a VIRT.

RES lehetett.

A System Activity nevű csodát szoktam használni(ctrl+esc re gyorsan előjön). Az most ezt írja: Memory:227 036K, Shared Mem: 167 088K.  A htop -ban meg ezt látom: VIRT: 2414M, RES: 386M, SHR: 164M.
Biztos vagyok benne, hogy a System Activity Memory sorában láttam a 6 Gb memóriát.

Egyébként azóta a probléma nem jelentkezett. Most már fokozottan figyelem a memória használatot és remélem okosabb leszek, ha megint megismétlődne.

Az Activity Monitor szép, színes, szagos, grafikonos, csak épp nem megbízhatóak az adatai. Az a mérvadó, amit a htop ír, ami egybeesik azzal, amit a top és a free parancs ír, persze vannak eltérések itt is, mert a htop a memóriahasználatba a buff/cache-t is beleszámolja, amit nem kéne. A tényleges memóriafogyasztás az a free -m parancs used+shared oszlopai összeadva, ami ugyanaz, amit a top mutat, ez a memória van úgy lefoglalva, hogy tényleg foglalás, a többi, a buffers, cache az felszabadul, ha igényli egy újonnan jött alkalmazás.

Egy folyamaton belül, meg a RES a mérvadó, a SHR csak statisztikai adat (jelezve, hogy a memória egy részét úgy használja, amiből más azonos libeket használó alkalmazás is profitálna külön betöltögetés és memóriahasznált nélkül), a VIRT-tel jellemzően nem szabad foglalkozni, mert az a progi által lejelentett maximális memóriaigény, amivel a folyamat gazdálkodhat, de ritkán használja azt ki.

A 227MB foglalás egy plasmánál elég szolidnak számít, azzal semmi baj nincs. Asztali környezetes mértékkel nézve nem sok. Sovány WM-hez képest viszont más műfaj. A régi Intel IGP-s archos laptopomon waylandes SwayWM-mel (Bash+Termite) a komplett rendszer idle memóriafogyasztása csak 140 MB, cakkpakk, ezt nem hiszi el hajbazer, hogy még a kedvenc XP-jét is veri. Az új, AMD APU-s laptopon az amdgpu driver meg az X + bspwm (+zsh és Alacritty) megdobja, az valami 240 MB környéke, 225 alá már dwm-mel sem tudtam lefaragni, az amdgpu driver és a bloatosabb új verziók miatt sajnos már lejjebb nem megy, igaz ez még mindig csak XP-s szint. Nem mintha nem lenne elég RAM-om, a 16 giga nagyja általában üresen áll, de nem kihasználatlanul, befogom ramdrive-nek, böngészőcache-nek, használja az integrált GPU, de a kernel is befogja fs cache-nek, buffernek, stb.. Inkább csak a kényelem, hogy nem fogy el soha a memória, nem kell leaktől félni, nem kell swap (mivel nem hibernálok), nem kell zram, egyéb. Nem is a memóriaspórolás a lényeg, hanem hogy ne legyen sallang a rendszeren, mert akkor azt a procinak se kell bootkor, alkalmazásindításokkor betöltenie, feleslegesen dolgoznia vele, így a rendszer gyorsabb lesz, nem lesznek betöltési mikrolagok. Ez a Linux legnagyobb előnye szvsz., hogy áttektinthetően, sallangmentesen lehet tartani a rendszert, ki lehet kerülni a sok bloatot, amit nem használsz, és amit a nagy DE-knél, meg commerce OS-eknél a multik betesznek ballasztként a rendszerbe, amit minden user teherként nyög, tolja maga előtt, minden betöltésnél, frissítésnél, veheti alá az erős vasat, extra RAM-ot.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Kinek mi a sallang meg a teher. Én speciel azért használok plasmát meg minden hozzávalót, mert ezt érzem kényelmesnek és gördülékenyen használhatónak. A hw-t meg kifizettem, hadd vegye csak igénybe :)
Értelem szerűen nem arról van szó, hogy zabáljon fel mindent - azt megteszik a browserek úgyis - de nem zavar, hogy nem 1-200 Mb-t eszik a DE, ha közben olyan szolgáltatásokat kapok, amik számomra praktikusak.

Jelen állás szerint amúgy most egy 8Gb RAMmal szerelt vason vagyok, start után ha feláll a desktop, akkor ebből kb 22-24%-ot foglal úgy, hogy azért néhány szolgáltatás is indul vele (pl insync, syncthing, akonadi-s dolgok, kdeconnect) és indul automatikusan 2 app (KeepassXC, telegram). Ezt én nem érzem tragédiának, főképp annak fényében, hogy egy browser 10-12 tabbal pillanatok alatt eszik ennyit.

Azért 8 giga RAM-os gépnél elég sok a 22-24%-os boot utáni RAM fogyasztás. Én épp ezért használok csak minimalista programokat, azoknak függősége sincs nagyon, szolgáltatás se nagyon indul semmi egy NTP-n kívül. KeepassXC helyett saját GNU GPG-vel kódolt jelszóadatbázist használok, amit a saját scriptem kezel, jelenít meg egy terminálablakban nem kell szolgáltatásként indulnia, bár míg KeepassXC-t meg Keepass CLI-t használtam, azoknak sem kellett szolgáltatásként indulniuk.

Amiben viszont teljesen egyetértek, az a browser. Hiába is sovány a rendszer, a böngésző mindenképp bloat, persze lehet ellene védekezni reklámblokkolással, scriptblokkolással, kevesebb füllel, addonok számát minimalizálva, Chrome-alapú megoldások helyett Firefox-ot használva, de a net, meg a böngészők bloatok lettek, ez ellen nem lehet tenni. A böngészés nálam is megdobja a memóriahasználatot 1-2 gigával, kb. 20 fülnél és pár lejátszott netes videó után.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧