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

[Aldrin Martoq]

On Tue, 2008-12-30 at 16:58 -0300, Horst H. von Brand wrote:
> Aldrin Martoq <amartoq en dcc.uchile.cl> wrote:
> > Hola Victor, muy largo lo que escribiste, tratare de aportar un poco ;)
> > On Tue, 2008-12-30 at 12:21 -0300, Victor Hugo dos Santos wrote:
> > Esto es mas lento porque en el fondo tienes un puro disco con varios
> > platos,
> No. RAID significa leer y escribir varios cada vez (para lo de "R").
>         esto influye en el seek time y se encolan si tienes varias
> > aplicaciones "distintas" corriendo al mismo tiempo.
> No. Si tienes varios platos (y cabezales) independientes, tienes mejor
> rendimiento. RAID los interconecta (la "A"), y el rendimiento se va al
> suelo.

Fisicamente son varios discos, pero logicamente es uno solo.

Actualmente, un disco usualmente tiene varios platos, supongamos 4.
Luego, cuando leemos 1024KiB desde el sector 0, leera _al mismo tiempo_:
- 256KiB del sector 0 del 1er plato,
- 256KiB del sector 0 del 2do plato,
- 256KiB del sector 0 del 3er plato,
- 256KiB del sector 0 del 4to plato
Entonces tienes un ancho de banda de 1024KiB/dt == 4 veces mas rapido
que si leyeras desde un solo plato. Ahora, el costo de buscar esa
informacion (seek) no cambia.


Ahora, si configuramos un RAID-5 con 5 discos por ejemplo, es la misma
historia: Cuando leemos 4096KiB desde el sector 0, leera _al mismo
tiempo_:
- 1024KiB del sector 0 del 1er disco,
- 1024KiB del sector 0 del 2do disco,
- 1024KiB del sector 0 del 3er disco,
- 1024KiB del sector 0 del 4to disco,
- 1024KiB del sector 0 del 5to disco (paridad)

Tienes un ancho de banda de 4096Kib/dt == 4 veces mas rapido (porque el
ultimo disco es para validacion de paridad).

Esto funciona porque los discos estas rotando al mismo tiempo y la
controladora sabe manejar eso. Luego, el costo de busqueda (seek) es el
mismo que en un solo disco. En discos/controladoras mas baratos, el seek
time sera peor.

Luego, poner discos en RAID es como agregar mas platos a un mismo disco:
aumentas el ancho de banda de lectura/escritura pero tienes el mismo
tiempo de busqueda. Este tipo de afinamiento (ancho de banda) lo
controlas con el tamano del stripe y el "read-ahead". Para esto, lo
ideal es saber la distribucion del bloque que lee tu aplicacion/sistema
operativo.


[Puedes configurar RAID de manera distinta a esta, mezclando el uso de
los discos pero perderas rendimiento]

> > La solucion fue respaldar todo, rehacer el arreglo en 2 arreglos RAID-5
> > y dejar unas aplicaciones usando 1 grupo de discos y otras aplicaciones
> > usando el otro grupo de discos. La cola de lecturas/escrituras disminuyo
> > enormemente, y ahora las lucecitas eran a un lado o al otro.
> No es la mejor configuracion, entonces: Claramente le sacas el maximo
> provecho a los discos si estan trabajando /todo/ el tiempo, no la mitad si
> y la mitad no.

Depende de la aplicacion, como explique arriba si tienes un RAID con
todos los discos en el fondo tienes un solo disco. Si tienes un solo
disco, el seek time es el mismo que el de un disco y eso es malo si
tienes mucha concurrencia (tipos leyendo/escribiendo arriba, otros
almedio y otros abajo).

En tal caso, es mejor separar la carga en varios grupos, mejorando el
tiempo de busqueda (seek). Para el caso de Victor por ejemplo, dejar
oracle en un grupo y postgres en otro grupo.


> > > 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)
> 
> > Creo que todo esto lo sabriamos si tuvieramos DTrace, asi no tendriamos
> > que adivinar...
> ... pero se requeriria 5 veces la maquina por Slowlaris... ;-)
> [Recuerden que en Linux solia ser que lanzar un _proceso_ era mas rapido
>  que lanzar una _hebra_ en Solaris, en la misma maquina!]
> > Por ejemplo, podrias sacar la distribucion del taman~o del block usado
> > _en tu aplicacion_, que es lo que importa al final:
> > http://wikis.sun.com/display/DTrace/io+Provider#ioProvider-Examples
> Cuidado, eso cuando mucho puede dar una indicacion generica; nadie te dice
> que no hayan ajustado esos (y quien sabe que otros) parametros segun el
> sistema en el cual corre.

Saber la distribucion del blocksize de un I/O es algo impagable. Pagaria
un 10% de performance con tal de saber esa info y mucha otra, me he
topado con miles de problemas de rendimiento donde lo mas dificil es
precisamente medir donde esta el cuello de botella...


> > Podrias intentarlo con systemtap o por ultimo strace y nos
> cuentas ;)
> No creo que strace(1) ayude mucho aca?

Con strace puedes sacar el tamano de un write por ejemplo, y el tiempo
que tomo. Es un DTrace/Systemtap de los pobres ;)

-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>
http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 197 bytes
Descripción: This is a digitally signed message part
Url        : http://listas.inf.utfsm.cl/pipermail/linux/attachments/20081230/74c66023/attachment.bin