Você está na página 1de 9

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.

Você também pode gostar