Optimización del servidor MySQL en entorno Linux

Los usuarios ordinarios de MySQL aprovechan las operaciones de creación e indexación de tablas, así como las optimizaciones que se pueden realizar al escribir las consultas. Sin embargo, hay algunas optimizaciones que solo pueden realizar los administradores de MySQL y los administradores de sistemas que tienen control sobre el servidor MySQL o la máquina que ejecuta MySQL. Algunos parámetros del servidor son directamente aplicables al procesamiento de consultas y se pueden activar. Y algunos problemas de configuración de hardware afectan directamente la velocidad de procesamiento de consultas, deben ajustarse.

Problemas con el disco
Como se mencionó anteriormente, la búsqueda del disco es un gran cuello de botella en el rendimiento. Este problema se hace cada vez más evidente a medida que los datos comienzan a crecer y la memoria caché se vuelve imposible. Para bases de datos grandes, donde tiene más o menos acceso aleatorio a los datos, puede confiar en que tendrá al menos un disco para leer y varios discos para escribir. Para minimizar este problema, use un disco con poco tiempo de búsqueda.

Para aumentar el número de ejes de disco disponibles (y así reducir la sobrecarga de búsqueda), es posible simbolizar archivos en diferentes discos o dividir discos.

1. Usando enlaces simbólicos
Esto significa que usted vincula los símbolos de archivo de datos /índices desde el directorio de datos normal a otros discos (que también se pueden dividir). Esto hace que los tiempos de búsqueda y lectura sean mejores (si el disco no se usa para otras cosas)

2, dividir
dividir significa que tiene muchos discos y colocar el primero en el primero En el disco, el segundo bloque se coloca en el segundo disco, y el bloque nth está en el disco (nmodnumber_of_disks), y así sucesivamente. Esto significa que si su tamaño de datos normal se divide (o se alinea perfectamente), obtendrá un mejor rendimiento. Tenga en cuenta que la división es muy dependiente del sistema operativo y el tamaño de la división. Así que prueba tu aplicación con diferentes tamaños de división. Ver 10.8 utilizando su propio punto de referencia. Tenga en cuenta que la diferencia de velocidad para la división depende en gran medida de los parámetros, según cómo se dividan los parámetros y la cantidad de discos, puede obtener una diferencia de orden de magnitud. Tenga en cuenta que debe elegir optimizar para el acceso aleatorio o secuencial.

Para mayor confiabilidad, es posible que desee usar RAID0 + 1 raid (split + mirror), pero en este caso necesitará 2 * N unidades para almacenar los datos de N unidades. Si tienes dinero, esta puede ser la mejor opción. Sin embargo, es posible que también deba invertir en alguna inversión en software de administración de volumen para manejarlo de manera eficiente.

Una buena opción es tener datos un poco más importantes (se pueden regenerar) en un disco RAID0, y datos realmente importantes (como información de host y archivos de registro) en un disco RAID0 + 1 o RAIDN. Si tiene muchas escrituras debido a la actualización del bit de paridad, RAIDN puede ser un problema.

También puede configurar parámetros para el sistema de archivos utilizado por la base de datos. Un cambio fácil es montar el sistema de archivos con la opción noatime. Este es el último tiempo de acceso que omite la actualización en el inodo, y esto evitará algunas búsquedas de disco.

Problemas de hardware
El hardware se puede utilizar para mejorar el rendimiento del servidor de manera más eficiente:

1. Instale más memoria en la máquina. Esto aumenta el tamaño de la memoria caché y las memorias intermedias del servidor, lo que permite que el servidor utilice la información almacenada en la memoria con mayor frecuencia, lo que reduce la necesidad de obtener información del disco.

2. Si hay suficiente RAM para completar todos los intercambios en el sistema de archivos de memoria, entonces el sistema debe reconfigurarse para eliminar todas las configuraciones de intercambio de discos. De lo contrario, algunos sistemas todavía tienen que intercambiarse con el disco incluso si hay suficiente RAM para satisfacer el intercambio.

3, aumenta el disco más rápido para reducir el tiempo de espera de E /S. El tiempo de búsqueda es el factor principal que determina el rendimiento aquí. Mover la cabeza literalmente es muy lento, y una vez que se coloca la cabeza, leer el bloque desde la pista es más rápido.

4. Antes de volver a colocar los datos en diferentes dispositivos, debe asegurarse de comprender las características de carga del sistema. Si tiene alguna actividad primaria específica en un dispositivo físico en particular, colocar la base de datos allí podría empeorar el rendimiento. Por ejemplo, no mueva la base de datos a un dispositivo de servidor web que maneje una gran cantidad de tráfico web.

5, al configurar MySQL, debe configurarlo para usar bibliotecas estáticas en lugar de bibliotecas compartidas. El uso de un sistema binario dinámico binario compartido ahorra espacio en disco, pero un sistema binario estático es más rápido (sin embargo, si desea cargar una función definida por el usuario, no puede usar un sistema binario estático porque el mecanismo UDF se basa en conexiones dinámicas).

Selección de parámetros del servidor
El servidor tiene varios parámetros (o variables) que pueden modificarse para afectar su funcionamiento. El valor actual de la variable del sistema se puede verificar ejecutando el comando MySQLadminvaribles. Varios de los parámetros están relacionados principalmente con la consulta. Es necesario mencionarlo aquí:

delayed_queue_size
Este parámetro se ejecuta en otras instrucciones INSERTDELAYED. Antes de que los bloques del cliente, determine el número de filas en la cola de la instrucción INSERTDELAYED. El aumento del valor de este parámetro permite que el servidor reciba más filas de dicha solicitud, por lo que el cliente puede continuar ejecutándose sin bloquear.

key_buffer_size
Este parámetro es el tamaño del búfer utilizado para almacenar el bloque de índice. Si hay más memoria, aumentar este valor puede ahorrar tiempo en la creación y modificación del índice. Los valores más grandes permiten que MySQL almacene más bloques de índice en la memoria, lo que aumenta la probabilidad de encontrar valores clave en la memoria sin leer bloques de disco.

En MySQL 3.23 y versiones posteriores, si aumenta el tamaño del búfer de claves, es posible que desee iniciar el servidor con la opción — — init-file. Esto le permite especificar un archivo de sentencias de SQL que se ejecutará cuando se inicie el servidor. Si tiene tablas de solo lectura que desea almacenar en la memoria, puede copiarlas en una tabla HEAP que parece muy rápida para el índice.