24 giugno 2009

Le novità di ASM in 11g

La versione 11g di ASM include alcuni miglioramenti interessanti.
  • Comando CP: finalmente è possibile copiare i file da e verso lo storage ASM, come del resto qualsiasi processo server di Oracle può fare da sempre. La differenza è che si usa il comando CP da linea di comando ASDCMD o da linea di comando della shell come parametro di ASMCMD.

  • Fast Mirror Resync: in seguito a temporanee indisponibilità di un disco ASM contenente copie di dati mirrorati, la risincronizzazione avviene tenendo conto dei dati già presenti sul disco, evitando quindi la ricostruzione completa del mirror. ASM in pratica tiene traccia degli extent da aggiornare e al resync copia solamente quelli. È stato introdotto il parametro DISK_REPAIR_TIME, che definisce un periodo trascorso il quale il disco non disponibile viene ricostruito per intero.

  • Extent di dimensioni variabili: con 11g è possibile definire la dimensione degli extent, ovvero le unità di allocazione con cui viene riservato lo spazio per i file nello storage ASM. Nelle versioni precedenti questa dimensione era fissa e pari a 1 MB per i file "normali" e 128 KB per i file ad alto I/O rate. I 128 KB rimangono anche in 11g. Una conseguenza immediata è che aumenta ancora la quantità totale di dati che si possono immagazzinare nel database, potendo disporre di datafile più grandi.

07 giugno 2009

Hugepages in RHEL5

Abbiamo visto, in un post precedente, come sia possibile per Oracle allocare una buffer cache molto grande, fino a 62 GB, su un sistema Linux a 32 bit.

La buffer cache viene sostanzialmente allocata come un file su un filesystem di tipo ramfs, e l'accesso ai blocchi in memoria avviene in maniera indiretta.

Facciamo un passo indietro. La memoria nei sistemi a memoria virtuale (ad esempio Linux) viene allocata tramite pagine di 4 KB mappate sulla memoria fisica da una tabella di lookup locale che referenzia una tabella di lookup di sistema, la quale punta finalmente alla memoria fisica.

Le hugepage sono pagine di dimensione molto maggiore di quella standard. Nel caso di RHEL5 ho verificato una dimensione di 2 MB (almeno 500 volte la dimensione standard):
$ grep Huge /proc/meminfo 
HugePages_Total: 821
HugePages_Free: 558
HugePages_Rsvd: 555
Hugepagesize: 2048 kB

Le hugepage vengono allocate al boot tramite un parametro del kernel, in modo da riservare un numero di porzioni contigue di RAM sifficienti ad allocare la quantità di hugepage richieste, altrimenti la RAM viene allocata in pagine da 4 KB (il default). Inoltre le hugepage non sono swappabili; in linguaggio Oracle si potrebbero considerare pinned.
In generale quindi, per allocare quantitativi di RAM molto grandi e mantenere le tabelle di lookup a dimensioni accettabili, si possono usare le hugepage.

La relazione tra ramfs e hugepage è che le pagine allocate su ramfs sono appunto hugepage.

Se avete provato, come ho fatto io, a usare ramfs per la buffer cache, vi sarete accorti che solo la buffer cache va a finire su ramfs, mentre la shared pool finisce nella classica shared memory. Per controllare l'allocazione della shared memory basta utilizzare ipcs:
$ ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0xb0af65c0 1081347 oracle 600 85983232 11
0xb6c83f68 1114116 oracle 600 1629487104 26
0x00000000 1146885 oracle 640 4096 0

Come si può vedere l'utente oracle ha allocato 2 segmenti "grandi" di shared memory: la seconda è la shared pool, impostata a 1504 MB, mentre l'altra è la SGA dell'istanza ASM che gestisce i dischi sulla stessa macchina, mentre non compare la buffer cache.
Le 821 hugepage da 2 MB sul mio sistema di esempio servono ad ospitare la shared pool e la SGA dell'istanza ASM come viene riportato da ipcs.

Le hugepage non sono utili solo nei sistemi a 32 bit. Vedremo le applicazioni nel prossimo post.