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

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

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
• Citáty týdne: netcat, Andrew Morton
• Změna výchozích limitů sdílené paměti

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

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

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

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.

       

Komentáře