Üdv,
Egy Ubuntu alatt a top ezt mutatja a Chrome-ról (virt: 1133GB):
https://freeimage.host/i/mEmyLg
Kicsit soknak találom az értéket. Normál asztali gép.
Ez valami bug lehet?
- 498 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
Chrome annyi memóriát használ, amennyi a gépedben van. Simán.
- A hozzászóláshoz be kell jelentkezni
De ennyi nincs.
- A hozzászóláshoz be kell jelentkezni
Nálam is 1130 a virt.
- A hozzászóláshoz be kell jelentkezni
Gondolom meglep, hogy igen régóta virtuális memóriának számít a HDD/SSD fix tartalma is, és az is, hogy a Chrome igen régóta minden egyes fület sandbox-ban futtat, vagyis per tab behúzza virtuális memóriaként saját magát, nem válogatva, hogy mi az, ami kell vagy nem kell, mert a kernel úgyis csak azt a részét húzza be memóriába, amit épp futtatni kell, így spórolva valódi memóriát hasznos dolgokra.
Szóval nem bug és nem kell ennyi memóriának lennie a gépedben, a virtuális memória mérete lehet többszöröse a swap méretének, ahova azok a dolgok kerülnek, amelyek nincsenek fixen tárolva a HDD/SSD-n. Ez annyira így van, hogy akár konkrétan kikapcsolt swap mellett lehet ~30 GB virtuális memória: https://imgur.com/a/SivtDfw
- A hozzászóláshoz be kell jelentkezni
+1, bónuszként a kérdezőnek mmap(2)
- A hozzászóláshoz be kell jelentkezni
sbrk(2)-vel nekem csak 40 teráig sikerült eljutnom... szaralinux :)
- A hozzászóláshoz be kell jelentkezni
Gondolom meglep, hogy igen régóta virtuális memóriának számít a HDD/SSD fix tartalma is,
Nekem ottan azt az 1.1+ terát egy 32 gigás /home mellett volt képes összehozni, ahova volt úgy valami irás-joga a processzeknek ;) Tehát, minden file-t is bemmappel, nem 1x, nem 2x, hanem 35x, és akkor úgy :)
- A hozzászóláshoz be kell jelentkezni
Jó tudni, hogy a háttértárakon lévő fájlokat is mapeli, ez teljesen új nekem.
Azon a 8 gigás gépen azért elég határon van a képernyőkép alapján a memófogyasztás, jó a rendszer a cache-t el tudja dobni, ha kell a memória, de ilyen java, docker, kubernetes, egyéb rémségek futtatásához elég vékony az a 8 GB.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Jó tudni, hogy a háttértárakon lévő fájlokat is mapeli, ez teljesen új nekem.
Hát pedig szerintem majdnem kezdetek óta létező feature...
Azon a 8 gigás gépen azért elég határon van a képernyőkép alapján a memófogyasztás, jó a rendszer a cache-t el tudja dobni, ha kell a memória, de ilyen java, docker, kubernetes, egyéb rémségek futtatásához elég vékony az a 8 GB.
Ezt had én döntsem el.
- A hozzászóláshoz be kell jelentkezni
Jól van, én tőlem eldöntheted, hogy elég, az ábra meg azt mutatja, hogy nem. Félre ne értsd, nekem mindegy, hogy a te gépedben mennyi RAM van, nekem 8 giga elég lenne az én átlagos, lightos, együgyű felhasználásomhoz, csak én ilyen menő hypeword-ös jóságokat, amiket soroltam, nem futtatok. Az se látszik, hogy felhős gép, helyi virtuális gép, fizikai, vagy mi, nem tudom, hogy ennek megfelelően mennyi lenne bővíteni. Ha nem a legújabb DDR5, legjobb időzítésekre, és legnagyobb frekikre mész rá, illetve nincs odaforrasztva, akkor ma már a RAM ára nem olyan húzós tétel, főleg 16 giga nem valami luxus. A 32-64 gigáról el lehet vitatkozni, az valóban erősen felhasználásfüggő.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Jól van, én tőlem eldöntheted, hogy elég, az ábra meg azt mutatja, hogy nem.
Az ábra azt mutatja, hogy pont jól van terhelve az adott node, teljesen ki van használva a fizikai memória, nincs felesleg, amit kifizettem ugyan, de nem használok.
Félre ne értsd, nekem mindegy, hogy a te gépedben mennyi RAM van, nekem 8 giga elég lenne az én átlagos, lightos, együgyű felhasználásomhoz, csak én ilyen menő hypeword-ös jóságokat, amiket soroltam, nem futtatok.
Az én gépemben speciel 32 GB van, de nem tudom, hogy jön ide...
Az se látszik, hogy felhős gép, helyi virtuális gép, fizikai, vagy mi, nem tudom, hogy ennek megfelelően mennyi lenne bővíteni. Ha nem a legújabb DDR5, legjobb időzítésekre, és legnagyobb frekikre mész rá, illetve nincs odaforrasztva, akkor ma már a RAM ára nem olyan húzós tétel, főleg 16 giga nem valami luxus.
Na, figyelj, ha halvány fogalmad nincs arról, hogy milyen gépről van szó és az a gép minek a részeként mit futtat és annak milyen metrikák alapján elég mennyi memória, akkor miért jön az a kényszered, hogy megmondjad a tutit?
A 32-64 gigáról el lehet vitatkozni, az valóban erősen felhasználásfüggő.
Ha az adott node memória igénye ~6GB, akkor mégis mi a bánatos lófasznak tegyek bele 32 vagy 64 GB memóriát?
- A hozzászóláshoz be kell jelentkezni
Rosszul értelmezed a számokat. a RES és SHR oszlopokat kell nézni, azok mérik a valós fogyasztást, a kettő közül is a RES (resident) fontos (az SHR, azaz shared csak azt mutatja, hogy e RES-ből mekkora hányad a dinamikus libek, amit más folyamatok is használhatnak, azaz lehet közös keresztmetszet más folyamatokkal). A virtuális memória csak egy maximális címtérigény, hogy annyit jelentett be az alkalmazás, de azt nem foglalja le ténylegesen is, vagyis nem azonnal, tipikusan nem egyszerre.
Egyáltalán nem Chrome-specifikus. Nálam most jelenleg a Firefox kb. 30-35 füllel szálanként ilyen 11,5 és 19 giga VIRT memóriát jelez a htop-ban, közben meg ennyit nem foglal, mert az össz memóriafogyasztás csak kb. 7,5 giga (a boot utáni idle csak 285 mega), a 16 giga fizikai memóriából (swap nincs), a böngészőn kívül fut 2-3 terminálablak kisebb bizbaszokkal (htop, man pages, nvim). RES-ben ugyenezek a Firefox folyamatok/szálak csak 524M és 144M memóriát mutat, az a reális fogyasztás. Persze, ez sem kevés, de nem lehet mit csinálni, a böngészők már sok éve ilyen bloatak, sok millió kódsoros monstrumok, és a soydevek is telerakták JS hegyekkel és webfontokkal az oldalakat, azoknak meg kell a memória, erőforrás. Ma már a rendszer többi része is nagy, ezért nem értették, mikor írtam a 486-os topikban, hogy ki akarna már olyan régi hardveren modern Linux kernelt futtatni, esélytelen.
Azt nézd, amit a free, sima top, ps mutat, azok a tényleges értékek, minden más, amit ilyen btop, glances, htop, grafikus feladatkezelők, stb. mutatnak, az nem pontos, nem egységes, valamelyik beleméri a cache-t is, máshogy számolják bele a swap-ot, stb..
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ismerem a res, shr, virt mezőket, csak nem gondoltam, hogy a virt-be "minden is" beletartozik. 🙂
- A hozzászóláshoz be kell jelentkezni
A minden is kitételről én se tudtam, de ezt enélkül is ki lehet találni. Ha 1,1 TB-os fogyasztást mutat a VIRT oszlop, onnan rájöhetsz, hogy annyit nem foglalhat, mert a RAM, swap, egyéb SSD tárterületed sincs összeadva annyi, gyanút kell ilyenkor fogni.
Linuxon egyébként nagyon nehéz mérni a TÉNYLEGES memóriafoglalást. Mivel csak ilyen map-ok meg page-ek vannak összevissza, a kernel elég nehezen számolja, jelzi ki, hogy egy adott processhez pontosan mi tartozik, mennyivel emeli a fogyasztást, csak ilyen-olyan trükkök mentén számolt jellemző van, VIRT, RES/RSS, SHR, USS (Unique Set Size), PSS (Proportional Set Size). Aztán mindenki azt veszi ebből figyelembe, ami neki fontos. A valósághoz egyébként az SHR szokott a legközelebb lenni, a többinek a jelentősége marginális, ha csak dekstop user, meg egyszeri szerveres admin valaki.
De nem csak a folyamatok memóriafoglalásának a mérése problémás, de a szabad memória is, megint mindenféle page-ek meg töredezés miatt. A free-nél is megtévesztő, hogy különbséget tesz free és available memory között, aki ehhez nem szokott hozzá, nem érti miért van, annak elég körmönfont, ráadásul BSD-ken, ahol nincs GNU coreutils free parancs (bár talán fel lehet szögelni), csak vmstat, ott még nehezebb kijelezni, hogy akkor most mennyi a szabad memória, hála istennek a top akkor is ott van. Hasonlóan a load average értelmezése is trükkös, mert eleve csak CPU, és beleszól, hogy hány szálad van, így közvetlenül össze sem vethető, mert egy 2 magos gépen az 1,5-ös load az nem annyi, mint egy 16 magoson, ráadásul az I/O nincs belemérve, már ebből is félreértések szoktak lenni.
Én egyébként nézni szoktam az RES-en kívül az SHR-t is, mivel minimalizmus-fetisiszta vagyok, és ha van kb. két egyforma RES foglalású megoldás, de az egyiknél az SHR arány nagyobb, az azt jelenti, hogy több példányban futtatva, illetve más olyan programokkal futtatva, ami azonos libeket használ, memóriahatékonyabb. Ugyanez a VIRT-re, ha van két olyan megoldás, ami RES és SHR tekintetében is elég hasonló, akkor a VIRT eligazíthat, hogy melyik a bloatabb, melyik töltögetett be több adatot, stb.. De a felhasználók többségének ezt a sok összevissza metrikát kár beletenni a top/taskmanager-típusú programokban, csak arra jó, hogy a sok mindenféle adat összezavarjon valakit.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni