MONITOREO DE ESPACIO EN DISCO DURO EN MySQL La optimizacin en MySQL pasa por tres componentes, a saber:

Optimizacin del servidor MySQL Optimizacin de la base de datos Optimizacin de las consultas

Optimizacin de la configuracin del servidor MySQL

La optimizacin del servidor puede incluir una multitud de enfoques y mtodos, lo que intentaremos presentar en lo que sigue es una introduccin a los enfoques de base, a saber:

Compilacin del servidor Afinamiento de los parmetros del servidor Afinamiento de otros parmetros

Para hacer una buena optimizacin, es necesario proceder con una metodologa emprica a saber hacer las modificaciones una por una y probar cada vez la reaccin del sistema para ver el resultado. Una medida del rendimiento antes y despus de haber efectuado la optimizacin permite ver si el sistema ha sido optimizado o no.

Compilacin del servidor

Es recomendado utilizar la versin del cdigo fuente del servidor MySQL y compilarla teniendo en cuenta los diferentes parmetros del sistema a saber el conjunto de caracteres a utilizar, el microprocesador sobre el que va a

correr y utilizar un compilador adaptado (por ejemplo: pgcc para los microprocesadores Pentium).

Afinamiento de los parmetros del servidor

Es posible optimizar el funcionamiento de MySQL cambiando los valores de los parmetros del servidor. Como recordars para mostrar los parmetros se debe utilizar el comando:

show variables; Para ver el efecto de los parmetros sobre el servidor es necesario ejecutar el comando:

show status; Existen numerosas herramientas de monitoreo que permiten ver los efectos de los cambios efectuados en los parmetros en el servidor MySQL, por ejemplo Mytop equivalente al comando top de Linux. El fichero my.cnf contiene todos los parmetros que deben ser optimizados. Inicialmente, es posible comenzar con los parmetros que gestionan la memoria. Se debe tener en cuenta que cuanta ms memoria disponga el servidor, ms rpido ser, sin embargo, hay que asegurarse de que la memoria est disponible. MySQL contiene un conjunto de buffers y cachs internos, en el que es posible configurar el espacio asignado a cada uno a partir de las variables del fichero my.cnf. Las dos variables ms importantes son key_buffer_size y table_cache ya que son compartidas por todos los threads que corren sobre el

servidor e influyen de manera considerable en el rendimiento. Un ejemplo de variables:

key_buffer_size: memoria utilizada para las copias de seguridad de los ndices MyISAM.

table_cache: numero de tablas que pueden ser abiertas simultneamente.

read_buffer_size: memoria utilizada para la copia de respaldo de los datos salidos de los full scan de las tablas.

sort_buffer: memoria utilizada para la copia de respaldo de los datos de las tablas que sern ordenadas con un ORDER BY

Afinamiento de otros parmetros

El servidor MySQL obtiene un funcionamiento ptimo en SOLARIS, sin embargo, es posible optimizarlo en otros SO para aproximarse a su rendimiento ideal. El uso de RAID-RAID 0 es recomendado para la optimizacin de las operaciones de lectura escritura. As como el uso de discos SCSI en vez de IDE. El uso de redes rpidas optimiza el tiempo de respuesta y optimiza la comunicacin entre cliente/servidor y amo/esclavo para la replicacin.

Optimizacin de la base de datos

Generalmente para la optimizacin de las bases de datos lo recomendado es hacer uso de las buenas prcticas y las metodologas de concepcin de base de datos que permitan implementar esquemas de bases de datos eficaces y normalizados. Sin embargo para ello es necesario:

Saber lo que est lento en las bases de datos

Elegir la metodologa correcta Utilizar ndices Utilizar OPTIMIZE TABLE

Qu es lo que ralentiza las bases de datos

Generalmente, un cierto nmero de factores son la causa de la lentitud de las bases de datos. Entre los ms frecuentes:

Insuficiente numero de ndices: La primera causa de la lentitud es el uso de tablas sin ndices o sin ndices en las columnas relativas a las bsquedas. Esto no quiere decir que todas las tablas deben tener ndices, sino que hay que estudiar bien las necesidades de indexacin.

Uso excesivo de ndices: para optimizar las consultas y bsquedas, los ndices son la solucin, sin embargo, el aumento de ndices afecta el rendimiento en lo relativo a las actualizaciones. En la actualizacin de una tabla, las operaciones de insercin, modificacin y eliminacin repercuten generalmente sobre los ndices.

Uso de privilegios en las tablas y columnas de las tablas: en cada acceso MySQL debe verificar los derechos sobre las tablas y las columnas de las tablas lo que ralentiza considerablemente el rendimiento.

No hacer la eleccin correcta en la concepcin de la base de datos.

Modelizacin de la base de datos

El uso de las buenas prcticas de modelizacin y concepcin de bases de datos as como la eleccin de la metodologa apropiada permite implementar bases de datos eficaces.

Es necesario tener en cuenta un cierto nmero de consideraciones:

Apropiada eleccin de los tipos de campos: siempre procurar elegir las variables ms adaptadas a las necesidades (por ejemplo para almacenar un numero con no ms de 10 dgitos, lo mejor es utilizar un tipo TINYINT). El uso de campos de menor tamao permite cargar en memoria ms columnas.

Uso de campos de longitud fija: el uso de longitudes predeterminadas permite optimizar el acceso a las columnas ya que sus posiciones son predefinidas. Esto implica disminuir el uso de VARCHAR, TEXT y BLOB (para TEXT y BLOB, se recomienda romper la normalizacin del esquema de la base de datos y hacer una copia de respaldo de estos campos en otras tablas).

Aumentar el uso de las restricciones NON NULL cuando sea posible para optimizar el espacio de almacenamiento.

Elegir el tipo correcto para las tablas: MySQL permite tener en un mismo esquema tablas de diferente tipo.

Hacer una buena indexacin de las tablas.

Utilizar los ndices

Un ndice es una tabla de bsqueda que nos permite encontrar rpidamente lneas en una tabla. El ndice permite determinar la posicin del registro buscado en una tabla. Si una tabla no tiene ndice, todos los registros serian recorridos durante la bsqueda. Los ndices en MySQL son almacenados como de b-trees (rboles binarios), que representa una estructura de datos fcil y rpida de recorrer. El ndice puede incluir una o varias columnas, el ndice ser

llamado durante una bsqueda hecha sobre las columnas indexadas. En MySQL, la indexacin es automtica en las tablas con campos teniendo las restricciones PRIMARY, KEY, UNIQUE. La idea principal a tener en cuenta es que si una bsqueda es frecuente y sta incluye una o varias columnas, ser necesario crear el ndice correspondiente para optimizar el tiempo de respuesta va el comando CREATE INDEX

Uso del comando OPTIMIZE TABLE

Equivalente a la defragmentacin del disco duro, el comando OPTIMIZE TABLE permite defragmentar las tablas.

Optimizacin de las consultas

MySQL permite analizar las consultas y conocer el tiempo y plan de ejecucin. Esta informacin permite comprender lo que hace que las consultas sean lentas y optimizar la ejecucin de stas.

Detectar las consultas lentas

Para detectar las consultas lentas es posible:

1. observar las consultas lentas durante su ejecucin y los tiempos de respuesta anormales.

2. hacer un benchmark: testear las aplicaciones para ver qu componentes son los ms lentos.

3. verificar el Slow query log: es posible activar esta opcin en MySQL configurando la variable --log-slow-queries

Una vez detectadas las consultas lentas, la ejecucin del

comando EXPLAIN permite comprender la ejecucin y por lo tanto conocer o intervenir para optimizar.

MONITOREO DE LOG EN MYSQL

Para monitorear el rendimiento de MySQL, que mejor que arrancar por las consultas, para hacer esto disponemos de una serie de alternativas:

Activar el Slow Query Log: loguea todas las consultas que se excedan de un tiempo dado (log_query_time) o bien, que no utilicen ncides (log-queries-not-using-indexes). Para activarlo, debemos editar el archivo my.cnf y agregar en la seccin [mysqld]:

[CODE] long_query_time = 1 log-slow-queries = /var/log/mysql/mysql-slow.log log-queries-not-using-indexes [/CODE]

Describir una consulta: utilizar el comando DESCRIBE (o DESC es su forma abreviada). Por ejemplo: DESC SELECT FROM WHERE ORDER BY , este nos devolver si est utilizando ndices y cuales son.

Analizar mediante EXPLAIN, como ejecuta las consultas MySQL y determinar si se utilizan ndices, el nmero de filas exploradas e informacin adicional. Ver, Optimizacin de consultas con EXPLAIN.

MONITOREO DE MEMORIA COMPARTIDA

En MySQL 5.0, MySQL Cluster tata de usar transporte a travs de memoria compartida y configurarla automticamente cuando sea posible, principalmente donde ms de un nodo se ejecuta concurrentemente en el mismo equipo del cluser. (En versiones anteriores de MySQL Cluster, los segmentos de memoria compartida se soportan slo cuando el binario -max se compila usando --with-ndb-shm.) Cuando se define la memoria compartida explcitamente como mtodo de conexin, es necesario definir como mnimo NodeId1, NodeId2 y ShmKey. Todos los otros parmetros tienen valores por defecto que funciona bien en la mayora de casos.

Nota: El soporte SHM debe considerarse experimental.

[SHM]NodeId1, [SHM]NodeId2

Para identificar una conexin entre dos nodos es necesario proporcionar identificadores para cada uno de ellos como NodeId1 y NodeId2.

[SHM]ShmKey

Cuando se inicializan segmentos de memoria compartido, un ID de nodo se identifica para identificar unvocamente el segmento de memoria compartida para usar para la comunicacin. Se expresa como un entero que no tiene valor por defecto.

[SHM]ShmSize

Cada conexin SHM tiene un segmento de memoria compartida dnde los nodos entre mensajes se guardan por parte del que enva y donde lo lee el receptor. El

tamao de este segmento lo define ShmSize. El valor por defecto es 1MB.

[SHM]SendSignalId

Para obtener la traza de la ruta de un mensaje distribudo, es necesario proporcionar un identificador nico a cada mensaje. Poner este parmetro a Y hace que los IDs de mensajes se transporten sobre la red tambin. Esta caracterstica est desactivada por defecto.

[SHM]Checksum

Este parmetro es Y/N , y est desactivado por defecto. Cuando se activa, se calculan los checksums para todos los mensajes y se guardan en el buffer de envo.

Esta caracterstica evita que los mensajes se corrompan mientras esperan en el buffer de envo. Tambin sirve como chequeo para que no se corrompan los datos durante el transporte.