a další.Portál AbcLinuxu, 25. dubna 2024 18:11
Slíbil jsem, že půjdeme více pod pokličku, tak se do toho pustíme. Řeknu vám, že někdy na té pokličce leží pořádné závaží a dostat se do hrnce je značně obtížne. Dnes se pokusíme zjistit co se v Redmondovic rodince kuchti v hrnci s nápisem paměť procesu a také v malém rendlíku s nápisem csrss.exe.
V případě Windows je třeba jednoznačně jít ke zdroji, tedy na msdn.microsoft.com nebo přidružené weby. Na informace, které člověk pomocí googlu najde někde mimo se nejde příliš spolehnout. Množství informačního šumu, polopravd či vyložených bludů, které se v nich nacházejí je úchvatné. Jeden zdroj čerpá z jiného a z informace typu "já si myslím, že by to tak mohlo fungovat, tak to tak napíšu" se pomalu stane taková virtuální pravda.
To není tak jednoduchá otázka, jak by se na první pohled mohlo zdát. Získat tento údaj v operačním systému s virtuální paměti a sdílením, mmapovavnými soubory a podonbně je naopak úkol netriviální. Jak na to v linuxu jsem před časem psal. Ve Windows je hlavním ukazatelem pamětí pracovní sada (Woking Set). Tato hodnota se rozpadá na 3 části- private, sharable a shared. První část je uživatelům předkládána jako velikost procesu. Je to implicitní hodnota uvedena ve správci úloh a v nástroji "Sledování prostředků". Získat lze ještě hodnotu Virtual size a Commited (český překlad, Svěření, je kouzelný). Každopádně pokud se windowsáka zeptáte kolik u něho zabíta Firefox tak vým odpoví hodnotou vyčtenou buďto ze sloupce Working Set, nebo Private Working Set.
Microsoft to v helpu uvádí následující:
To determine which program is using the most memory, follow these steps:
- 1. Open Task Manager by right-clicking the taskbar and then clicking Task Manager.
- 2. Click the Processes tab.
- 3. To sort programs by memory usage, click Memory (Private Working Set).
Jsem nyní poměrně pracovně vytížen takže jsem to blíže nezkoumal, bral jsem to tak, že WS odpovídá linuxí hodnotě RSS. K práci ale potřebuju VirtualBox a všiml jsem si, že při spuštění dvou strojů (oba mají přiděleno 512 MiB paměti) mají oba jednotlivě zhruba 75 MiB WS a 200 MiB Virtual Size. V jednom ze strojů jsem spustil OpenOffice. S hodnotami to téměř nehlo. Zavřel jsem oba stroje a najednou jsem měl o více než gigabajt volné paměti více. Zázraky. Kouzla. Divy. Čáry. Černá magie. Toto mě přinutilo prozkoumat blíže o co jde.
Co o tom píšou hoši z Redmondu?
The working set of a program is a collection of those pages in its virtual address space that have been recently referenced. It includes both shared and private data. The shared data includes pages that contain all instructions your application executes, including those in your DLLs and the system DLLs. As the working set size increases, memory demand increases.
Máte pocit, že WS je tedy hodnotou, ze které lze o paměti využité procesem usuzovat jen velmi obezřetně? Co kdybych vám ukazal systemové volání umožnující nastavit spodní a horní limit WS procesu?
Vybavení těmito vědomostmi si můžeme říst co tedy vlastne WS znamená- je to často využívána paměť procesu, kterou systém bude držet ve fyzické paměti jak jen to půjde aby zamezil stránkování. Které stránky do WS spadnou je na operačním systému a podle jednoho blogu na msdn se využívá LRU strategie. Pokud se systém rozhoduje špatně tak je možné nastavit limity WS a systém se bude snažit tyto mantinely dodržet. Každopádně na počítači s menším množstvím paměti bude mit aplikace za stejných podmínek menší WS než na počítači s větší paměti.
Dalo by se říci, že systém udržuje pro každý proces množinu aktivních stránek. Existuje nějaká hodnota (pravděpodobně závislá na množství volné paměti a dalších parametrech), která určuje limit stáří stránky aby se vešeldo WS dané aplikace. Jedním z parametrů je zcela určitě to, zda je aplikace minimalizována či ne. Minimalizací aplikace způsobí zmenšení WS řádově o megabajty přičemž samotný akt minimalizace téměř žádné uvolnění paměti nezpůsobí. Stránky, které z WS vypadnou systém ve volných chvílích zapisuje na disk pokud je potřeba (pokud se jedná o kód nebo data uložená v .exe nebo .dll tak to není zapotřebí- jako miniaturní stránkovací soubory se využijí přímo tyto soubory na disku). To neznamená, že je zcela uvolní. Pouze v případě, že by to bylo zapotřebí provést tak už není potřeba odstránkovat. To je důvod, proč windows vykazuje v zásadě vždy značné využití stránkovacího souboru- jsou tam v holném počtu kopie stánek, které jsou zároveň i v paměti.
Můžeme tedy odpovědět na odázku z nádpisu kapitoly? Ano. Odpověď zní, že ve Windows není žádný spolehlivý prostředek jak určit velikost využité paměti procesem. Žádná hodnota poskytována systémem to neumožní spolehlivě zjistit. Zavřít aplikaci a sledovat kolik volné paměti přibude je samozřejmě taktéž pochybný a vysoce obskurní způsob. Stačí že zavřením aplikace zanikne nějaký soubor, který byl v diskové cache a dostaneme mylné výsledky.
Celou fyzickou paměť lze rozdělit do čtyř základních oblastí - volná paměť, paměť obsazená programy, (disková) cache a pamět jádra. Poslední zmíňovaná se navíc dělí na paměť stránkovatelnou a nestránkovatelnou. Vista se snaží aktívně využít volnou paměť. Při typickém scénáři využití počítače v Gentoo jsem dosáhl zaplnění celé paměti zhruba na konci pracovního dne. Vista to bezpečně zvládne do dvou hodin. Může za to featura superfetch a teké množství procesů, které na pozadí provádějí nejrůznější činnosti včetně např. skenování disku z cílem nalézt malware nebo indexace obsahu. Přínos superfetche a readyboostu je předmětem mého současného zkoumání.
Vista implementuje priority IO a systémové nástroje toho využívají. A nutno říci, že to opravdu funguje dobře. Pokud s diskem pracuje nějaká aplikace tak se scanování disku (s prioritou iddle) zastaví. Lze očekávat, že aplikace toho budou také brzy využívat. V Linuxu jsou IO priority součástí CFQ scheduleru a lze je ovládat pomocí ionice. Distribuce toho zatím dle mých pozorování prakticky vůbec nevyužívají. Přitom takové updatedb s nízkou prioritou by zcela jistě nejednomu ušetřilo narvy. Vista: dvojka, Linux: trojka. Váha: 3.
Proč má v XP konzole (cmd.exe) klasickou dekoraci okna a widgety a nepoužívá se aktuálně nastavený skin? Ve Viste dodá dekoraci DWM ale widgety (posuvník) jsou stále staré. Zato se ve viste nedá do konzole provést drag&drop. Blog na msdn dává částečné vysvětlení této záhady.
the command prompt window (like all console windows) is run under the ClientServer Runtime System (CSRSS), and CSRSS cannot be themed. But why can't CSRSS be themed? CSRSS runs as a system service, so any code that runs as part of CSRSS creates potential for mass havoc. The slightest mis-step could crash CSRSS, and with it the entire system. The CSRSS team decided that they didn't want to take the risk of allowing the theme code to run in their process, so they disabled theming for console windows.
O CSRSS se příliš hodně informací získat nedá. Víme že je to klientská část win32 API, stárá se o vytváření procesů a thready, běží jako systémová služba v režimu jádra a tudiž pád tohoto procesu stáhne dolů celý operační systém. Aha, na jednu zcela bezvyznamňoučkou věc bych zapomněl- stará se o konzoly. A to tak, že cmd.exe a PowerShell běží v režimu CSRSS.
Hlavním uváděným důvodem proč není na okno konzole použitý theme je tedy snaha zamezit tomu, aby chyba v kódu vykreslujícím dekoraci oken a widgety nezpůsobila pád celého systému.
Proč ve Vistě nefunguje přetažení souboru nebo složky do konzole? To je vysvětleno v tomto textu v kapitole "User Interface Privilege Isolation". Konkrétně se jedná o tento úryvekA lower privilege process cannot:
* SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.
Hezky vysvětleno. Zustává uz jen jediná prostá, taková neduležitá otázka: proč, u všech rohatých, běží konzole v režimu jádra se zvýšnými privilegiemi ikdyž ji spustí obyčejný uživatel? A není to tak náhodou docela velká chyba návrhu? Na první otázku se mi odpověď najít, i přes nemalé vynaložené úsilí, nepodařilo a dedukce taktéž nezabírá. Na druhou nechť si každý odpoví sám. Dle mého názoru se v hrci nazvanem csrss.exe vaří hnus fialový.
Toť pro dnešek vše. Příště bude určite jedna kapitola věnovaná tématu "Systém, který si žije svým vlastním životem" a další.
Tiskni
Sdílej:
the command prompt window (like all console windows) is run under the ClientServer Runtime System (CSRSS), ... CSRSS runs as a system service, so any code that runs as part of CSRSS creates potential for mass havoc.Nemám slov ... Vlastne niečo ma napadá: onedlho všetky CLI programy vo Windows budú považované za apriori nebezpečné a anti-víry ich budú dávať do karantény. Zbohom HalloWorld.exe. To, že už nepôjde urobiť drag&drop súboru z explorera do cmd.exe - jedna z mála užitočných trikov čo tam mali a oni to vyrazia ... Mimochodom, ešte stále sa to okno cmd.exe nedá dynamicky resizovať?
8.1.2008 14:45
mess | skóre: 43
| blog: bordel
| Háj ve Slezsku - Smolkov
... konzole ma oproti uzivateli, ktery je spousti zvysena prava...To je celkem podstatná bezpečnostní díra, nemyslíte?
9.1.2008 09:16
mess | skóre: 43
| blog: bordel
| Háj ve Slezsku - Smolkov
format C: .
8.1.2008 16:58
rADOn | skóre: 44
| blog: bloK
| Praha
Konzole musi bezet jako systemovy proces kvuli kompatibilite s DOSem - widle nemaji zadnou abstrakci terminalu a programy pisici do konzole muzou bud pouzit podedena volani DOSu (vicemene k nicemu), nebo psat rovnou do graficke pameti ve znakovem rezimu. Coz vyzaduje strachat se v mapovani pameti procesu takze neprekvapi ze to bezi pod systemovym uctem.
Vylepseni jako ANSI.SYS a podobne se nikdy neujaly a win32 api tohle AFAIK nijak neresi, takze widlaci stale tahaji na noze kouli navrhu MSDOSu.
.
8.1.2008 21:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Rýpavý komentář:
A nutno říci, že to opravdu funguje dobře..... Vista: dvojka
Dotaz: jak by to mělo fungovat na jedničku?
Sú situácie, kde i ten najlepší je len druhý. Spýtaj sa pápeža.
9.1.2008 02:59
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Distribuce toho zatím dle mých pozorování prakticky vůbec nevyužívají. Přitom takové updatedb s nízkou prioritou by zcela jistě nejednomu ušetřilo narvy.Schválně jsem se podíval do svého openSUSE 10.3 (protože se mi už dříve zdálo, že tam updatedb nebrzdí systém tak, jak jsem byl zvyklý z FC 6), a s potěšením zjistil, že se tam s I/O prioritou pracuje - ionice se používá jak pro updatedb, tak pro beagle.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
9.1.2008 12:55