Test di HugePages con XEN

giovedì 5 novembre 2009 alle 05:07 | Pubblicato su Linux | 2 commenti
Tag: , , , ,

Ebbene, dopo essere riuscito ad ottenere una macchina para-virtualizzata con XEN con il supporto per le Huge Pages come descritto nel mio post precedente, era arrivato il momento di verificare se effettivamente c’erano problemi con questa accoppiata.

Confesso che nella fretta come al solito ho voluto bruciare le tappe ed ho subito cercato di configurare le Huge pages e di provare a far partire il database Oracle (sempre l’istanza 11gR2). La fretta è stata una cattiva consigliera come il solito, perché ho litigato un po’ con i parametri di configurazione della memoria di Oracle per far stare tutto nella RAM che ho a disposizione. Seguirò nella descrizione lo stesso ordine con cui ho eseguito le operazioni.

Configurazione del sistema operativo

Una volta “abilitato” il kernel all’utilizzo delle Huge Pages, bisogna configurare quanta parte di memoria debba essere dedicata  a queste pagine giganti, infatti andando a vedere il file /proc/meminfo si osserva:

[root@oel53test11gR201 ~]# cat /proc/meminfo |grep Huge
HugePages_Total:      0
HugePages_Free:       0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

per farlo in modo definitivo (si può fare anche al volo, ma siccome le pagine devo essere contigue potrebbe essere necessario un reboot affinché il sistema trovi sufficente memoria contigua libera) si modifica il file /etc/sysctl.con aggiungendo le righe:

vm.nr_hugepages = 420
vm.hugetlb_shm_group = 505

La prima riga corrisponde al numero di pagine, che moltiplicato per la dimensione della pagina (nel mio caso 2048K) la dimensione in byte della memoria che si vuole gestire in questo modo (in questo esempio 420*2048k=840M). La seconda riga è importante se si intende far utilizzare le Huge Pages ad oracle: indica il gruppo del sistema operativo che  può utilizzare le huge pages con le chiamate di sistema shmat/smget (Vedi vm/hugetlbpage.txt) Questo secondo la documentazione, ma vedremo dopo che a me questo non torna.

Secondo alcune note del Metalink Oracle, ad esempio la 560501.1, occorre modificare anche il file /etc/security/limits.conf aggiungendo le due righe:

oracle soft memlock n
oracle hard memlock n

Dove n è il numero di KByte che si assegnerà alla SGA (immagino sia il caso di mettere un numero un po’ più grande)

Modifcato i file si può fare un reboot e  dopo di ciò si ottiene:

[root@oel53test11gR201 ~]# cat /proc/meminfo |grep Huge
HugePages_Total:   420
HugePages_Free:    420
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

Configurazione di Oracle

Stando alla nota Oracle Metalink 749851.1 l’impostazione “Automatic Memory Management (AMM)” di Oracle 11g non è compatibile con l’uso delle HugePages, quindi occorre settare a 0 i parametri MEMORY_TARGET e MEMORY_MAX_TARGET .  Ho quindi impostato i vari parametri SGA_TARGET, SGA_MAX_SIZE PGA_AGGREGATE_TARGET, con qualche difficoltà. Non ho verificato se l’incompatibilità è certificata anche per la R2 di 11g, in ogni caso questa incompatibilità spiega il perché nei manuali ufficiali non viene incoraggiato l’utilizzo delle Huge Pages.

Dopo aver aggiustato in più fasi tutti i parametri Oracle sono arrivato finalmente ad un risultato. Ad un certo punto sono arrivato al livello che sembrava tutto a posto ma da /proc/meminfo risultavano ancora tutte le pagine libere, ad indicare che Oracle non le usava: era perché il numero di pagine che avevo riservato ancora non bastavano per tutta la SGA, infatti aumentandolo da 405 a 420 ho risolto.

… risolto poco, perché il risultato del tentativo di avvio dell’istanza Oracle è stato un reboot della macchina virtuale con la visualizzazione sulla console di XEN di un bel “kernel panic”.

A questo punto ho fatto quello che avrei dovuto fare subito, ho provato le hugepages con un programmino di test, precisamente quello descritto in questo bel articolo.

Riporto quindi il messaggio in console:

Unable to handle kernel paging request at ffff88005cc122f0 RIP:
[<ffffffff802cd3ec>] hugetlb_no_page+0x1e3/0x27e
PGD 13cd067 PUD 15cf067 PMD 16b6067 PTE 801000005cc12065
Oops: 0003 [1] SMP
last sysfs file: /block/dm-0/range
CPU 0
Modules linked in: autofs4(U) hidp(U) nfs(U) lockd(U) fscache(U) nfs_acl(U) rfcomm(U) l2cap(U) bluetooth(U) sunrpc(U) dm_multipath(U) scsi_dh(U) scsi_mod(U) ipv6(U) xfrm_nalgo(U) crypto_api(U) parport_pc(U) lp(U) parport(U) pcspkr(U) xennet(U) dm_raid45(U) dm_message(U) dm_region_hash(U) dm_mem_cache(U) dm_snapshot(U) dm_zero(U) dm_mirror(U) dm_log(U) dm_mod(U) xenblk(U) ext3(U) jbd(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
Pid: 3435, comm: oracle Tainted: G      2.6.18-2.6.18-164xenhugepages #1
RIP: e030:[<ffffffff802cd3ec>]  [<ffffffff802cd3ec>] hugetlb_no_page+0x1e3/0x27e
RSP: e02b:ffff880063017d18  EFLAGS: 00010246
RAX: ffff88005cc122f0 RBX: 0000000048c0d0e7 RCX: 0000000048c0d027
RDX: 0000000000000000 RSI: 0000000048c0d0e7 RDI: 000000008bdffe98
RBP: 0000000000000000 R08: ffffffff804fbfc3 R09: 0000000000000908
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880002fe5000
R13: ffff8800a12e4160 R14: 000000008bdffe98 R15: ffff88005fb5ce58
FS:  00002abe89f78e60(0000) GS:ffffffff805ce000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process oracle (pid: 3435, threadinfo ffff880063016000, task ffff880063ac87a0)
Stack:  00000001804f62c0  ffff88005cc122f0  ffff880009a95b80  0000000000000000
ffff88005cc122f0  ffff880009a95b80  000000008bdffe98  0000000000000001
ffff88005fb5ce58  ffffffff802cd4dc
Call Trace:
[<ffffffff802cd4dc>] hugetlb_fault+0x55/0xba
[<ffffffff80208b0c>] __handle_mm_fault+0x5c/0x1354
[<ffffffff80241249>] vma_prio_tree_insert+0x20/0x38
[<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
[<ffffffff8020e6fe>] do_mmap_pgoff+0x658/0x7c3
[<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
[<ffffffff80231992>] __up_write+0x27/0xf2
[<ffffffff8026082b>] error_exit+0x0/0x6e

Code: 48 89 18 83 7c 24 04 00 74 23 41 f6 47 28 08 75 1c 48 8b 4c
RIP  [<ffffffff802cd3ec>] hugetlb_no_page+0x1e3/0x27e
RSP <ffff880063017d18>
CR2: ffff88005cc122f0
<0>Kernel panic – not syncing: Fatal exception

Va detto, che l’errore non avviene nel momento in cui il programma alloca le pagine (con shmget) ma quando cerca di scriverci dentro. Ho anche provato ad eseguire il programmino di test dopo aver tolto dal file /etc/sysctl.conf la riga vm.hugetlb_shm_group = 505, in questo modo stando alla documentazione solo l’utente root dovrebbe essere in grado di utilizzare le Huge Pages, ma nel mio caso non è cambiato nulla, la macchina si riavviata con lo stesso errore.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Hai provato a usare le hugepages with kvm?


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: