Re: strip/block size y otros temas de RAID (largo)
El mié, 31-12-2008 a las 18:08 -0300, Aldrin Martoq escribió: [Yep, el termino stripe lo use muy mal] On Wed, 2008-12-31 at 13:08 -0300, Marcelo Espinosa Alliende wrote: El mié, 31-12-2008 a las 11:38 -0300, Aldrin Martoq escribió: Tambien hay algo extran~o en la formula, por lo siguiente: un ejemplo para ilustrar lo anterior. carga de 500 I/Os con 10 discos para RAID5 LecturasEscriturasI/Os RAID_5 -- 100,00%0,00%(500 + 0) / 10= 50 90,00%10,00% (450 + 200) / 10 = 65 75,00%25,00% (375 + 500) /10 = 87,5 50,00%50,00% (250 + 1000) / 10 = 125 0,00%100,00% (0 + 2000) / 10 = 200 LecturasEscriturasI/Os RAID_10 -- 100,00%0,00%(500 + 0) /10 = 50 90,00%10,00% (450 + 100) / 10 = 55 75,00%25,00% (375 + 250) / 10 = 62.5 50,00%50,00% (250 + 500) / 10 = 75 0,00%100,00% (0 + 1000) / 10 = 100 Con 10 discos y solo lectura deberias tener performance de 9x para raid-5 y 5x para raid-10; pero tus calculos no muestran eso. no, el comportamiento en operaciones de IO es igual para ambos, aquí lo que te dice es que cada disco va a manejar ese volumen de IOs y punto. A ver, si es la cantidad de operaciones por disco lo estas calculando mal. jejeje... LOS SUPUESTOS aca son: - no hay cache o los datos no estan en el - la escalabilidad del numero de operaciones/disco es un buen indicador - raid 10 lee de ambos espejos (lo llamare RAID nuevo mas abajo) PARA RAID-5 - si tenemos 500 lecturas a distribuir en 10 discos, cada disco debera ejecutar 500/9 lecturas (ya que un disco no almacena datos). Hombre, se ocupan los 10 discos... la paridad se distribuye en todos los discos... te imaginas si muere el disco que tiene la paridad? (según tu lógica eso es un raid3) - si tenemos 500 escrituras sobre 10 discos, cada escritura toma 2 lecturas y 2 escrituras; luego cada disco hace 500*4/9 operaciones. La formula es: operaciones/disco = (lecturas + escrituras*4)/(n_discos - 1) no... son n_discos a secas PARA RAID-10 viejo - este es el RAID10 que supongo yo esta implementado - aca supongo que el raid _compara_ lo que lee desde un espejo y el otro - luego, 500 lecturas se duplican entre espejos, osea son 100 lecturas por disco. supones mal, la redundancia se ocupa en este nivel cuando no puede acceder exitosamente a la información requerida, lo que hacen las controladoras decentes (yo he ocupado de HP e IBM, no he tenido la mala suerte -al parecer- de ocupar PERC :) es utilizar el disco espejo para aprovechar de leer data adicional, no la misma data para comparar si está bien o no. Wikipedia: RAID 1 puede estar leyendo simultáneamente dos datos diferentes en dos discos diferentes, por lo que su rendimiento se duplica. RAID 10 es un nivel 0+1, es decir, un stripe espejado por lo que la lógica de raid_1 aplica. - cuando escribe, escribe en ambos espejos. 500 escrituras son 100 escrituras por disco. La formula seria: operaciones/disco = (lecturas*2 + escrituras*2)/n_discos menos, el espejo se usa sólo como redundancia... si no puede leer por falla del disco maestro (sectores malos, etc...) recurre al espejo para recuperar dicha información, no es un si o sí. explicado arriba PARA RAID-10 nuevo - aca suponemos que las lecturas son alternadas entre espejos; luego 500 lecturas son 500/10 = 50 lecturas por disco - cuando escribe, escribe en ambos espejos. 500 escrituras son 100 escrituras por disco. La formula seria: operaciones/disco = (lecturas + escrituras*2)/n_discos que tiene de nuevo si esto *es* RAID_10 (ver correo original) Resumiendo en una tabla: operaciones/disco #disk #oper #read #write RAID-5 RAID-10 RAID10 nuevo 10500 100% 0% 55.56 100 50 10500 90% 10% 72.22 100 55 10500 75% 25% 97.22 100 62.50 10500 50% 50% 138.89 100 75 10500 0%100%222.22 100 100 tu formula para raid5 no es correcta, raid10 (de tu tabla) no opera con la lógica que mencionas, y el raid nuevo *es* el raid_10. por mucho cache que le pongas a la controladora, si tienes más de un 10% de escrituras raid10 se va a comportar mejor que raid 5 y punto... Hmm segun tu tabla original, RAID-10 siempre es mejor y en el caso 100% lectura es igual que RAID-5. Segun la mia, RAID-10 nuevo es mejor _siempre_. Eso en la practica es claramente incorrecto. Lo que esta mal de tu tabla y de mi tabla son los supuestos. Veamos los supuestos: Los mios no son supuestos, simplemente es información
Re: strip/block size y otros temas de RAID (largo)
2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: On Tue, 2008-12-30 at 18:37 -0300, Victor Hugo dos Santos wrote: por cierto, acabo de ir a configurar la controladora para hacer pruebas.. pero he descubirto que la controladora (sera esta en particular ???), permite crear el RAID10, pero no me permite crear volumenes logicos en el.. o sea, se utilizo RAID10/RAID50/RAID60 debo de usar un solo volumen con todo el espacio de los discos. No hagas volumenes con la controladora, solo creas arreglos que seran vistos como discos en el sistema operativo... Por ejemplo, un arreglo RAID-10 con los sectores 0-99 de los discos 1, 2 y 3. Luego otro arreglo RAID-5 con los sectores 100-199 de los discos 1, 2 y 3. bueno.. creo que me confundi y/o confundi a usted.. lo que digo, es que la controladora esta (PERC 6/I).. no me permite utilizar parte de los disco y/o subdividirlos, cuando es un RIAD-10/50 o sea.. se voy utilizar este tipo de RAID, se va todo como un solo volumen.. no es posible dividirlo, utilizar sectores del disco, crear volumenes o lo que sea.. si o si, va interito. Para hacer justa la prueba, deberias mover uno de los discos al otro canal. Ej de prueba: ++ ++ |D1 D2 D3| |D4 D5 D6| ++ 0++ 0 | sda r10| | sdc r5 | ++ 100 ++ 100 | sdb r5 | | sde r10| ++ 200 ++ 200 For RAID levels 0, 1, 5, and 6 only, you can use part of the available disk space to create one virtual disk and then use the rest of the disk space to create another virtual disk or disks. Hmmm si no se puede, usa el D1 D2 D3 con RAID-10 completo, y en el D4 D5 D6 Raid5. ... RAID-10 necesita minimo 4.. y se lo hago, ya no podre utilizar RAID-5, por tendre solamente 2 discos disponibles. sugerencias ??? :-( salu2 y buenas fiestas a todos. -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Aldrin Martoq escribió: En mi experiencia, LVM es LENTO, segun las ultimas pruebas que hice (un tarro parecido al que muestras). Cambia alguna particion (/var ?) y haz alguna prueba sencilla y nos avisas, pues no tengo numeros! Una vez los compadres de Greenplum hicieron unas mediciones de LVM y encontraron que era lento; o mejor dicho, que ponÃa un techo al rendimiento que se podÃa alcanzar: a medida que aumentabas la cantidad de discos, no veÃas ninguna mejora. Sacando a LVM de entre medio, se observaba un crecimiento lineal de rendimiento con el aumento de discos. Alguna URL? Seria interesante repetir las mediciones (LVM ha cambiado mucho). Y me parece bien raro, LVM usa striping, asi que (para carga de lecturas y escrituras al azar) el rendimiento debiera aumentar en forma basicamente lineal con el numero de discos. Si puedes evitar LVM, evitalo. De todas formas puedes agregar más espacio para las BDs en particiones nuevas; en Postgres usando tablespaces, en Oracle no sé cómo se hará. Eso de todas formas, el interponer una capa de software (e indireccion) adicional solo puede disminuir el rendimiento. Pero por otro lado, es el precio que pagas por la flexibilidad... Me parece que RAID-5 seria lo mejor para performance/confiabilidad. Las mediciones de rendimiento que han hecho varias personas en pgsql-performance han mostrado que RAID-10 es muy superior a RAID-5. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: strip/block size y otros temas de RAID (largo)
2008/12/31 Horst H. von Brand vonbr...@inf.utfsm.cl: Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Aldrin Martoq escribió: [...] Si puedes evitar LVM, evitalo. De todas formas puedes agregar más espacio para las BDs en particiones nuevas; en Postgres usando tablespaces, en Oracle no sé cómo se hará. Eso de todas formas, el interponer una capa de software (e indireccion) adicional solo puede disminuir el rendimiento. Pero por otro lado, es el precio que pagas por la flexibilidad... mmm.. en mi caso, LVM es esencial por los snapshots. lo usamos principalmente para disminuir el tiempo en que los servicios estaban detenidos por que se estaban ejecutando respaldos de los datos, o sea: - se detiende los servicios - se crea el snap - se llevanta los servicios - se respalda los datos desde el snap desconozco si hay alguna otra altrenativa a LVM+SNAP en ext3. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
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
Re: strip/block size y otros temas de RAID (largo)
On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: Aldrin Martoq escribió: En mi experiencia, LVM es LENTO, segun las ultimas pruebas que hice (un tarro parecido al que muestras). Cambia alguna particion (/var ?) y haz alguna prueba sencilla y nos avisas, pues no tengo numeros! Una vez los compadres de Greenplum hicieron unas mediciones de LVM y encontraron que era lento; o mejor dicho, que ponía un techo al rendimiento que se podía alcanzar: a medida que aumentabas la cantidad de discos, no veías ninguna mejora. Sacando a LVM de entre medio, se observaba un crecimiento lineal de rendimiento con el aumento de discos. Si puedes evitar LVM, evitalo. De todas formas puedes agregar más espacio para las BDs en particiones nuevas; en Postgres usando tablespaces, en Oracle no sé cómo se hará. Me parece que RAID-5 seria lo mejor para performance/confiabilidad. Las mediciones de rendimiento que han hecho varias personas en pgsql-performance han mostrado que RAID-10 es muy superior a RAID-5. Hmmm estaba revisando y muchos sitios dicen lo mismo. Basicamente, RAID-5 es superior en lectura y RAID-10 es superior en escritura. La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
On Wed, 2008-12-31 at 09:52 -0300, Victor Hugo dos Santos wrote: ... RAID-10 necesita minimo 4.. y se lo hago, ya no podre utilizar RAID-5, por tendre solamente 2 discos disponibles. Tienes razon, me equivoque con 3 discos. sugerencias ??? Prueba separadamente: reconfigura y prueba RAID-10 y luego reconfigura y prueba RAID-5... O si tienes mas discos/tarros, pon 4 discos en un canal y 4 en el otro, asi podras probar simultaneamente ;) -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
On Wed, 2008-12-31 at 10:09 -0300, Marcelo Espinosa Alliende wrote: El mar, 30-12-2008 a las 17:52 -0300, Aldrin Martoq escribió: Haz la prueba, de hecho en el primer link que mandaste el tipo muestra la conversa en una lista y del primer link: http://lists.us.dell.com/pipermail/linux-poweredge/2007-December/034160.html 10GB file: * RAID5 : 255MB/s * RAID10 : 224MB/s (???) 2 x 10GB file (simultaneos) * RAID5 : 2 x 36MB/s * RAID10 : 2 x 31MB/s (ouch!) esos datos muestran que la controladora es deficiente, los datos resultantes lo avalan, de hecho el mismo autor lo declara, no debieras poner esto como ejemplo. Bueno, lo puse porque es similar a lo que obtuve yo en mis pruebas... y en tal caso es lo que importa, al fin y al cabo es lo que se va a usar. el problema de raid 5 es que no escala bien con las escrituras... como lo mencionó Horst, el número IO's que raid 5 es capaz de manejar se determina por la formula siguiente: [ IO_lecturas + (4 * IO_escrituras) ] / n°_discos en el caso de raid 10 es [ IO_lecturas + (2 * IO_escrituras)] / n°_discos al incrementar el nº de discos mejora considerablemente la lectura (analogía de los platos que mencionas) , y en el caso de la escritura gana raid10 pues sólo se duplica la operación, no cuadriplica como en el caso de raid5. Tienes razon en que me he fijado solo en la lectura. Ahora, esta parte no la entiendo, porque 4* y 2* ? Si tienes 4 discos, escribir un stripe: - en raid5: significa leer 2 y escribir 2 stripes. - en raid10: significa escribir 4 stripes. La penalidad de raid5 es que primero leo y luego escribo, mientras que en raid10 solo escribo. No veo la duplicidad ni cuadriplicidad _en tiempo_ de la operacion, estoy asumiendo que escribo/leo al mismo tiempo en todos los discos (como si fueran platos extras). Tambien hay algo extran~o en la formula, por lo siguiente: un ejemplo para ilustrar lo anterior. carga de 500 I/Os con 10 discos para RAID5 LecturasEscriturasI/Os RAID_5 -- 100,00%0,00%(500 + 0) / 10= 50 90,00%10,00% (450 + 200) / 10 = 65 75,00%25,00% (375 + 500) /10 = 87,5 50,00%50,00% (250 + 1000) / 10 = 125 0,00%100,00% (0 + 2000) / 10 = 200 LecturasEscriturasI/Os RAID_10 -- 100,00%0,00%(500 + 0) /10 = 50 90,00%10,00% (450 + 100) / 10 = 55 75,00%25,00% (375 + 250) / 10 = 62.5 50,00%50,00% (250 + 500) / 10 = 75 0,00%100,00% (0 + 1000) / 10 = 100 Con 10 discos y solo lectura deberias tener performance de 9x para raid-5 y 5x para raid-10; pero tus calculos no muestran eso. Me parece que estas calculando la carga que lleva cada disco (divides por el numero de discos) en vez del rendimiento (yo usaria alguna medida de ancho de banda, como KiB/s) para el conjunto en total. -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
Victor Hugo dos Santos escribió: mmm.. en mi caso, LVM es esencial por los snapshots. lo usamos principalmente para disminuir el tiempo en que los servicios estaban detenidos por que se estaban ejecutando respaldos de los datos, o sea: - se detiende los servicios - se crea el snap - se llevanta los servicios - se respalda los datos desde el snap desconozco si hay alguna otra altrenativa a LVM+SNAP en ext3. Hay filesystems que implementan snapshots (y otras cosas) nativamente, como ZFS. Si de paso saltas a OpenSolaris, vas a tener la posibilidad de usar DTrace tambien ;-) (BTW Postgres tiene un conjunto propio de trazas para DTrace, que yo no he probado nunca pero he oído que son muy buenas para diagnosticar problemas de rendimiento). Ah, y si lo que quieres es DTrace, está en otros sistemas operativos, como FreeBSD y Mac OS X. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC God is real, unless declared as int
Re: strip/block size y otros temas de RAID (largo)
Aldrin Martoq escribió: On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: Me parece que RAID-5 seria lo mejor para performance/confiabilidad. Las mediciones de rendimiento que han hecho varias personas en pgsql-performance han mostrado que RAID-10 es muy superior a RAID-5. Hmmm estaba revisando y muchos sitios dicen lo mismo. Basicamente, RAID-5 es superior en lectura y RAID-10 es superior en escritura. La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team. Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
Re: strip/block size y otros temas de RAID (largo)
2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Aldrin Martoq escribió: On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: [...] La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). mmm.. es provable.. pero has escuchado comentarios de alguna que sea buena ??? cuales ?? salu2 y buenas fiestas. -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
Aldrin Martoq escribió: On Wed, 2008-12-31 at 11:12 -0300, Horst H. von Brand wrote: 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. Han hecho un strace -c /bin/ls / por ejemplo? Es basicamente el mismo tipo de informacion que uno necesita cuando usa DTrace o Systemtap. Me imagino que se podria modificar para extraer mas datos relevantes que a uno le pueda interesar... El problema de strace es que muestra la información a un nivel muy lejano. Sólo tienes el dato de cuando se entra y sale de cada syscall, pero no sabes nada de qué cosas pasan por debajo (por ej. cuales llamadas a read leen del disco y cuales traen cosas de algún cache). Ni tampoco qué cosas pasan más arriba, por ejemplo dónde se hace cada llamada a read, o por qué la aplicación parece estar haciendo un montón de llamadas a stat() que en realidad las hace libc o alguna otra biblioteca. Para diagnosticar algunos problemas yo he usado oprofile, que es bastante más que strace (pero bastante menos que DTrace). Uno de los problemas que me han ocurrido con strace es que las aplicaciones se ven afectadas (creo que el tema de signals)... Varias veces hacer strace a un proceso java he terminado con la jvm colgada. Claro, eso puede ser un problema que no tienes con DTrace. Lo otro es que strace afecta el rendimiento de la aplicación, mientras que DTrace es mucho menos intrusivo en este aspecto. -- Alvaro Herrerahttp://www.amazon.com/gp/registry/3BP7BYG9PUGI8 Most hackers will be perfectly comfortable conceptualizing users as entropy sources, so let's move on. (Nathaniel Smith)
Re: strip/block size y otros temas de RAID (largo)
On Wed, 2008-12-31 at 12:58 -0300, Victor Hugo dos Santos wrote: 2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Aldrin Martoq escribió: On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). mmm.. es provable.. pero has escuchado comentarios de alguna que sea buena ??? cuales ?? Estoy seguro que obtendras el mejor rendimiento con el raid nativo de linux, pero tendras un buen gasto de CPU... Del resto, has las pruebas correspondientes no mas en el tarro que tengas ... depende mucho de tu aplicacion. -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
Aldrin Martoq escribió: On Wed, 2008-12-31 at 12:58 -0300, Victor Hugo dos Santos wrote: 2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Aldrin Martoq escribió: On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). mmm.. es provable.. pero has escuchado comentarios de alguna que sea buena ??? cuales ?? Estoy seguro que obtendras el mejor rendimiento con el raid nativo de linux, pero tendras un buen gasto de CPU... El problema es que no puedes tener un cache respaldado por baterias en este caso (cosa que Victor Hugo ya dijo que tenía). Para una base de datos puede ser una diferencia sustancial. Del resto, has las pruebas correspondientes no mas en el tarro que tengas ... depende mucho de tu aplicacion. /me nods -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3, W 73º 15' 24.7 En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica (Irulan)
Re: strip/block size y otros temas de RAID (largo)
Victor Hugo dos Santos listas@gmail.com wrote: 2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Aldrin Martoq escribió: On Wed, 2008-12-31 at 10:05 -0300, Alvaro Herrera wrote: [...] La data que muestro (LVM, RAID) fueron pruebas personales contra el tarro, probb mis pruebas estuvieron malas en algun punto. Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oÃdo muchas veces que las controladores RAID Adaptec son horribles, y algunas que solÃan venir con Dell hace años también). mmm.. es provable.. pero has escuchado comentarios de alguna que sea buena ??? cuales ?? Sgun lo que lei (hace tiempo!), el RAID por software de Linux era mejor que todas las controladoras RAID por hardware. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: strip/block size y otros temas de RAID (largo)
Victor Hugo dos Santos escribió: 2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). mmm.. es provable.. pero has escuchado comentarios de alguna que sea buena ??? cuales ?? Sí, algunos (LSI, Areca) ... por ej. acá hay un par de recomendaciones http://archives.postgresql.org/pgsql-performance/2008-12/msg00121.php Puedes seguir buscando los archivos de la lista pgsql-performance: http://search.postgresql.org/search?q=good+raid+controller+marlowem=1l=13d=365s=r Echale un vistazo a los artículos de Scott Marlowe o Greg Smith (Luke Lonergan también podría haber sido pero hace mucho que no participa) -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ Someone said that it is at least an order of magnitude more work to do production software than a prototype. I think he is wrong by at least an order of magnitude. (Brian Kernighan)
Re: strip/block size y otros temas de RAID (largo)
[Yep, el termino stripe lo use muy mal] On Wed, 2008-12-31 at 13:08 -0300, Marcelo Espinosa Alliende wrote: El mié, 31-12-2008 a las 11:38 -0300, Aldrin Martoq escribió: Tambien hay algo extran~o en la formula, por lo siguiente: un ejemplo para ilustrar lo anterior. carga de 500 I/Os con 10 discos para RAID5 LecturasEscriturasI/Os RAID_5 -- 100,00%0,00%(500 + 0) / 10= 50 90,00%10,00% (450 + 200) / 10 = 65 75,00%25,00% (375 + 500) /10 = 87,5 50,00%50,00% (250 + 1000) / 10 = 125 0,00%100,00% (0 + 2000) / 10 = 200 LecturasEscriturasI/Os RAID_10 -- 100,00%0,00%(500 + 0) /10 = 50 90,00%10,00% (450 + 100) / 10 = 55 75,00%25,00% (375 + 250) / 10 = 62.5 50,00%50,00% (250 + 500) / 10 = 75 0,00%100,00% (0 + 1000) / 10 = 100 Con 10 discos y solo lectura deberias tener performance de 9x para raid-5 y 5x para raid-10; pero tus calculos no muestran eso. no, el comportamiento en operaciones de IO es igual para ambos, aquí lo que te dice es que cada disco va a manejar ese volumen de IOs y punto. A ver, si es la cantidad de operaciones por disco lo estas calculando mal. LOS SUPUESTOS aca son: - no hay cache o los datos no estan en el - la escalabilidad del numero de operaciones/disco es un buen indicador - raid 10 lee de ambos espejos (lo llamare RAID nuevo mas abajo) PARA RAID-5 - si tenemos 500 lecturas a distribuir en 10 discos, cada disco debera ejecutar 500/9 lecturas (ya que un disco no almacena datos). - si tenemos 500 escrituras sobre 10 discos, cada escritura toma 2 lecturas y 2 escrituras; luego cada disco hace 500*4/9 operaciones. La formula es: operaciones/disco = (lecturas + escrituras*4)/(n_discos - 1) PARA RAID-10 viejo - este es el RAID10 que supongo yo esta implementado - aca supongo que el raid _compara_ lo que lee desde un espejo y el otro - luego, 500 lecturas se duplican entre espejos, osea son 100 lecturas por disco. - cuando escribe, escribe en ambos espejos. 500 escrituras son 100 escrituras por disco. La formula seria: operaciones/disco = (lecturas*2 + escrituras*2)/n_discos PARA RAID-10 nuevo - aca suponemos que las lecturas son alternadas entre espejos; luego 500 lecturas son 500/10 = 50 lecturas por disco - cuando escribe, escribe en ambos espejos. 500 escrituras son 100 escrituras por disco. La formula seria: operaciones/disco = (lecturas + escrituras*2)/n_discos Resumiendo en una tabla: operaciones/disco #disk #oper #read #write RAID-5 RAID-10 RAID10 nuevo 10500 100% 0% 55.56 100 50 10500 90% 10% 72.22 100 55 10500 75% 25% 97.22 100 62.50 10500 50% 50% 138.89 100 75 10500 0%100%222.22 100 100 por mucho cache que le pongas a la controladora, si tienes más de un 10% de escrituras raid10 se va a comportar mejor que raid 5 y punto... Hmm segun tu tabla original, RAID-10 siempre es mejor y en el caso 100% lectura es igual que RAID-5. Segun la mia, RAID-10 nuevo es mejor _siempre_. Eso en la practica es claramente incorrecto. Lo que esta mal de tu tabla y de mi tabla son los supuestos. Veamos los supuestos: - no hay cache: ok, yo tambien jugaba sin cache. Puede que no tengas cache si lees/escribas data nunca vista. Pero ese no es un caso muy real, en el mejor caso (esta en cache) RAID-5 escribe en 2 discos, igual que RAID-10. - RAID-10 lee de ambos discos: me parece que esto no pasa en las controladores que he visto. Creyendole a mi tabla, RAID-10 debe ser SIEMPRE superior a RAID-5 (ya que tienes el ancho de banda de 10 discos en vez de 9 en modalidad lectura). Pero en la practica esto no sucede o no lo he visto. - el # operaciones por disco es un buen indicador: insisto en que el real indicador debe ser el ancho de banda. el # operaciones no considera que en la escritura de un stripe en RAID-5 hay un delay importante al leer todos los discos y luego escribir 2 discos. Tampoco estas considerando que en la escritura de un stripe, cuando escribes, escribes en los 10 discos. Si bien es al mismo tiempo, el tema del tiempo de busqueda influye en el tiempo en que termine esa operacion (por eso insisto que son 10 escrituras al mismo tiempo). Hay otro item que no ves con el indicador de #operaciones/disco: en RAID-5 tienes mucho mas espacio disponible. Entonces, un stripe almacena mas datos en un RAID-5 que en un RAID-10 (casi el doble). Esto significa que en cualquier operacion, si lees el taman~o de un stripe completo en RAID-5 solo ocuparas 1 vez los discos, en RAID-10 los ocuparas 2 veces. Ya estoy
Re: strip/block size y otros temas de RAID (largo)
2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). Hey, ni tanto con las Adaptec! :-) He escuchado de algunos modelos malitos pero en mi corta experiencia, he tenido buenos resultados con esa marca. -- http://www.mgonzalez.cl/
Re: strip/block size y otros temas de RAID (largo)
Mario Gonzalez escribió: 2008/12/31 Alvaro Herrera alvhe...@alvh.no-ip.org: Quizás las pruebas no estaban malas sino que las hiciste con hardware penca (por ej. he oído muchas veces que las controladores RAID Adaptec son horribles, y algunas que solían venir con Dell hace años también). Hey, ni tanto con las Adaptec! :-) He escuchado de algunos modelos malitos pero en mi corta experiencia, he tenido buenos resultados con esa marca. Parece que hay otros que están de acuerdo contigo, por ej. http://www.nabble.com/Adaptec-5805-SAS-Raid-td16056447.html -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ La conclusión que podemos sacar de esos estudios es que no podemos sacar ninguna conclusión de ellos (Tanenbaum)
Re: strip/block size y otros temas de RAID (largo)
Victor Hugo dos Santos escribió: pero has escuchado comentarios de alguna que sea buena ??? cuales ?? El comentario de Mario me hizo llegar a este thread donde también hay algunas recomendaciones y comentarios generales sobre discos y controladoras: http://markmail.org/message/vapnntifqchr5t4c#query:+page:1+mid:sfxodr5wuuxzgnmt+state:results -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ Java is clearly an example of money oriented programming (A. Stepanov)
strip/block size y otros temas de RAID (largo)
Hola a todos, como van las fiestas para fin de año ??? 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 2 - no tengo problemas de performance en estes momentos, pero quiero descubrir hasta donde puedo llegar (en mejoria) manteniendo los datos seguros. 3 - los 4 servidores que tengo para pruebas, son PowerEdge 2950 ( 2 x Intel(R) Xeon(R) CPU X5460 @ 3.16GHz) y32768 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) 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 y dentro del sistema operativo tengo las siguientes particiones y LVM === $ sudo fdisk -l Disco /dev/sda: 1198.2 GB, 1198295875584 bytes 255 heads, 63 sectors/track, 145684 cylinders Unidades = cilindros de 16065 * 512 = 8225280 bytes Disposit. InicioComienzo Fin Bloques Id Sistema /dev/sda1 * 1 32 257008+ 83 Linux /dev/sda2 33316825189920 8e Linux LVM /dev/sda33169 145684 11447597705 Extendida /dev/sda53169 65416 57028+ 8e Linux LVM /dev/sda6 65417 127664 57028+ 8e Linux LVM [vic...@blue etc]$ sudo lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert applVG_DATOS -wi-ao 20,00G dataVG_DATOS -wi-ao 400,00G raiz VG_SYS -wi-ao 20,00G swap VG_SYS -wi-ao 4,00G === 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) - crear en la controladora un volume de discos para la particion / (~ 20 GB) - 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 ~) bien.. hacendo esto, las particiones / y /var/data usarian el sector 0 de los volumenes y estarian alinadas case que por defecto con los strip size de los RAIDs 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) * 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. no se si me explique bien mi duda !!! (sorry) * 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 ?? bueno, considerando que: - las particiones estan alinadas con los volumenes - el strip size sea 64K - el arreglo en RAID 10 entonces, formateo las particiones con el siguiente comando: sudo mkfs.ext3 -E stride=16 /dev/VG_DATOS/data bueno, utilizo el valor 16 en base al calculo (stride = strip size / block size) y se que el valor por defecto del block size para ext3 es 4K pero sera este valor (4K) el mejor para BDs ?? alguna otra recomendacion ?? en el enlace (http://wiki.centos.org/HowTos/Disk_Optimization) indica algunos parametros para montar las particiones: notime creo que no es tan necesario para las BD, por que son pocos archivos pero de gran tamano commit suena interesante, principalmente por que hay la controladora RAID tiene una bateria. writeback la verdad, verdadera es que no entendi del todo. :-( y todo esto ira en el fstab: /dev/VG_DATOS/data /var/data defaults,noatime,commit=120,data=writeback 0 0 pero son realmente seguros con la actual configuracion que tengo ?? comentarios ?? bien.. por ultimo (finalmente), en el segun y ultimo link (2 y 4) comentan sobre la posibilidad de aumentar el read-a-head de los dispositivos RAIDs.. en el segundo enlace menciona el comando:
Re: strip/block size y otros temas de RAID (largo)
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: 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 2 - no tengo problemas de performance en estes momentos, pero quiero descubrir hasta donde puedo llegar (en mejoria) manteniendo los datos seguros. 3 - los 4 servidores que tengo para pruebas, son PowerEdge 2950 ( 2 x Intel(R) Xeon(R) CPU X5460 @ 3.16GHz) y32768 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) En mi experiencia, LVM es LENTO, segun las ultimas pruebas que hice (un tarro parecido al que muestras). Cambia alguna particion (/var ?) y haz alguna prueba sencilla y nos avisas, pues no tengo numeros! 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 y dentro del sistema operativo tengo las siguientes particiones y LVM En mis pruebas, separar el arreglo fisico similar al _USO_ que tendra en el sistema operativo ayuda bastante. La primera vez hice lo mismo: un puro arreglo RAID-6 con 8 discos, al final era mas lento porque tenia varias aplicaciones escribiendo en el disco y si bien el arreglo _era_ muy rapido, tenias lecturas/escrituras que estaban encoladas. Se veia a simple vista: todas las lucecitas constantemente moviendose de TODOS los discos. Esto es mas lento porque en el fondo tienes un puro disco con varios platos, esto influye en el seek time y se encolan si tienes varias aplicaciones distintas corriendo al mismo tiempo. 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. Varios: - recuerda que los discos de un lote son mas propensos a fallar una vez que fallo el primero: apenas falle un disco comienza a buscar reemplazos! http://lwn.net/Articles/237924/ - luego: cuando tienes esta cantidad de espacio, busca donde dejar los respaldos (data y APLICACIONES). 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) - crear en la controladora un volume de discos para la particion / (~ 20 GB) - 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 ~) Separalos en base al USO. Yo tenia varias maquinas virtuales, lo que hice fue poner unas en 1 arreglo y otras en el otro arreglo; alternadas segun cuando se usan. Me parece que RAID-5 seria lo mejor para performance/confiabilidad. Te recomiendo separar en dos grupos de 3 y 3 discos, en cada grupo crea mas de un arreglo RAID (cada arreglo lo veras como un disco sdX). Luego en la marcha, segun el uso, puedes mover un arreglo entre un grupo y el otro. Algo asi: grupo 1grupo 2 |D1 D2 D3| |D4 D5 D6| | sda | | sde | | sdb | | sdf | | sdc | | sdg | ++ ++ Entonces, puedes dejar por ejemplo: sda / sde /backup sdb /database1 sdf /database2 sdc swapsdg /test 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... 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 Podrias intentarlo con systemtap o por ultimo strace y nos cuentas ;) -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: Hola Victor, muy largo lo que escribiste, tratare de aportar un poco ;) siii.. gracias !! :D [...] En mi experiencia, LVM es LENTO, segun las ultimas pruebas que hice (un tarro parecido al que muestras). Cambia alguna particion (/var ?) y haz alguna prueba sencilla y nos avisas, pues no tengo numeros! anotado.. hare la prueba en la siguiente semana. [...] En mis pruebas, separar el arreglo fisico similar al _USO_ que tendra en el sistema operativo ayuda bastante. La primera vez hice lo mismo: un puro arreglo RAID-6 con 8 discos, al final era mas lento porque tenia varias aplicaciones escribiendo en el disco y si bien el arreglo _era_ muy rapido, tenias lecturas/escrituras que estaban encoladas. Se veia a simple vista: todas las lucecitas constantemente moviendose de TODOS los discos. Esto es mas lento porque en el fondo tienes un puro disco con varios platos, esto influye en el seek time y se encolan si tienes varias aplicaciones distintas corriendo al mismo tiempo. sospeche desde el principio !! pero en este caso, estas maquinas estan dedicada unica y exclusivamente a las BD.. asi, que creo que la particion que realmente tendra carga es la de datos. [...] - recuerda que los discos de un lote son mas propensos a fallar una vez que fallo el primero: apenas falle un disco comienza a buscar reemplazos! http://lwn.net/Articles/237924/ interesante el articulo.. pena que los links llevan a documentos que necesitan suscripcion ($$$) para visulizarlos. - luego: cuando tienes esta cantidad de espacio, busca donde dejar los respaldos (data y APLICACIONES). esto ya esta considerado.. vamos a tener servidores redundantes.. en otras palabras: redundantemente problematicos !! ;-) [...] Separalos en base al USO. Yo tenia varias maquinas virtuales, lo que hice fue poner unas en 1 arreglo y otras en el otro arreglo; alternadas segun cuando se usan. Me parece que RAID-5 seria lo mejor para performance/confiabilidad. mmm.. en esto discrepo de vos.. por que en el caso del RAID 5, la controladora debe de calcular las paridades (o como se llame).. y esto consume recursos.. en el caso del RAID 10 (y otros), esto no ocurre.. generando una mejor performance en este aspecto. http://es.wikipedia.org/wiki/RAID#RAID_1.2B0 Obs.: es la primera vez que veo que un articulo en español esta mucho mas detallado que en ingles en la wikipedia !! :) [...] Creo que todo esto lo sabriamos si tuvieramos DTrace, asi no tendriamos que adivinar... 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 interesante.. lo estoy revisando. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
Victor Hugo dos Santos listas@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) y32768 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
Re: strip/block size y otros temas de RAID (largo)
On Tue, 2008-12-30 at 15:51 -0300, Horst H. von Brand wrote: [...] 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. Este ejemplo es un clásico. Y me atrevería a decir que es la norma, más que la excepción. Después de la segunda o tercera iteración, recién se comienza a asumir que el problema puede estar en las consultas, la aplicación o alguna combinación de éstas. -- Germán Póo-Caamaño http://www.calcifer.org/
Re: strip/block size y otros temas de RAID (largo)
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. 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. Varios: - recuerda que los discos de un lote son mas propensos a fallar una vez que fallo el primero: apenas falle un disco comienza a buscar reemplazos! http://lwn.net/Articles/237924/ - luego: cuando tienes esta cantidad de espacio, busca donde dejar los respaldos (data y APLICACIONES). Esa es la idea de RAID (la I, originalmente de inexpensive: juntar montones de discos chicos y baratos para obtener capacidades (y confiabilidad) de disco inmenso y exageradamente caro). [...] 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. Podrias intentarlo con systemtap o por ultimo strace y nos cuentas ;) No creo que strace(1) ayude mucho aca? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
LWN [Was: Re: strip/block size y otros temas de RAID (largo)]
Victor Hugo dos Santos listas@gmail.com wrote: 2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: [...] - recuerda que los discos de un lote son mas propensos a fallar una vez que fallo el primero: apenas falle un disco comienza a buscar reemplazos! http://lwn.net/Articles/237924/ interesante el articulo.. pena que los links llevan a documentos que necesitan suscripcion ($$$) para visulizarlos. Los articulos de LWN son restringidos a los subscriptores por una semana (o un poco mas). Los $$$ que pago por la subscripcion a LWN mas que lo valen. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: LWN [Was: Re: strip/block size y otros temas de RAID (largo)]
On Tue, 2008-12-30 at 17:00 -0300, Horst H. von Brand wrote: Victor Hugo dos Santos listas@gmail.com wrote: 2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: - recuerda que los discos de un lote son mas propensos a fallar una vez que fallo el primero: apenas falle un disco comienza a buscar reemplazos! http://lwn.net/Articles/237924/ interesante el articulo.. pena que los links llevan a documentos que necesitan suscripcion ($$$) para visulizarlos. Los articulos de LWN son restringidos a los subscriptores por una semana (o un poco mas). Los $$$ que pago por la subscripcion a LWN mas que lo valen. Bueno, es un articulo viejo y esta disponible a cualquiera. Tambien hice clic en el primer informe y lo veo perfectamente! http://usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
On Tue, 2008-12-30 at 15:35 -0300, Victor Hugo dos Santos wrote: 2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: En mis pruebas, separar el arreglo fisico similar al _USO_ que tendra en el sistema operativo ayuda bastante. La primera vez hice lo mismo: un puro arreglo RAID-6 con 8 discos, al final era mas lento porque tenia varias aplicaciones escribiendo en el disco y si bien el arreglo _era_ muy rapido, tenias lecturas/escrituras que estaban encoladas. Se veia a simple vista: todas las lucecitas constantemente moviendose de TODOS los discos. Esto es mas lento porque en el fondo tienes un puro disco con varios platos, esto influye en el seek time y se encolan si tienes varias aplicaciones distintas corriendo al mismo tiempo. sospeche desde el principio !! pero en este caso, estas maquinas estan dedicada unica y exclusivamente a las BD.. asi, que creo que la particion que realmente tendra carga es la de datos. Crea los grupos/arreglos que te recomende, despues en la marcha intercalas las bases de datos que tienen mas carga. Me parece que RAID-5 seria lo mejor para performance/confiabilidad. mmm.. en esto discrepo de vos.. por que en el caso del RAID 5, la controladora debe de calcular las paridades (o como se llame).. y esto consume recursos.. en el caso del RAID 10 (y otros), esto no ocurre.. generando una mejor performance en este aspecto. http://es.wikipedia.org/wiki/RAID#RAID_1.2B0 Obs.: es la primera vez que veo que un articulo en español esta mucho mas detallado que en ingles en la wikipedia !! :) Haz la prueba, de hecho en el primer link que mandaste el tipo muestra la conversa en una lista y del primer link: http://lists.us.dell.com/pipermail/linux-poweredge/2007-December/034160.html 10GB file: * RAID5 : 255MB/s * RAID10 : 224MB/s (???) 2 x 10GB file (simultaneos) * RAID5 : 2 x 36MB/s * RAID10 : 2 x 31MB/s (ouch!) La diferencia es que si tienes 4 discos por ejemplo, en: RAID 5 tienes el performance de 3 discos. RAID 10 tienes el performance de 2 discos. Otra ganancia es que con RAID10 necesitas un numero par de discos, con RAID5 tienes velocidad y 1 disco backup con cualquier numero de discos a partir de 3. El calculo de paridad es muy simple (XOR creo), es varias veces mas rapido que el disco. Tambien es posible que consigas mejor performance usando el raid por software de linux, ya que el algoritmo de ordenamiento ante varios lectores/escritores sera mejor que el de la controladora. El costo es que te consume CPU, pero si tienes tantos cores podrias ocupar uno de esos ;) -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
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. 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 amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: strip/block size y otros temas de RAID (largo)
2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: On Tue, 2008-12-30 at 16:58 -0300, Horst H. von Brand wrote: Aldrin Martoq amar...@dcc.uchile.cl wrote: [...] 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. obs.: en mi caso es una applicaccion (oracle y postgresql) para cada servidor !!! salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: On Tue, 2008-12-30 at 15:35 -0300, Victor Hugo dos Santos wrote: 2008/12/30 Aldrin Martoq amar...@dcc.uchile.cl: [...] Haz la prueba, de hecho en el primer link que mandaste el tipo muestra la conversa en una lista y del primer link: http://lists.us.dell.com/pipermail/linux-poweredge/2007-December/034160.html [...] La diferencia es que si tienes 4 discos por ejemplo, en: RAID 5 tienes el performance de 3 discos. RAID 10 tienes el performance de 2 discos. mmm.. en mi caso serian 6 discos.. ;-) veamos que pasa. por cierto, acabo de ir a configurar la controladora para hacer pruebas.. pero he descubirto que la controladora (sera esta en particular ???), permite crear el RAID10, pero no me permite crear volumenes logicos en el.. o sea, se utilizo RAID10/RAID50/RAID60 debo de usar un solo volumen con todo el espacio de los discos. he llamado a DELL y segun ellos es imposible hacer esto de crear discos virtuales/volumenes dentro de estes tipos de RAIDs ahora toy buscando info en internet para ver las alternativas que tengo: For RAID levels 0, 1, 5, and 6 only, you can use part of the available disk space to create one virtual disk and then use the rest of the disk space to create another virtual disk or disks. y recomendaron que: ponga los 2 primeros discos en RAID-1 (SO) y los 4 restantes en RAID-10 plop !!! que malo no ??? salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Re: strip/block size y otros temas de RAID (largo)
On Tue, 2008-12-30 at 18:37 -0300, Victor Hugo dos Santos wrote: por cierto, acabo de ir a configurar la controladora para hacer pruebas.. pero he descubirto que la controladora (sera esta en particular ???), permite crear el RAID10, pero no me permite crear volumenes logicos en el.. o sea, se utilizo RAID10/RAID50/RAID60 debo de usar un solo volumen con todo el espacio de los discos. No hagas volumenes con la controladora, solo creas arreglos que seran vistos como discos en el sistema operativo... Por ejemplo, un arreglo RAID-10 con los sectores 0-99 de los discos 1, 2 y 3. Luego otro arreglo RAID-5 con los sectores 100-199 de los discos 1, 2 y 3. Para hacer justa la prueba, deberias mover uno de los discos al otro canal. Ej de prueba: ++ ++ |D1 D2 D3| |D4 D5 D6| ++ 0++ 0 | sda r10| | sdc r5 | ++ 100 ++ 100 | sdb r5 | | sde r10| ++ 200 ++ 200 For RAID levels 0, 1, 5, and 6 only, you can use part of the available disk space to create one virtual disk and then use the rest of the disk space to create another virtual disk or disks. Hmmm si no se puede, usa el D1 D2 D3 con RAID-10 completo, y en el D4 D5 D6 Raid5. ++ ++ |D1 D2 D3| |D4 D5 D6| ++ 0++ 0 | sda r10| | sdb r5 | ++ 200 ++ 200 Tambien haz la prueba de RAID por software, ahi seguro que puedes! -- Aldrin Martoq amar...@dcc.uchile.cl http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: LWN [Was: Re: strip/block size y otros temas de RAID (largo)]
Horst H. von Brand escribió: Los $$$ que pago por la subscripcion a LWN mas que lo valen. Efectivamente, es una muy buena fuente de informacion, yo era subscriptor particular tambien, actualmente estoy dentro de la subscricion coorporativa de SUSE eso si ;) -- We have art in order not to die of the truth - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research Development http://www.opensuse.org/
