Aldrin Martoq <amar...@dcc.uchile.cl> wrote: > On Tue, 2008-12-30 at 16:58 -0300, Horst H. von Brand wrote: > > Aldrin Martoq <amar...@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