LinuxParty

Muchos servidores de bases de datos, especialmente como MySQL, usan discos duros para cada inserción de datos, por lo que para obtener un buen rendimiento, para estas bases de datos con gran cantidad de inserciones, se debe afinar lo que se escribe.

Ajustar las E/S es una tarea tediosa que requiere de muchas iteraciones hasta que finalmente alcanzamos la meta y vemos el resultado.

Creo que la sintonización de rendimiento de lectura es una tarea diferente de afinación para el rendimiento de escritura. Combinando los dos, a veces puede ser una de las tareas más difíciles que un SysAdmin pueda afrontar.

Ahora prefiero centrarme en el rendimiento de escritura en este artículo.

De arriba hacia abajo

Me gusta "calzarme ambos zapatos", tanto como Administrador de Sistemas y como Desarrollador, me gusta poner en práctica metodologías de desarrollo en la administración del sistemas. Esta es la "metodología top-down de desarrollo" - para analizar todos los pasos desde la parte superior -el comportamiento de la aplicación, el sistema operativo, sistema de archivos y luego, eventualmente -el hasta el final, el hardware-.

Al analizar el rendimiento y el diseño de E/S para la correcta ejecución, siempre imaginar IOPS como el agua corriendo por una tubería - desde la aplicación por el hardware.

Si cualquier parte de la tubería es más estrecha -no funcionaría correctamente-. Y nuestra tarea aquí es examinar la tubería y ampliarla cuando sea necesario.

Caracterizar su E/S

Cuando se habla del rendimiento de escritura, generalmente uno se encuentra con E/S muy secuenciales -tales como escribir bloques de vídeo, una tras otra. O "mejor" bastante al azar- como cuando un usuario realiza cambios en lugares de las DB que no se esperan. La sintonización es una de la últimas tareas bastante más difícil.

Afinar su aplicación

Los desarrolladores tienen siempre miedo de usar demasiada memoria. ¿Por qué? - No lo sé...

Hoy la memoria es barata, y con mucho, muchas veces me he encontrado a desarrolladores invertir incontables horas de desarrollo en optimizar para ahorrar la "enorme" cantidad de 4KB de memoria. La memoria es, con mucho, más barato que el trabajo.

¡Utilice toda la memoria que necesite! (es un comentario del que escribe, del que no todo el mundo querrá estar de acuerdo, yo no lo estoy) Yo animo a los desarrolladores a usar malloc() para utilizar grandes cantidades de memoria y evitar cualquier acceso al disco y el tiempo de la CPU se reduce.

Especialmente cuando se sintoniza para E/S, sólo tiene que utilizar más memoria. Si, por ejemplo, tiene que escribir bloques de datos en el disco, tal vez usted pueda amortiguarlo tanto como pueda -y dedicarse a la escritura en disco sólo cuando sea realmente necesario o cuando sea más conveniente hacerlo-.

Lo mismo sirve para la escritura aleatoria de E/S - amortiguar sus solicitudes y ofrecerle a su base de datos en trozos grandes - amos a la capa de abajo utilizando los métodos de E/S más eficientes. Por ejemplo, usted tiene muchas peticiones de escritura, en lugar de serializar el disco en el orden en que han llegado, caché de muchos de ellos, y deje en la cola el resto

Si su aplicación es en realidad una base de datos -numerosos parámetros se pueden configurarse para conseguir que la base de datos trabaje mucho mejor. Afine el sistema operativo

Un concepto muy importante a seguir siempre durante la optimización de un sistema operativo es "No te creas el Dios". Los sistemas operativos suelen saber lo que es bueno para ti. Eso es por lo general.bueno con los sistemas operativos modernos de hoy en día, tales como Linux, en el que puedes elegir entre unos cuantos planificadores IO.

Un planificador IO es el componente en el sistema operativo que ordena las peticiones de las colas y trata de optimizar el orden en el que se servirán.

Entonces, ¿cuál es el mejor? - No puedo responder a esta pregunta. Si usted no tiene un medidor de IO para el sistema (una prueba unitaria que imitan el carácter IO de su aplicación), por favor haga construir uno y experimente con las diferentes IO que Linux le ofrece. Su respuesta se encuentra justo detrás de la esquina.

Algunos de los parámetros del kernel (tuneables a través de sysctl) también están ahí para ayudarnos. Desde mi experiencia pasada, jugando con ellos rendirán muy poco de una mejora de rendimiento. El arma fundamental suele ser el planificador de IO que usted elija.

Seleccione el sistema de archivos correcto

Por suerte con Linux, tenemos una amplia selección de sistemas de archivos que pueden proporcionar enormes mejoras. ext* (ya sea 2, 3 o 4) son sin duda muy buenos, pero no están especialmente orientados a la ejecución sistemas de archivos.

Probablemente te estés preguntando ¿cual es el mejor fs journaling para nuestro sistema? - ya que puede perjudicar el rendimiento. Si por alguna razón tiene que hacer un reinicio duro de repente en un sistema de archivos 2TB, se llevará a cabo una comprobación del sistema, NO DEBE, pero puede ser interrumpido, cosa que no se recomienda -pese a que la comprobación parezca interminable-.

Entre los sistemas de archivos orientados a resultados que existen, te recomiendo experimentar con JFS , XFS , btrfs y por supuesto - el infame ReiserFS .

El aumento de rendimiento que podría obtenerse mediante la correcta elección del sistema de archivo. En mi lugar de trabajo anterior hemos tenido graves problemas de rendimiento IO para escritura. No fue sino hasta que migramos del por defecto ext3 a JFS obteniendo un aumento aproximado del 50% en el rendimiento, con sólo cambiar el sistema de archivos!

Hablando de sistemas de archivos, a veces tal vez no requiera un sistema de archivos. Un sistema de archivos eventualmente ralentiza las cosas. ¿Necesita fechas en sus archivos? ¿Permisos? ¿enlaces duros? ¿Una jerarquía?

Si se siente duro -siempre las solicitud a través un dispositivo de bloques puede producir enormes ganancias de rendimiento con el inconveniente del incremento de la gestión.

Echa un vistazo, por ejemplo, en Oracle RDBMS. Oracle RDBMS puede trabajar con dispositivos básicos - para acceder a un dispositivo de caracteres / bloques en lugar de archivos en un sistema de ficheros. Sin embargo es un dolor de cabeza para el DBA. Pero si exprime todo el rendimiento como su prioridad, el incremento de trabajo de gestión se desvanecerá por el aumento de rendimiento.

Configuración del disco

Quizás el componente más importante de su sistema, si el sistema está obligado a utilizarlo como IO.

Va a ser una gran diferencia para su sistema si se va a acceder a una única disco, pero por el contrario, las empresas pueden requerir un conjunto de 128 discos en una máquina de almacenamiento.

Antes de evaluar esta situación, primero debe preguntarse si quiere hacer frente a la configuración del disco por su cuenta, o utilizar una solución off-the-shelf (fuera de la plataforma).

Off-the-shelf (fuera de la plataforma) Como solución suele ser excelente en términos de rendimiento, fiabilidad y gestión. Sin embargo, va a ser muy caro. A veces incluso 10 veces más caro, para el mismo rendimiento.

Diseñar la configuración del disco adecuadamente para su aplicación sigue existiendo incluso si tienes una solución off-the-shelf super-cara para el almacenamiento de una de las grandes empresas.

Usted debe estar muy familiarizado con niveles RAID y lo que funcionaría mejor para su aplicación.

A continuación, debe preguntarse si el RAID que se encuentra en Linux es lo suficientemente amplio como para su sistema. Yo soy un orgulloso usuario de software RAID para Linux en mi servidor, pero para un sistema empresarial adecuado me gustaría tratar de evitarlo.

Hablando de niveles de RAID, RAID 4/5 nunca te dará un buen rendimiento, en comparación con RAID 0 o RAID 10.

Si el rendimiento de escritura no es prioritario -a continuación, por el mismo precio- Puede disponer de un conjunto de productos básicos baratos en RAID 10 pueden hacer mucho mejor que un juego de gama alta HDs 15K RPM en RAID 5. Soy consciente de que para RAID 10 necesitará duplicar el número de discos en comparación con RAID 5, pero como he dicho - Utiliza productos más baratos!

Si Google y Facebook están utilizando el enfoque de hardware común (y probablemente HDs básicos) -, entonces no pueden estar equivocados!

Otra palabra sobre los controladores RAID - vienen en todas las formas y colores. Para un funcionamiento correcto ir por los de marca, como Adaptec o 3ware. En términos generales -preferibles los que tienen controladores de código abierto o conductores de vanilla kernel - así nunca están obligados a comprobar qué versión del kernel utilizan.

Una última palabra

Prueba, prueba y prueba un poco más!

Siempre un perfil de su desempeño IO, utilizando herramientas como Monitis, Munin, Cacti y por último pero no menos importante – iostat.

Me gusta mucho iostat para esa tarea, le da excelentes parámetros tales como:

• ‘r/s’ and ‘w/s’ – Reads and Writes per second. Combina ambos.
• ‘%util’ – Utilization of the device

Y algunos otros contadores más que todo se puede medir en una resolución apretada.

Si controla constantemente su sistema le permitirá saber si el tedioso ajuste IO debe tomar algún tiempo o ninguno en absoluto. Si no hay problemas de rendimiento IO, a continuación, relájese, relájese, tome una cerveza - es mucho más divertido.

Siguiente:

Cómo mejorar el rendimiento de E/S del Servidor. (2 de 2)