strip/block size y otros temas de RAID (largo)

[Horst H. von Brand]

Victor Hugo dos Santos <listas.vhs en gmail.com> wrote:
> bien, estoy mirando algunos documentos de como mejorar la peformance
> de accesos a los discos duros:

> 1 http://thias.marmotte.net/archives/2008/01/05/Dell-PERC5E-and-MD1000-performance-tweaks.html
> 2 http://kbase.redhat.com/faq/docs/DOC-2893
> 3 http://wiki.centos.org/HowTos/Disk_Optimization
> 4 http://insights.oetiker.ch/linux/raidoptimization/
> 
> y tengo algunas dudas "existenciales" que tal vez alguno pueda
> ayudarme a entender
> 
> Obs.:
> 1 -  El SO es un RHEL 5.2

OK.

> 2 - no tengo problemas de performance en estes momentos, pero quiero
> descubrir hasta donde puedo llegar (en mejoria) manteniendo los datos
> seguros.

Como dice por alli: 

"First rule of optimization: Don't do it.
 Second rule of optimization (only of experts!): Don't do it (yet)."

Y el dictum de Knuth: "Premature optimization is the root of all evil"

Para reflexion final, como dice Jon Bentley[1] (y tiene algunos cuentos muy
lindos para apoyarlo): Optimizar es ubicar el cuello de botella
(_midiendo_, porque a la hora de estimar donde esta no andamos ni cerca) y
ver como eliminarlo. Hacer que los discos se accedan mas rapido no ayuda en
(casi) nada si el problema esta en otra parte. Lo tipico es que un programa
pase 95% de su tiempo en 5% de su codigo (para una variedad de valores de 5
y 95 ;-). Entonces haciendo que el 5% vaya 2 veces mas rapido, tienes que
en vez de 100 se demora:

  95 * 1/2  + 5 * 1 = 52,5

o sea, logras que vaya casi 2 veces mas rapido. En cambio, si a traves de
un heroico esfuerzo logras disminuir el tiempo de ejecucion del 95%
restante a la mitad, tienes que se demora:

  95 * 1 + 5 * 1/2 = 97,5

En castellano, no hay diferencia.

El mismo efecto ocurre a lo ancho en sistemas, no solo programas. Me
contaron de una situacion en la cual una consulta SQL se demoraba decenas
de minutos; compraron maquinas mas grandes, discos mas rapidos, ... y
lograron disminuir el tiempo de ejecucion de la consulta (critica en cierta
aplicacion) un par de minutos (10 o 15%). Reorganizando la consulta y
agregando indices adecuados, el tiempo bajo a unos pocos segundos.

> 3 - los 4 servidores que tengo para pruebas, son
> 	PowerEdge 2950 ( 2 x Intel(R) Xeon(R) CPU X5460 @ 3.16GHz) y 	32768 MB
> 	Controladora PERC 6/i Integrated (con bateria) con 6 (4 en el canal 0
> y 2 en el canal 1) discos Seagate Cheetah NS SAS (3Gb/s 400-GB y 16 MB
> de cache)
> 4 - dichos equipos estarian destinados a trabajar con BD (oracle y postgresql)

Conviene alli organizar las bases de datos de forma que no hayan accesos
concurrentes "al mismo disco" (separar logs y datos, poner tablas que se
"usan juntas" en discos separados, ...)

> bien.. en estes momentos tengo un solo RAID-10 creado en la
> controladora que alberga todos los 6 discos y me genera un unico
> volume de 1,116.00 GB

Mala idea. Ver arriba.

RAID (salvo espejado puro o striping a secas) es letal para rendimiento:
Supongamos 3 datos + 1 paridad. Para escribir requieres a lo menos leer 2
(2 datos que no cambian, 1 cambia y no importa), calcular nueva paridad y
escribir 2 (nuevos datos y nueva paridad). Si eres paranoico (debiera
serlo!), lees 4 (3 datos + paridad), verificas; luego escribes 2 (nuevos
datos + nueva paridad). Para leer requieres leer 4 (3 datos + paridad,
luego verificar). Compara con 1 escritura y 1 lectura. Aun si logras
traslapar perfectamente I/O (== una controladora por disco), igual pagas
los costos de operaciones extra y verificar.

> y dentro del sistema operativo tengo las siguientes particiones y LVM

LVM es muy comodo, pero tiene su costo en rendimiento...

[...]

> despues de leer varios documentos en internet... pienso que el mejor seria:
>  - crear en la controladora un volume de discos para las particiones
> "/boot" y "swap" (~ 5GB)

/boot solo se usa al inicio. Puede ir "donde quepa", es irrelevante para el
rendimiento.

Recordar que los discos son  m u y  l e n t o s  frente a RAM, asi que
debe considerarse siempre el area swap como ultimo recurso. Idealmente
nunca se usa, esta unicamente para el caso "once in a blue moon" se quedo
sin memoria el sistema; entonces en vez de irse de hocico sigue funcionando
(extremadamente lento, pero sigue). Esto salvo casos extran~os de
aplicaciones que tienen memorias virtuales gigantescas, a las que rara vez
hacen referencia (servidor DNS).  O sea, si usas swap, compra mas
RAM. Por lo expuesto, puede ir donde quiera (no afecta "el caso normal").

>  - crear en la controladora un volume de discos para la particion "/" (~
>  20 GB)

Sistema operativo y aplicaciones. Dependiendo de la carga exacta, _debiera_
ser totalmente irrelevante (las bibliotecas y programas se cargan en RAM, y
ya).

>  - crear en la controladora un volume de discos para las particiones
> de datos "/var/data" con todo el espacio que sobre de los discos (unos
> 1.1TB ~)

Divide los "datos" como indique arriba.

[...]

> aca me entra las siguientes dudas:
> 
> * ahora, el strip size de los volumenes esta configurado en 64 K (con
> Write-Back y Adaptive Read Ahead habilitados tambien), pero cuales
> serian los mejores valores para:
>  - particion "/" en general
>  - base de datos oracle y postgresql (considerar instalación por
> defecto, sin cambios significativos)

Depende de los taman~os de los registros, y las ideas que tienen Oracle y
PSQL respecto de los taman~os de sus lecturas. Menor que los "bloques" del
RDBMS es contraproducente, mayor no ayuda demasiado.

> * no tengo certeza, pero el strip size no funciona igual que el block
> size de los sistemas de archivos, o si ?? por ejemplo..
> se tengo configurado el FS con blocos de 4K y envio 3 archivos de 2K
> entonces, utilizaria 3 blocos y estaria ocupando 12K en el FS.
> se tengo configurado el strip size en 64K y envio 3 archivos de 40K ,
> estes se escriben sequencialmente/en bruto en los discos, sin
> perdidas.

Depende del sistema de archivos. Si el sistema de archivos usa bloques de
4KiB, usas 3 bloques de 4KiB para los datos (+ burocracia propia del
sistema de archivos!). Si los strips son de 64 KiB, y tienes 3 archivos de
40KiB, c/u usa 10 bloques, que pueden estar en el mismo strip o no.

> no se si me explique bien mi duda !!! (sorry)

Yep.

En todo caso, aca lo que interesa es el "sistema de archivos" del RDBMS (te
conviene usar "raw partitions", no mapear los bloques a ubicaciones en
archivos que luego hay que mapear a ubicaciones en disco; notar que LVM
introduce un nivel adicional de indireccion, aunque barato).

> * hay algun comando/script para verificar en el FS el tamano promedio
> de los archivos y en base a esto saber cual es el mejor block size que
> deberia de utilizar ??

Que buena pregunta! Crei que nunca ibas a hacerla... df(1) te entrega ya
sea el espacio fisico o el numero de inodos (== archivos) usados, de alli
es un ejercicio en sed(1) + bc(1) obtener lo que buscas ;-)

Si quieres algo mas elaborado, deberas recurrir a find(1) y procesar el
resultado de alguna forma.


Aprendi mucho de [2] (aunque es bastante an~ejo, las tecnicas que plantea
son validas siempre). Revisa lo que te cuenta sar(1).

[1]
@Book{bentley82:_writing_eff_progr,
  author =       {Jon Louis Bentley},
  title =        {Writing Efficient Programs},
  publisher =    {Prentice Hall},
  year =         1982
}

[2]
@Book{Loukid90,
  author =       "Mike Loukides",
  title =        "System Performance Tuning",
  publisher =    "O'Reilly",
  year =         1990
}
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513