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 01:00 | Nová verze

Byla vydána verze 1.27 programovacího jazyka Rust (Wikipedie). Z novinek je nutno zmínit podporu SIMD (Single Instruction Multiple Data). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 0
včera 16:22 | IT novinky

CEO Intelu Brian Krzanich rezignoval (tisková zpráva). Oficiálním důvodem je "vztah na pracovišti". S okamžitou platností se dočasným CEO stal Robert Swan.

Ladislav Hagara | Komentářů: 23
včera 14:11 | Komunita

Konsorcium Linux Foundation ve spolupráci s kariérním portálem Dice.com zveřejnilo 2018 Open Source Jobs Report. Poptávka po odbornících na open source neustále roste.

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

Na stránkách linuxové distribuce Ubuntu Studio byla publikována příručka Ubuntu Studio Audio Handbook věnována vytváření, nahrávaní a úpravě zvuků a hudby nejenom v Ubuntu Studiu. Jedná se o živý dokument editovatelný na jejich wiki.

Ladislav Hagara | Komentářů: 0
včera 12:11 | Zajímavý projekt

Společnost Red Hat koupila na konci ledna společnost CoreOS stojící mimo jiné za odlehčenou linuxovou distribucí optimalizovanou pro běh kontejnerů Container Linux. Matthew Miller, vedoucí projektu Fedora, představil v článku na Fedora Magazine nový podprojekt Fedory s názvem Fedora CoreOS. Fedora CoreOS má být to nejlepší z Container Linuxu a Fedora Atomic Hostu. Podrobnosti v často kladených otázkách (FAQ) a v diskusním fóru.

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

Po více než devíti měsících vývoje od vydání verze 11.0 byla vydána verze 12.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 10
20.6. 20:00 | Upozornění

Výbor pro právní záležitosti Evropského parlamentu (JURI) dnes přijal své stanovisko ke kontroverzní novele směrnice, která v EU upravuje autorské právo v online prostředí (Pro: 14, Proti: 9, Zdrželo se: 2). Další kolo legislativního procesu proběhne na začátku července.

Ladislav Hagara | Komentářů: 31
19.6. 19:55 | Zajímavý článek

Byly zveřejněny (pdf) podrobnosti o kritické bezpečnostní chybě CVE-2017-12542 v HPE iLO 4 (Integrated Lights-Out), tj. v proprietárním řešení společnosti Hewlett Packard Enterprise pro vzdálenou správu jejich serverů. Bezpečnostní chyba zneužitelná k obejití autentizace a k vzdálenému spuštění libovolného kódu byla opravena již v květnu loňského roku ve verzi 2.53.

Ladislav Hagara | Komentářů: 20
19.6. 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
19.6. 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (23%)
 (4%)
 (7%)
 (3%)
 (11%)
Celkem 237 hlasů
 Komentářů: 39, poslední včera 17:44
    Rozcestník

    Jaderné noviny – 24. 4. 2014: Vyšší limity sdílené paměti

    12. 5. 2014 | Luboš Doležel | Jaderné noviny | 2971×

    Aktuální verze jádra: 3.15-rc2. Citáty týdne: netcat, Andrew Morton. Změna výchozích limitů sdílené paměti.

    Obsah

    Aktuální verze jádra: 3.15-rc2

    link

    Aktuální vývojová verze jádra je 3.15-rc2 vydaná 20. dubna. Linus k ní řekl: A sedmého dne rc vydání opět povstalo, jak pravily skripty sepsané na kernel sumitu roku 2004.

    Stabilní aktualizace: verze 3.13.11 vyšla 22. dubna. Greg řekl, že odteď přestane řadu 3.13 udržovat, ale jaderný tým Ubuntu bude v podpoře pokračovat až do dubna 2016.

    Citáty týdne: netcat, Andrew Morton

    link

    Vítáme vás u nejzbytečněji komplikovaného formátu vydání alba od netcatu.

    V tomto repozitáři si můžete zkompilovat vlastní jaderný modul, vytvořit zařízení /dev/netcat a poslat jeho výstup rourou do přehrávače:

    ogg123 – < /dev/netcat 

    Tento repozitář obsahuje data stop z alba ve zdrojových souborech, které (v zájmu složitosti) pocházejí z .ogg souborů, které byly kódovány z .mp3 souborů, které byly kódovány z finálních .wav souborů, které byly generovány z konečných mixážních .wav souborů z ProTools, které byly vytvořeny z 24stopé analogové pásky.

    Brandon Lucia, Andrew Olmstead a David Balatero vydali nové album

    Řekl bych, že první věcí by bylo přidat tam varování a počkat, jestli zjistíme, kolik kódu bude takovou změnou zasaženo. Do printk přidej „prosím pošlete mail Keesovi“ ;-) Jednou jsem to udělal, je tomu mnoho let. Dostal jsem spoustu e-mailu. Znovu jsem to už neudělal.

    -- Andrew Morton

    Změna výchozích limitů sdílené paměti

    link

    Limity sdílené paměti System V v linuxovém jádře jsou od úplného začátku nastaveny na stejnou hodnotu. Ačkoliv uživatelé mohou tento limit navýšit, jelikož objem paměti očekávaný moderními aplikacemi během uplynulých let vzrostl, otázkou nadále zůstává, jestli má smysl výchozí nastavený změnit – je tu i možnost jej zcela odstranit. Jak se už ale často stává, ukázalo se, že se najdou uživatelé, kteří si navykli na to, že se limit sdílené paměti chová určitým způsobem, takže jeho změna by vedla k nečekaným důsledkům. Proto i když asi nikdo není se současným výchozím nastavením spokojen, není jednoduché určit, jak jej opravit.

    Sdílená paměti dle System V (SHM) je běžně užívána jako prostředek ke komunikaci mezi procesy; skupina spolupracujících procesů (například relací databáze) může sdílet segment paměti až do maximální velikosti povolené systémem. Tento limit může být vyjádřen v bajtech na sdílený segment (SHMMAX) a v podobě celkového počtu stránek použitých pro všechny segmenty (SHMALL). Na Linuxu byla výchozí hodnota SHMMAX vždy 32 MB a výchozí hodnota SHMALL je definována jako:

    #define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
    

    kde SHMMNI je maximální počet SHM segmentů – standardně 4096 – což zase dává výchozí hodnotu SHMALL 2097152 stránek. I když mají dobře známé výchozí hodnoty, tak hodnoty SHMMAX a SHMALLL je možné měnit pomocí sysctl. Je tu také související parametr nastavující minimální velikost sdíleného segmentu (SHMMIN); na rozdíl od ostatních limitů prostředků je tento nastaven na jeden bajt a není možné jej měnit.

    I když se většina uživatelů shodne, že jeden bajt je rozumnou minimální velikostí segmentu, to samé se nedá říct o SHMMAX; 32 MB není pro dnešní nenažrané procesy mnoho. Pravdou je, že se na produkčních systémech v posledních letech stalo navyšování SHMMAX rutinou a u nejpopulárnějších aplikací používajících SHM je doporučování navýšení běžnou praxí.

    Proto nepřekvapí to, že se v komunitě řešilo, že už je čas tento limit navýšit na nějakou vhodnější hodnotu, a tak 31. března Davidlohr Bueso poslal patch, který zvyšuje SHMMAX na 128 MB. Bueso uznal, že navýšil limit o v zásadě libovolnou hodnotu (jde o čtyřnásobné navýšení), ale v diskuzi, která následovala, řekl, že uživatelé by se asi měli rozhodnout sami a SHMMAX nastavit na určité procento celkové systémové RAM; zvýšení výchozí hodnoty jen představuje lepší výchozí bod pro současný hardware.

    Andrew Morton však namítal, že zvýšení výchozí hodnoty neřeší problém – a to ten, že uživatelé často narážejí na umělé omezení, které není nijak opodstatněné:

    Hele. 32M dělá problémy. Libovolné navýšení libovolných 32M na libovolných 128M nic neřeší – problém tu pořád je. Zkus se nad tím prosím více zamyslet: jak se tohoto problému můžeme navždy zbavit?

    Jedním způsobem, jak se problému navždy zbavit, by bylo se zbavit SHMMAX, ale jak bylo v diskuzi připomenuto, administrátoři pravděpodobně budou mít zájem nastavit alespoň nějaký limit tak, aby nikdo nemohl vytvořit SHM segment, který spotřebuje veškerou paměť v systému. Motohiro Kosaki navrhl nastavit výchozí limit na nulu, což by znamenalo „neomezeně“. Bueso pak tento přístup převzal v druhé verzi svého patche. Jelikož je SHMMIN napevno nastaveno na jedničku, logika velí, že SHMMAX nemůže nikdy být uživateli vnímáno jako platná hodnota – buď jde o výchozí hodnotu („neomezeně“), nebo je to důsledek přetečení.

    Aktualizovaná verze patche navíc nastavuje výchozí hodnotu SHMALL na nulu – což opět znamená „neomezeně“. Odstranění limitu celkového objemu SHM tímto způsobem ale odhalilo druhou chybu na kráse: Manfred Spraul upozornil, že nastavení SHMALL na nulu je způsob, jak administrátoři (poměrně rozumně) úplně zakazují alokace SHM; patch má ten neúmyslný důsledek, že dělá přesný opak toho, co měl tento krok znamenat – povoluje neomezenou alokaci SHM.

    Spraul následně napsal svůj vlastní alternativní patch, který se tomuto problému snaží vyhnout tak, že SHMMAX a SHMALL nastavuje na ULONG_MAX, což znamená nekonečno. Toto řešení s sebou ale také nese rizika; zejména kvůli tomu, že jsou známy případy, kdy se aplikace snaží hodnotu SHMMAX inkrementovat, nikoliv nastavit na určitou hodnotu, což by způsobilo přetečení. Výsledkem by bylo, že by aplikace narazily na nesprávnou hodnotu SHMMAX – pravděpodobně by byla mnohem menší, než kolik potřebují, takže by jejich pokusy o alokaci SHM selhaly.

    I tak ale Buesco souhlasil, že předejít obrácení významu ručního nastavení SHMALL na nulu je správná věc, a odsouhlasil Spraulův přístup. Poslední verze Spraulova patche se snaží přetečení předejít tím, že používá ULONG_MAX – 1L<<24, Spraul ale uznává, že uživatelům nic nebrání v tom přetečení způsobit.

    Poslední obavou zapříčiněnou touto změnou je, že pokud systém nemá žádnou horní mez alokací SHM, pak je možné, aby uživatelé spotřebovali veškerou dostupnou paměť na segmenty SHM. Pokud ale dojde k takové masivní alokaci, OOM killer nebude moci zakročit a tuto paměť uvolnit. Řešením je buď to, aby administrátoři povolili volbu shm_rmid_forced (která vynutí, že každý segment SHM bude vytvořen s příznakem IPC_RMID – což zaručuje, že je přiřazen k alespoň jednomu procesu, což zase zajistí, že jakmile OOM killer zabije zodpovědný proces, tak SHM segment zmizí spolu s ním) nebo aby ručně nastavili limity SHM.

    Protože původním smyslem tohoto úsilí bylo předejít potřebě ručně nastavovat limity SHM, může se zdát, že jsme tam, kde jsme byli. Pro většinu uživatelů je ale odstranění starých limitů vítanou změnou. Zlotřilí uživatelé pokoušející se alokovat veškerou paměť ve sdílených segmentech jsou přinejlepším anomálie (ale určitě něco, na co by si administrátoři měli dávat pozor), zatímco původní výchozí limit 32 MB byl pro řadu uživatelů už dlouhou dobu problémem.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

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

    Komentáře

    Vložit další komentář

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