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í
×
    dnes 13:11 | Zajímavý článek

    Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.

    Ladislav Hagara | Komentářů: 1
    dnes 12:33 | IT novinky

    Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.

    Ladislav Hagara | Komentářů: 0
    dnes 11:44 | IT novinky

    Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.

    Ladislav Hagara | Komentářů: 1
    dnes 11:33 | IT novinky

    Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.

    Ladislav Hagara | Komentářů: 4
    včera 18:11 | IT novinky

    Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).

    Ladislav Hagara | Komentářů: 0
    včera 15:22 | Komunita

    V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).

    Ladislav Hagara | Komentářů: 0
    včera 15:00 | Nová verze

    Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 5
    včera 12:22 | Pozvánky

    Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.

    jose17 | Komentářů: 0
    včera 04:44 | IT novinky

    Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.

    Ladislav Hagara | Komentářů: 16
    19.5. 23:22 | Zajímavý software

    Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.

    Ladislav Hagara | Komentářů: 12
    Jaký je váš oblíbený skriptovací jazyk?
     (60%)
     (23%)
     (9%)
     (2%)
     (0%)
     (0%)
     (6%)
    Celkem 53 hlasů
     Komentářů: 5, poslední včera 20:57
    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

    Memory overcommitting - ráj nebo peklo?

    25.5.2005 20:33 | Přečteno: 1791× | 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.