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

[Horst H. von Brand]

Aldrin Martoq <amartoq en dcc.uchile.cl> wrote:
> 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.

Lo que importa es la interaccion entre lo fisico y lo logico.

> Actualmente, un disco usualmente tiene varios platos, supongamos 4.

OK.

> Luego, cuando leemos 1024KiB desde el sector 0, leera _al mismo tiempo_:

Leera al mismo tiempo 1024KiB desde el sector 0, nada mas. Los discos estan
en condiciones de transferir datos desde una unica cara (== cabezal) a la
vez. Salvo dispositivos mas bien exoticos.

[...]

> 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.

No. El ancho de banda no cambia.

Lo que si cambia (internamente) es que los discos manejan extenso
buffering, y si pides leer de la pista 30, sector 17, y el cabezal viene a
caer en el sector 25 aprovecha de leer el resto de la pista a partir de
alli y la guarda porque probablemente van a solicitar parte de eso
pronto. Asi el ancho de banda que ves puede ser mayor que el con el que se
leen datos fisicamente de la superficie del disco.

> 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)

Con esto obtienes 1024KiB de datos utiles, lo otro es unicamente para poder
verificar paridad (y corregir datos dan~ados que se hayan leido). O sea, el
tiempo de esto (idealmente) es igual a leer de un disco + el tiempo para
verificar paridad (o corregir, segun sea el caso). Pero ver mas abajo
porque esto no es tan simple.

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

No...

> 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.

Idealmente, el seek es el mismo. Pero seria bien dificil asegurar
sincronizar tanto los discos (considera el remapeo "transparente" de
sectores malos), y definitivamente no hay como sincronizar los discos en
giro, asi que la latencia rotacional (que sera la mayor de todas!) empeora.

> Luego, poner discos en RAID es como agregar mas platos a un mismo disco:
> aumentas el ancho de banda de lectura/escritura

Respecto de datos utiles, disminuye (contencion de acceso a memoria,
calculo de paridad). Claro, si te las arreglas de forma que "generalmente"
requieres datos de varios de los bloques juntos sales ganando... ver
<http://en.wikipedia.org/wiki/Write_Anywhere_File_Layout> para detalles de
como y cuando se puede hacer eso en la practica.

>                                                 pero tienes el mismo
> tiempo de busqueda.

Empeora, por lo anterior.

>                     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.

De eso se trata (en parte) el afinamiento interno que hace el RDBMS de sus
accesos a disco, y las sugerencias que hacian en Oracle sobre Sun al menos
de formatear las particiones del caso con ciertos taman~os de sector, etc.

[...]

> > > 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,

No estamos hablando de 10%, sino 50% o incluso mucho mas...

Y la "distribucion del blocksize de un I/O" es mas bien trivial: El taman~o
de bloque de tu sistema de archivos, ni un byte mas ni uno menos. Medir
distribucion de taman~os de lecturas o escrituras es otro cuento... y alli
entra todo el stack (la aplicacion dice algo, libc (stdio et al) se encarga
de algun buffering, el sistema de archivos decide que I/O hacer cuando y
"fisicamente" donde, la capa de dispositivos de bloque de tu nucleo acumula
operaciones y las reordena (toda esa linda teoria de elevadores como SCAN y
demases en sistemas operativos), y finalmente el disco hace lo suyo con
buffering interno). Con todos esos involucrados, de cuyas actividades el
sistema operativo puede mostrarte cuando mucho un segmento muy estrecho, no
veo como podrias resolver problemas de rendimiento. Salvo que este mal
implementada parte del sistema operativo... y ese es otro saco de pulgas.

>                                                               me he
> topado con miles de problemas de rendimiento donde lo mas dificil es
> precisamente medir donde esta el cuello de botella...

Siempre es ese el problema central ;-)

> > > 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,

Cierto.

>                                                            y el tiempo
> que tomo.

El tiempo que tomo en retornar de la llamada al sistema, nada mas.

>           Es un DTrace/Systemtap de los pobres ;)

Si y no. Es una herramienta para otros usos.
-- 
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