abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    včera 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    včera 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 2
    včera 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 24
    včera 09:55 | IT novinky

    Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.

    Ladislav Hagara | Komentářů: 2
    včera 09:33 | IT novinky

    Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.

    Ladislav Hagara | Komentářů: 0
    včera 08:11 | Nová verze

    Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    29.4. 20:55 | Nová verze

    Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.

    Ladislav Hagara | Komentářů: 0
    29.4. 16:22 | Nová verze

    Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.

    Ladislav Hagara | Komentářů: 0
    29.4. 15:55 | Pozvánky

    Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových

    … více »
    Zdenek H. | Komentářů: 2
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 495 hlasů
     Komentářů: 19, poslední včera 11:32
    Rozcestník

    Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.


    NAVRCHOLU.cz
    Aktuální zápisy
    Nejčtenější za poslední měsíc Nejkomentovanější za poslední měsíc

    Memory overcommitting - ráj nebo peklo?

    25.5.2005 20:33 | Přečteno: 1786× | Ze života

    Je příjemné alokovat si více paměti, než je k dispozici. Na druhou stranu, má to dost nepříjemná úskalí. Mnohokrát jsem o tom přemýšlel, ptal jsem se řady lidí na jejich názor, ale jisté zůstává jenom jedno - je to záležitost vysoce kontroverzní.

    Pravděpodobně všichni vědí, o co jde - ale raději to aspoň ve stručnosti nastíním:

    Pokud se alokuje paměť (např. funkcí malloc() v jazyce C), paměť k dispozici buďto je (a v tom případě volání skončí úspěchem, paměť se alokovala), anebo není (a volání skončí neúspěchem). Protože programy obvykle alokují více paměti, než jí pak skutečně využijí (je to z různých důvodů, někdy je skutečné využití velmi malé, např. u málo vytížených serverových aplikací), používá se technika zvaná overcommitting (česky bych řekl třeba "přealokace", ale není to přesné). Z pohledu aplikace to vypadá tak, že alokace skončí vždycky úspěšně, i když dané množství k dispozici není. Většinou to není problém, systém úspěšně funguje.

    Problém nastane, když je alokováno víc paměti, než může systém dát k dispozici (když selžou veškeré pokusy o uvolnění paměti). Pak nastupuje hrubé násilí - v Linuxu reprezentované procesem oom-killer. Ten se spustí ještě dřív, než k dané situaci dojde (spouští se při poklesu volné paměti pod určitý práh) a vytipuje vhodné kandidáty na odstřelení. Pokud už skutečně není volná paměť, oom-killer zlikviduje proces, který byl nejžhavějším kandidátem. A tak pokračuje tak dlouho, dokud nejsou požadavky uspokojeny.

    Otázka je, zda je použití overcommittingu vůbec výhrou. Jednoznačná odpověď není, čím dál víc jsem ale přesvědčen, že minimálně v prostředí, kde požadujeme stabilitu, své místo nemá (jen pro úplnost - overcommitting lze snadno vypnout). Poměrně snadno lze totiž takový systém destabilizovat.

    Před časem jsem si tu stěžoval na problémy s X.org v souvislosti se zběsilou alokací paměti. Tato alokace souvisela s prohlížečem Opera, nicméně paměť alokoval X server. A nejen že alokoval, ale také nějak používal (podrobnosti neznám), takže brzy (za několik sekund) došlo k tomu, že se vyčerpala veškerá paměť včetně swapu a došlo na nejhorší. To co se dělo dál, nešlo předem předvídat - oom-killer (aspoň ten v jádře 2.6.10) je špatný střelec a svůj cíl si často vybere nevhodně. Takže i když by měl být sestřelen původce (tj. X server; správněji spíš Opera, ale takovou inteligenci od "ničitele" chtít nemůžeme), odnesl to často jiný, zcela nevinný proces.

    Jaké nebezpečí z toho plyne, je zřejmé. Jakýkoli program, který v systému běží, ho snadno může zásadním způsobem poškodit, aniž by dělal nějakou složitou činnost. Stačí pouze alokovat paměť. Bez overcommittingu by jeho alokace byla prostě najednou neúspěšná, a i když by se mu podařilo vyčerpat volnou paměť, přímé následky by nebyly. Kdežto takto by mu mohlo za oběť padnout i několik procesů, než by byl sám sestřelen.

    Nechávám celou věc otevřenou, jednoznačný názor jsem si neudělal. Jen si říkám, zda cena, která se platí za možnost "kouzelného nafouknutí" paměti, není příliš vysoká.

           

    Hodnocení: -

    zatím nehodnoceno
            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    25.5.2005 20:59 Michal Marek (twofish) | skóre: 55 | blog: { display: blog; } | Praha
    Rozbalit Rozbalit vše malloc vs. brk, mmap
    Důvod pro tuhle strategii může být ten, že glibc si paměť alokuje po větších kusech, aby nemusela moc často volat brk() nebo mmap(). Podobně se chovají některé algoritmy v jiných knihovnách / aplikacích (např. při zvětšování pole se malloc()uje dvojnásobek původní velikosti). Tudíž pár stránek nakonec zůstane ležet ladem. Ale zdůvodnění od někoho fundovanějšího by mě docela zajímalo :-)

    PS: limity nejsou špatná věc...
    Luk avatar 25.5.2005 21:07 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: malloc vs. brk, mmap
    Tohle je jasné. Ostatně u souborů se používá něco podobného - také lze vytvořit soubor určité velikosti, ale bloky se ve skutečnosti alokují až v případě potřeby ... a tehdy už nemusí být k dispozici (ale tam to není taková tragédie).

    Jinak ještě k oom-killeru - nevím, jak kvalitně funguje teď, ale v jádrech řady 2.4 s ním byly takové problémy, že byl v jednu chvíli prakticky odstraněn (resp. nevybíral kandidáta, nýbrž sestřelil proces, který potřeboval paměť).
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    25.5.2005 21:18 doubleZ | skóre: 24 | blog: smazano
    Rozbalit Rozbalit vše Re: malloc vs. brk, mmap
    kernel 2.4.29, me sestrelil nejen proces, ktery potreboval pamet, jez neexistuje, ale i jeho rodicovsky proces se vsemi ostatnimi child
    25.5.2005 21:20 Michal Marek (twofish) | skóre: 55 | blog: { display: blog; } | Praha
    Rozbalit Rozbalit vše Re: malloc vs. brk, mmap
    oom_kill.c ve 2.6.11 na mi první pohled přijde stejný jako ve 2.4, a funguje tak, že X server by neměl zabít skoro nikdy: Zvýhodňuje totiž procesy běžící pod rootem a procesy, které spotřebovaly hodně CPU času (komentář: "There is no particular reason for this other than that it turned out to work very well in practice." :-)).

    Ono zabít X server SIGKILLem by stejně nejspíš znamenalo reboot, protože bůhví v jakém stavu by zůstala grafická karta...
    Luk avatar 25.5.2005 21:43 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: malloc vs. brk, mmap
    Ale v případě, který jsem popsal (a který se mi s X.org stával - nyní s XFree86 už naštěstí ne :-)), alokoval právě X server (ale čert ví proč - bylo to kvůli nějakému požadavku Opery). Pokud je to právě takhle, tak je chování oom-killera logické, ale v daném případě nic neřeší - dokud žije X server nebo Opera, problém přetrvává.

    Jinak po odstřelení X serveru se to chovalo korektně, normálně nastartoval (s kartou nVidia, modul "nv"), reboot nebyl potřeba. Ale s danou verzí Opery + X.org se dala situace (zobrazením toho "správného" webu) kdykoliv navodit znovu (čili bylo to systematické).
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    25.5.2005 21:55 doubleZ | skóre: 24 | blog: smazano
    Rozbalit Rozbalit vše Re: malloc vs. brk, mmap
    tak se mi to povedlo :-) mno, vystup byl fakt divnej ;) na tty7 (alt + F7) jsem mel pochybne znaky vypadajici jako hebrejstinoazbukocinstina a nova xka nabehla na 8micku
    25.5.2005 21:17 doubleZ | skóre: 24 | blog: smazano
    Rozbalit Rozbalit vše asi je
    myslim si, ze nekdy tato cena vysoka opravdu je, zrovna pred dvema dny jsem si takto nechal prizabit Xka, kdyz jsem za pomoci Wilbura (GIMPU :) naprosto vymrhal ramku i swap, kdy alokace byla provedena tak obrovska,ze sezrala vsechno mozne misto, a takovy webserver, ktery lezel ladem a skladem a mam ho tu jen pro ladeni svych stranek, zustal bez povsimnuti a me to zabilo naprosto vsechno, veskerou rozdelanou praci... jenze kdyby nedoslo k realokacim pameti pro httpd tak by nenastaly takovehle problemy... nevim, je to sporne
    25.5.2005 21:47 unchallenger | skóre: 69 | blog: unchallenger
    Rozbalit Rozbalit vše Re: asi je
    U GIMPu je to IMO jen tvoje blbost, protože si tam můžeš nastavit, kolik paměti se smí spotřebovat na tile cache, což je ten velký žrout paměti. Takový valgrind je mnohem záludnější.
    25.5.2005 21:34 Pmx
    Rozbalit Rozbalit vše Když to jde snadno vypnout...
    Když to jde snadno vypnout (jedním echo někam do /proc jestli se nemýlím), tak si snad každý může vybrat, co pro něj lepší jest, ne? :) Lepší, než kdyby vyšší síly (kernel maintaineři) rozhodly takto za nás. Takže moc nechápu kritický tón tohoto článku, ale jinak je přínosný popisem problematiky, která podle mě Jediné správné(TM) řešení zatím ani nemá...

    Tak mě napadá - dal by se udělat prográmek, který v takové těžké chvilce paměťového nedostatku vytvoří na disku nějaký soubor jako další (dočasný) swap...
    25.5.2005 23:21 Libor Klepac | skóre: 45 | Mýto
    Rozbalit Rozbalit vše Re: Když to jde snadno vypnout...
    Urine should only be green if you're Mr. Spock.
    25.5.2005 23:45 Triton
    Rozbalit Rozbalit vše Dobrý tip
    Tak jsem si na jednom desktopu(kernel 2.6.11.10) defaultně ten overcommit vypnul a zkusím alespoň týden testovat, jestli to bude použitelný.
    26.5.2005 00:10 Mikuláš Patočka
    Rozbalit Rozbalit vše overcommit
    Kdyby overcommit byl vypnut (což snad ani nejde), byl by na tom systém ještě hůř ... nějaký proces sežere veškerou paměť, a ty se pak už nepřihlásíš ani ze sítě ani z konzole (protože programu sshd a login je odepřena paměť). V případě, že jseš přihlášený, tak toho žrouta paměti taky nezabiješ, protože program kill nedostane žádnou paměť. Eventuálně bash vůbec nedostane paměť, do které si ukládá stisklé klávesy, takže ani nic nenapíšeš.

    Pokud vypneš oom-killer, tak ti to zastřelí proces, který o paměť naposled žádal, takže k výše zmíněnému scénáři může a nemusí dojít.

    Nejlepší by v takové situaci bylo vytipovat uživatele, jehož procesy žerou nejvíc paměti a tomu zabít proces, který nejvíc žere.

    X-server se bohužel zabít nesmí, protože nechá grafickou kartu v neznámém stavu (schválně si ho zkus zabít pomocí kill -9 --- ale pak už ti nezbyde nic jiného než ctrl-alt-del).
    26.5.2005 02:05 Martin Vidner
    Rozbalit Rozbalit vše Re: overcommit
    V případě, že jseš přihlášený, tak toho žrouta paměti taky nezabiješ, protože program kill nedostane žádnou paměť.
    Proto je taky kill zabudovany prikaz shellu (prinejmensim bash a zsh).
    Luk avatar 26.5.2005 08:39 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: overcommit
    1. Overcommit vypnout jde (viz třeba "man malloc")

    2. Rozdíl je v tom, že bez overcommittingu nějaký proces "jen" nedostane paměť (ale může žít dál, pokud je napsaný tak, aby se z toho vzpamatoval), kdežto oom-killer rovnou zabíjí, což není úplně nejčistší.

    3. X server nejen že se zabít smí, ale on se dokonce i zabíjí (viz můj příklad) - aspoň v jádře 2.6.9 ve FC. Zabití pomocí kill -9 nemá fatální následky, dopadne (aspoň u mě) úplně stejně, jako kdybych stiskl Ctrl-Alt-BkSp.
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    26.5.2005 14:59 doubleZ | skóre: 24 | blog: smazano
    Rozbalit Rozbalit vše Re: overcommit
    ano, smi, stava se to, viz take muj priklad, nevim kde kdo vycetl ze nesmi, me to melo temer shodny efekt jako Ctrl+Alt+BkSp, jen se spustil na novym screenu a stary nechal spadly, myslim, ze kdybych na nem dodatecne dal reboot xek tak by tam zas nabehly...
    26.5.2005 09:36 #Tom
    Rozbalit Rozbalit vše Overcommit -> /dev/null
    Overcommit je jednoznačně na škodu, uvítal bych, kdyby byl implicitně vypnutý, nelíbí se mi, že při startu systému musím použít tohle:
      echo 2 > /proc/sys/vm/overcommit_memory
    
    Nejhorší zkušenosti s nedostatkem přealokované paměti mám taky pod Xkama, pravým původcem je pro změnu Mozilla/FireFox (je jedno, co je to za verzi). Poprvé jsem si toho všiml na své celkem nevinně vyhlížející stránce s naskenovanými skripty. Na novějších počítačích s větší pamětí (>= 512 MB), nebo i na starších s Konquerorem (nebo s Mozillou/IE pod Windows) nehrozí žádné nebezpečí, pod Linuxem s Mozillou/FireFoxem a 256 MB RAM+128 MB swapem to ale končí špatně...

    P.S.: Ta stránka obsahuje jen 96 PNG obrázků s celkovou velikostí cca 2,5 MB.
    26.5.2005 10:48 petr_p
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Tech 96 obrazku ale ma 84 Mpixelu. Pak taky musis zvazit, ze drawable Firefoxu ma nejakou barevnou hloubku. Takze kdyz to zabere pres 200 MB, tak se neni cemu divit.
    26.5.2005 11:07 #Tom
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Chybička se vloudila - nahrál jsem tam jen 61 obrázků (1.8 MB), o to ale nejde. Rozměry jsou vždy přibližně 1000x1500, tak mi vychází cca 90M pixelů. To je hodně, FireFox zřejmě nepočítá s tím, že mu budou podstrkovány takovéto stránky. (Konqueror je v tomto o dost lepší.) Ale hlavní je, že s povoleným overcommitem tak může Linux úplně spadnout úplně snadno jen kvůli otevření jednoduché (a - to uznávám - ne zrovna pěkně udělané) stránky.
    26.5.2005 15:02 Libor Klepac | skóre: 45 | Mýto
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    hmm

    echo "vm.overcommit_memory = 2" >> /etc/sysctl.conf

    ? ;-)
    Urine should only be green if you're Mr. Spock.
    26.5.2005 16:29 #Tom
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Rada je to pěkná, jenže obsah souboru /etc/sysctl.conf se sám nezavede, nejdřív někdo či něco musí spustit třeba /sbin/sysctl -p. Takže se tím neřeší nic... Nebylo by od věci si ten overcommit zakázat rovnou ve zdrojácích jádra ;-)
    26.5.2005 16:32 Libor Klepac | skóre: 45 | Mýto
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    hmmm ;-)
    :cat /etc/init.d/procps.sh  | grep sysctl
    # /etc/init.d/procps: Set kernel variables from /etc/sysctl.conf
    [ -x /sbin/sysctl ] || exit 0
                   if [ ! -r /etc/sysctl.conf ]
                   eval "/sbin/sysctl $n -q -p $redir"
    
    Urine should only be green if you're Mr. Spock.
    26.5.2005 16:37 Libor Klepac | skóre: 45 | Mýto
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    no ten grep dopadl teda ;-)
    Urine should only be green if you're Mr. Spock.
    26.5.2005 16:40 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Já to tak píšu odjakživa a ještě mi nikdo nic neřekl :-)
    Copak toho není dost?
    26.5.2005 16:45 Libor Klepac | skóre: 45 | Mýto
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    ja myslel, ze pod sebe prisly ty radky tak, ze to vypada, ze kdyz tam neni ten soubor, tak ze se pouzije ;-)
    Urine should only be green if you're Mr. Spock.
    26.5.2005 16:47 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Je to grepnutý, tak to dá rozum… Já myslel, že myslíš to s tím grepem a catem ;-)
    Copak toho není dost?
    26.5.2005 16:49 #Tom
    Rozbalit Rozbalit vše Re: Overcommit -> /dev/null
    Proč ne ;-) Ale není to v každé distribuci, přidávat něco takového jen kvůli overcommitu je na nic...

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.