Skutečný žrout paměti - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Odkud pochází fotografka Anne Erhard?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Software

Skutečný žrout paměti

5. prosince 2002, 00.00 | Minule jsme si ukázali jednoduchý prográmek, který sice alokuje obrovské množství paměti, ale nijak ji nevyužívá. Díky tomu také nijak neomezuje běh ostatních programů, protože nepotřebuje skoro žádnou fyzickou paměť. Daleko horší to ale je v případě, kdy aplikace nejen alokuje spoustu paměti, ale skutečně ji také využívá.

Skutečný žrout paměti

Minule jsme si ukázali jednoduchý prográmek, který sice alokuje obrovské množství paměti, ale nijak ji nevyužívá. Díky tomu také nijak neomezuje běh ostatních programů, protože nepotřebuje skoro žádnou fyzickou paměť; operační systém proto nemusí swapovat stránky paměti na disk a zpět, a nikomu je nemusí odebírat:

 98 /tmp> >t.m
 #include <stdlib.h>
 int main() {
   while (1) {
     if (!malloc(100*1024*1024)) break;
     usleep(100000);
   }
   return 0;
 }
 99 /tmp>

Daleko horší to ale je v případě, kdy aplikace nejen alokuje spoustu paměti, ale skutečně ji také využívá: v takovém případě samozřejmě roste rychle i její spotřeba reálné paměti — nejen virtuální. Po čase systém spotřebuje reálnou paměť, která je k dispozici, a začne odebírat stránky ostatním procesům; při tom samozřejmě musí swapovat, a práce s celým systémem se zřetelně zpomalí; někdy až na neúnosnou mez.

Máte-li chuť (a instalovanou vývojářskou podporu), můžete vyzkoušet následující jednoduchou variantu — nejprve pro jistotu uložte na disk všechny rozdělanou práci, pro případ, že by vás zpomalení systému přimělo restartovat. Na první pohled by se mohlo zdát, že mezi minulým a tímto příkladem není žádný zásadní rozdíl; jejich chování však bude diametrálně odlišné:

 19 /tmp> <t.m 
 #include <stdlib.h>
 int main() {
   while (1) {
     int size=100*1024*1024;
     char *cp=malloc(size);
     if (!cp) break;
     while (size>0) cp[size-=4000]=0;
     usleep(100000);
   }
   return 0;
 }
 20 /tmp> cc t.m && ( ./a.out & while (true) ; do ( ps -o ucomm,vsize,rss | fgrep a.out )  ; sleep 1 ;  done )
 a.out              103948    308
 a.out              103948  91352
 a.out              103948 102700
 a.out              206348 115528
 a.out              206348 128664
 a.out              206348 137004
 ...

Hned na začátku vidíme, jak spotřeba fyzické paměti dohání virtuální paměť. Je také jasně vidět, že aplikace běží o poznání pomaleji. Jakmile začne operační systém odebírat stránky paměti ostatním procesům a swapovat — a to při rychlosti, s jakou náš prográmek paměť alokuje, bude velmi brzy — viditelně se zpomalí odezva systému jako taková; prosté přepnutí mezi dvěma okny bude trvat poměrně dlouho.

Po nějakém čase (závislém na tom, kolik a jakých aplikací zrovna běží, a také na velikosti fyzické paměti) systém vybere všechnu paměť od ostatních procesů, a začne odebírat stránky samotnému našem programu — to bude vypadat nějak takto:

 ...
 a.out              308748 243492
 a.out              308748 248764
 a.out              308748 250624
 a.out              411148 250284
 a.out              411148 259476
 a.out              411148 258292
 a.out              411148 253100
 a.out              411148 249848
 ...

Vidíme, že velikost fyzické paměti už se v zásadě nemění — víc jí prostě k dispozici není, a proto jí také program více nedostane. Jen se neustále odebírají stránky, jež momentálně nejsou zapotřebí, a ukládají se na disk.

Přepneme-li do jiné aplikace, uvidíme dokonce prudký pokles; tak tomu v mém případě bylo těsně před ukončením programu:

 ...
 a.out             3585548  60908
 a.out             3585548  61948
 a.out             3585548  61936
 *** malloc: vm_allocate(size=104857600) failed with 3
 *** malloc[3058]: error: Can't allocate region
 ^C
 21 /tmp> 

Stojí za to si povšimnout dalšího důsledku stránkování: po ukončení našeho programu je samozřejmě všechna paměť opět volně k dispozici, ale stránky ostatním neaktivním aplikacím již jsou odebrány. Přepneme-li proto na některou z aplikací, jež jsme po celou dobu testu nepoužili, bude přepnutí zřetelně pomalejší než za normálních okolností: to proto, že aplikace musí nejprve načíst z disku do paměti prakticky všechny své stránky.

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Software  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

Zatím nebyl uložen žádný příspěvek, buďte první.

 

 

Vložit nový příspěvek

Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: