[opensuse-es] 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-perform... 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.: 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) 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) 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. Inicio Comienzo Fin Bloques Id Sistema /dev/sda1 * 1 32 257008+ 83 Linux /dev/sda2 33 3168 25189920 8e Linux LVM /dev/sda3 3169 145684 1144759770 5 Extendida /dev/sda5 3169 65416 500007028+ 8e Linux LVM /dev/sda6 65417 127664 500007028+ 8e Linux LVM [victor@blue etc]$ sudo lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert appl VG_DATOS -wi-ao 20,00G data VG_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: /sbin/blockdev --setra 8192 /dev/sdb y en el ultimo enlace menciona el comando: echo 1024 > /sys/block/sda/queue/read_ahead_kb que imagino que en esencia hacen exactamente el mismo.. pero hay alguna formula para obtener el mejor valor para el "read-a-head" o es en prueba y error ?? y principalmente, cual es el mejor metodo (o archivo de configuracion) para dejar este valor seteado como predefinido ?? ufff.. sorry por el largo del correo ... salu2 y atento a cualquier comentarios. -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) El Tuesday 30 December 2008, Victor Hugo dos Santos escribió:
Hola a todos, como van las fiestas para fin de a�o ???
Bien, en familia. ¿Tú qué tal?
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-perfor mance-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
No me extraña que tengas dudas existenciales después de leer tu correo. Las BBDD son peculiares ... Vamos a ver si te puedo ayudar ... De buenas a primeras, lo mejor que puedes hacer para una BBDD e ponerle mucha RAM, cuanta más, mejor. Otro consejo es trabajar con 64 bits (para aprovechar al máximo toda la RAM qeu le puedas poner). Las CPUs no suelen ser un cuello de botella a menos que tengas muchas búsquedas, triggers y esas cosas. Es ppreferible que sean CPUs de pocos cores, así evitarás cuellos de botella al acceder a la RAM. En las BBDD separa el log y los datos (tablas): - log: RAID 1 ó RAID 10 - datos: RAID 5 ó 6, RAID 10 también puede ser interesante Importante, que sean RAIDs _DIFERENTES_.
Obs.: 2 - no tengo problemas de performance en estes momentos, pero quiero descubrir hasta donde puedo llegar (en mejoria) manteniendo los datos seguros.
Backups ;)
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
¿32 MB? Me imagino que te habrás equivocado y serán 32 GB, ¿verdad? La CPU es quad-core y de 3.16 GHz, hubiera sido preferible una dual-core para no saturar tanto el bus CPU-RAM. Veo que tienes el X5460. El consumo es de 120 W y el front side bus es de 1333. Yo hubiera preferido el E5462 que, aunque tiene menos GHz (2.8 GHz), tiene dos ventajas: - bus a 1600 MHz - 80 W Si quieres más ciclos, también tienes el E5472.
canal 0 y 2 en el canal 1) discos Seagate Cheetah NS SAS (3Gb/s 400-GB y 16 MB de cache)
Discos interesantes, buena elección.
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
Mal. Tendrías que tener diferentes RAIDs para cada partición. Como diría Camaleón: -1. Usas LVM sin realmente necesitarlo: aumentas la carga del sistema innecesariamente: -1. Los volúmenes lógicos están bien cuando hablamos de discos (o LUNs) de más de 2 TB (suponiendo que la controladora y/o tu Linux no soporten discos de más de 2 TB). Si los soportan ... evita en la medida de lo posible LVM. Otra razón para usar LVM es que tengas 2 LUNs, por ejemplo, de 8+1 discos. No es aconsejable hacer LUNs de más de 8+1 discos porque aumenta la probabilidad de qu ete fallen 2 discos dentro de un mismo LUN. En ese caso, para juntar ambos LUNs, utilizarías LVM. [...]
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
Aquí tienes un problema muy grande y es que tienes pocos discos y tienes que hacer muchas cosas. lo ideal sería hacer las siguientes particiones: / -> RAID 1 (o hacer imágenes) -> 2 discos, pueden ser SATA swap -> RAID 0 es muy rápido, aunque si se pierde el disco ... puedes perder datos que estén en swap y no se hayan escrito a disco -> dos discos (pueden ser los mismo que los de /) /var/datos -> RAID 10, 5 ó 6 -> al menos 4 discos (SAS, 73 GB y 15 krpm) aunque depende del espacio que necesites para tu filesystem. Quizás necesites más. /logs -> RAID 10 Esta partición _NO_ es para /var/log, es para el log de la BBDD, _EXCLUSIVAMENTE_ -> al menos 4 discos (SAS, 73 GB y 15 krpm) aunque depende del espacio que necesites para tu filesystem, aunque no creo que necesites más /var/log -> RAID 10 -> al menos 4 discos (SAS, 73 GB y 15 krpm) aunque depende del espacio que necesites para tu filesystem, aunque no creo que necesites más OJO !!!! Aunque /logs (o como lo quieras llamar) y /var/datos sean las dos RAID 10, _NO LAS PONGAS JUNTAS_ !!!! El log suele escribir mucho y muy pequeño, es deicr, crea muchos IOPS. Los datos no, luego puedes encontrarte que uno afecta al otro y cae el rendimiento. Separar estas particiones es para evitar que las IOPS de uno afecten al otro. No es lee/escribe de la misma manera en /var/datos que en / o en /logs. Tenemos la bonita cifra de 14 discos: 12 SAS (73 GB y 15 krpm) y 2 SATA.
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)
Al tner todo en el mismo RAID, estás vendido. Usa el tamaño que se ha definido en el RAID o múltiplo del mismo. Si fueran diferentes tipos de RAID, para uno y otro, sí te podría ser interesante definir el stripe unit y stripe width para cada uno. En tu caso, sólo tienes un RAID por lo que si usas diferentes stripe units, lo que puedes hacer es afectar negativamente al resto. / no suele escribir y leer mucho así que no te preocupes por ella porque sólo es importante durante el arranque. Las demás sí que te tienen que preocupar.
* 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)
El stripe unit lo que define es el tamaño de bloque que se va a escribir a disco. Es decir, si defines un stripe unit de 8K, lo que estás diciendo es que se van a escribir a disco de 8 KB en 8 KB. No es que un fichero de 2 KB te vaya a ocupar esos 8 KB enteros, eso depende del sistema de ficheros. En todo caso, lo ideal es que el stripe unit sea = al tamaño de bloque del sistema de ficheros. Así, ambos escriben "al mismo tiempo". Imagínate que tu stripe unit es de 8 KB y el tamaño de bloque en tu filesystem es de 2 KB. El filesystem intentará escribir cada 2 KB a disco mientras que la controladora intnetará escribir cada 8. Otra cosa, habla con Oracle y a ver qué te aconsejan ellos. Oracle es muy fastidioso con cómo escribe a disco. Otra cosa, ¿qué contiene tu BBDD? ¿Cuántos accesos simultáneos soporta? ...
* 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 ??
No que yo sepa. Tendrías que hacer un find, sumar el tamaño de cada fichero y luego hacer la media. No es fácil hacer esas cosas.
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 ??
Habla con Oracle y que te aconsejen.
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.
¿Cuánto tiempo te da la batería? La batería protege a la caché de la controladora, ¿qué tamaño tiene la caché de la controladora? Recuerda que lo que esté en RAM se pierde. Pon mejor un SAI ;)
writeback la verdad, verdadera es que no entendi del todo. :-(
Los sistemas de ficheros en journal tienen dos partes (sub volúmenes): log y datos (XFS tiene 3, siendo el tercero tiempo real). En el caso de ext3, el comportamiento puede ser: - ordered: se escriben los datos y luego el journal - writeback: se escriben datos y journal sin orden - journal: se escribe primero el log y luego los datos
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: /sbin/blockdev --setra 8192 /dev/sdb y en el ultimo enlace menciona el comando: echo 1024 > /sys/block/sda/queue/read_ahead_kb que imagino que en esencia hacen exactamente el mismo.. pero hay alguna formula para obtener el mejor valor para el "read-a-head" o es en prueba y error ??
Tienes que conocer la aplicación que estás usando, es decir, tienes que saber qué tamaño escribe y lee tu aplicación. Imagínate que te dicen que Oracle lee/escribe 32 KB -> pon TODO a 32 KB. No me hagas caso en cuanto al tamaño, me lo acabo de inventar, es sólo un ejemplo.
y principalmente, cual es el mejor metodo (o archivo de configuracion) para dejar este valor seteado como predefinido ??
ufff.. sorry por el largo del correo ...
salu2 y atento a cualquier comentarios.
En resumidas cuentas: pon más RAM. Es más rentable ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (2)
-
Rafa Grimán -
Victor Hugo dos Santos