Il controller collegato ai dischi fisici solitamente ha una cache - protetta o non - e una coda massima di comandi che è capace di gestire tramite una coda. Questa dimensione di coda ( solitamente chiamato scsi commands queue) varia molto da controller a controller quindi l'unico modo di conoscerlo è di cercare nella documentazione.
Quindi riassumendo, un applicativo richiede un IO, questo IO viene preso in carico dai vari livelli di LVM e file system (LVM, VxVM, ZFS ... ) che lo mandato ai driver, dal driver al controller fisico che lo mette in coda. Successivamente il controller manda le istruzioni ai dischi. Se queste attività non vengono eseguite in
Ogni LUN considera che la coda del controller è di
MAX_QUEUE_CONTROLLER / NUMERO_DI_LUN il risultato va arrotondato al multiplo di 8 piu vicino e mai sotto 8. (vedi sotto)
Se ho un controller con una queue da 512 e ho 50 LUN il numero è 10,24 arrotondato a 8 o16. Metto anche 16 perche la situazione calcolata è la peggiore: quella in cui ogni lun cerca di fare tutti gli I/O possibili. Questo caso estremo è utile per avere un numero di base ma va poi pensato con l'effettivo carico di I/O esistente.
Per vedere i limiti imposti basta guardare la colonna "actv" di iostat
ps:
ZFS aumenta di molto gli I/O visto che per ogni disco presente in un zpool ne fa uno stripe, quindi una richiesta da parte dell'applicazione di 1 I/O si trasforma in N richieste sul controller fisico, con N numero di dischi in stripe del zpool.
ps2: per gli hitachi 99xx con solaris 10 esiste il bug 6848081 risolto solo a dicembre 2009
Posts
No comments:
Post a Comment