Aunque puede ser que suene intimidante, el ajuste del rendimiento sólo trata de sacar el mayor rendimiento posible de un sistema. Para hacer esto es necesario entender cuales son las variables que están involucradas y como pueden afectar el buen funcionamiento del servidor Web.
Antes de entrar en los detalles, vale la pena reiterar un hecho importante: las técnicas que se van a mostrar no arreglarán búsquedas mal escritas o sin optimizar, un mal diseño de la base de datos, u otros problemas del diseño de la aplicación. Puede que sirvan para aliviar el esfuerzo de un servidor ocupado, pero simplemente se está posponiendo lo inevitable. La única solución a una aplicación mal escrita o un diseño pobre de la base de datos es irse al código y optimizarlo.
Uso de memoria
Del lado del servidor, el único y más importante factor en determinar cómo de bien rendirá MySQL, es la memoria. MySQL es capaz de ejecutar varios subprocesos a la vez. Esto significa que cada vez que se realiza una conexión, MySQL crea un subproceso. Cada subproceso consume memoria. El almacenamiento en caché de los resultados también consume memoria. Se puede pensar entonces, que entre más memoria tengamos en el servidor, será lo mejor. Sin embargo no es suficiente con tener mucha memoria disponible, es necesario indicarle a MySQL como queremos que use la memoria.
Las configuraciones por defecto de MySQL son bastante conservadoras para el hardware de hoy en día, sin embargo, si se tiene un servidor MySQL dedicado con varios cientos de mega bytes de RAM, se debe ser capaz de darle a MySQL una porción bastante grande de ella para trabajar. Por defecto, sólo usará una pequeña porción de lo que haya disponible; esto se debe a que no hay ninguna forma de saber si está corriendo en un servidor dedicado donde será usado de forma continua o si está corriendo en un esforzado portátil donde sólo se usa para almacenar una pequeña aplicación.
Los búfferes y cachés de MySQL son de dos tipos: globales, y por hilo.
Globales: tal y como sugiere el nombre, estas áreas de memoria son reservadas una vez y son compartidas a través de todos los hilos de MySQL. Dos de los más importantes son el búffer de claves y la caché de tablas. Debido a que son búfferes compartidos, el objetivo es que sean lo más grandes posibles.
Por hilo: estos búfferes reservan memoria individualmente a medida que necesitan realizar operaciones particulares, tales como ordenar o agrupar datos. A propósito, la mayoría de los búfferes MySQL se reservan en esta forma.
A continuación se examina primero que función tienen cada uno de los búfferes y como configurar e inspeccionar sus valores, posteriormente se mostrará como examinar contadores de rendimiento de MySQL y juzgar si los cambios que se realizan tienen implicaciones o no.
Búffer de claves
El búffer de claves es donde MySQL cachea los bloques de índices para tablas MyISAM. Cada vez que una búsqueda usa un índice, MySQL mirará antes de nada a ver si el índice relevante está o no en memoria. El parámetro key_buffer en el archivo my.cnf determina que tan grande puede ser este búffer. Una vez que el búffer este lleno, MySQL hará sitio para nuevos datos reemplazando datos antiguos que no hayan sido usados recientemente.
Como una recomendación general, en un servidor MySQL dedicado se debería reservar entre el 20 y el 50 por ciento de la memoria RAM para el búffer de claves de MySQL.
Caché de tablas
Las tablas MyISAM están compuestas de tres archivos en disco:
El archivo de datos nombredetabla.MYD, el archivo índice nombredetabla.MYI, y finalmente, el archivo de definición de la tabla llamado nombredetabla.FRM. Para poder usar una única tabla, MySQL necesita de hecho abrir los tres archivos. El archivo .FRM se cerrará después de que lea el esquema, pero los demás permanecerán abiertos, MySQL no los cerrará hasta que lo necesite. Esto evita una sobrecarga asociada con la apertura y cierre de los archivos si la tabla se usa frecuentemente. Los archivos normalmente no se suelen cerrar hasta que ocurre uno de los siguientes eventos:
1. La tabla se ha cerrado de forma explícita mediante FLUSH TABLES.
2. La tabla se ha desechado
3. El servidor esta siendo reiniciado
4. El número total de tablas abiertas ha alcanzado el valor del parámetro table_cache
El último evento es particularmente importante si se tienen muchas tablas que se usan a menudo entre todas las bases de datos. El valor por defecto de table_cache es de 64, así que si se tienen unos cientos de tablas que se usen de forma activa, MySQL va a desperdiciar mucho tiempo y esfuerzo abriendo y cerrando innecesariamente estos archivos.
Incrementar el tamaño de la caché de tablas ciertamente ayudará en esta situación, pero se debe tener cuidado de no hacer el valor demasiado grande, ya que todos los sistemas operativos tienen un límite en el número de los archivos abiertos por un mismo proceso. De hecho. algunos también tienen limitado el número total de archivos abiertos que puede tener un único usuario. Si MySQL intenta abrir demasiados archivos, el sistema operativo se negará a permitirlo y MySQL generará un mensaje de error en el archivo de registro de errores. Ante la duda, se tienen que comprobar las limitaciones del sistema operativo.
Búfferes de registro
Siempre que MySQL ha de escanear una tabla, el hilo que realiza el escaneo reservará un búffer de registro para cada tabla que ha de escanear. Esto sucede típicamente cuando MySQL decide que es más eficiente escanear la tabla que usar un índice para una búsqueda. También ocurre cuando simplemente no hay un índice que se pueda usar.
Al incrementar el valor de record_buffer en el archivo my.cnf, se permite que MySQL lea las tablas en trozos más grandes. Es probable que esto reduzca el número de búsquedas en el disco y haga que el escaneo sea significativamente más rápido en un servidor muy atareado.
Sin embargo, se tiene que ser muy cuidadoso con el búffer de registro si se tienen muchos clientes que realizan búsquedas completas sobre tablas. Debido a que el búffer de registro se reserva por cada hilo, se puede acabar en una situación donde clientes individuales hagan que se reserven búfferes de registro al mismo tiempo. Si el resto de la memoria está limitada es probable que se empiece a hacer uso de la memoria de intercambio y se verá dramáticamente reducido el rendimiento. En la versión 3.23.41 se introdujo un parámetro relacionado denominado record_rnd_buffer.
Al igual que record_buffer, se usa para escanear un gran número de filas. El record_rnd_buffer se usa para búsquedas que resultan en una ordenación intermedia del archivo además de algunas lecturas de registro no secuenciales. Afortunadamente, si no se fija el valor de record_rnd_buffer se establecerá por defecto el valor de record_buffer.
Búffer de ordenación
Tal y como implica su nombre, el búffer de ordenación se usa para responder a búsquedas que involucren elordenamiento de los datos -aquellas con una sentencia ORDER BY en ellas. Además, el búffer de ordenaciónse usa para las búsquedas que involucren agrupar datos -aquellas con una sentencia GROUP BY. Al igual que los demás búfferes que se han visto, el búffer de ordenación es relativamente pequeño por defecto. Al ajustar la entrada de sort_buffer en el archivo my.cnf: set-variable= sort_buffer= 8M puede reducir dramáticamente la cantidad de tiempo que se usa para ordenar grandes grupos de resultados.
¿Necesita asesoría adicional? Contacte aquí un especialista en servidores dedicados de INTERNET YA
Fuente: http://programacion.net