mysql.server es un fichero que puede hallarse en el directorio support-files bajo el directorio de instalación de MySQL o en un árbol de código fuente MySQL. Se instala como /etc/init.d/mysql para conseguir que MySQL inicie y se detenga automáticamente. Consulte Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”.

Si MySQL no puede abrir suficiente ficheros o conexiones, es posible que Linux no se haya configurado para gestionar suficientes ficheros.

En Linux 2.2 y posteriores, se puede verificar la cantidad de manejadores de ficheros asignados de esta forma:

shell> cat /proc/sys/fs/file-max
shell> cat /proc/sys/fs/dquot-max
shell> cat /proc/sys/fs/super-max

Si se poseen más de 16 MB de ram, se debería agregar a los scripts de inicio algo como lo siguiente (por ejemplo, mysql.server en SuSE Linux):

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

Los comandos echo también pueden ejecutarse como root,desde la línea de comandos, pero los valores establecidos se perderán la próxima vez que se reinicie el ordenador.

De manera alternativa, estos parámetros pueden configurarse al inicio usando la herramienta sysctl, la cual es usada por muchas distribuciones de Linux (incluyendo SuSE Linux 8.0 y posteriores). Colocar los siguientes valores en un fichero llamado /etc/sysctl.conf:

# Incrementa algunos valores para MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

También se debería agregar lo siguiente a /etc/my.cnf:

[mysqld_safe]
open-files-limit=8192

Esto elevará a 8192 el límite del servidor para el número total de conexiones y ficheros abiertos.

La constante STACK_SIZE de Linuxthreads controla el espacio de la pila de subprocesos en el espacio de direcciones. Necesita ser lo suficientemente grande como para brindar bastante lugar para cada pila individual de subprocesos, pero lo suficientemente pequeña para mantener la pila de algunos subprocesos ejecutándose fuera de los datos globales de mysqld. Desafortunadamente, la experiencia demostró que la implementación Linux de mmap() desasigna una región previamente asignada (mapped), si se solicita asignar (map) una dirección actualmente en uso, poniendo a cero los datos de toda la página en lugar de retornar un error. De modo que la seguridad de mysqld o cualquier otra aplicación hebrada depende de la "caballerosidad" del código que crea los subprocesos. El usuario debe tomar medidas para cerciorarse que el número de procesos en ejecución en cualquier momento dado es lo suficientemente bajo como para que las pilas de procesos se mantengan lejos del montón (heap) global. Con mysqld esto debería hacerse, estableciendo un valor razonable para la variable max_connections.

Si el usuario compila por sí mismo a MySQL, puede aplicar un parche a LinuxThreads para un mejor uso de la pila. Consulte Sección 2.12.1.3, “Notas sobre la distribución de código fuente para Linux”. Si no se desea aplicar un parche a LinuxThreads, se deberá establecer max_connections a un valor no mayor de 500, o incluso menos si se tienen un gran buffer de claves, grandes tablas de montón (heap tables) o alguna otra cosa que obligue a mysqld a reservar gran cantidad de memoria,o si se está ejecutando un kernel 2.2 con un parche de 2Gb. Si se está empleando la versión binaria en RPM, se puede establecer en forma segura max_connections a un valor de 1500, asumiendo que no hay grandes buffers de claves, o grandes tablas de montón (heap tables) con muchos datos. Mientras más se reduzca STACK_SIZE en LinuxThreads, más subprocesos podrán crearse sin problemas. Se recomiendan valores ente 128KB y 256KB.

Si se utilizan muchas conexiones simultáneas, puede sufrirse una “característica” del kernel 2.2, que intenta prevenir ataques de bomba de bifurcación (fork bomb) penalizando los procesos que bifurcan o clonan un proceso hijo. Esto provoca que MySQL no escale bien a medida que se incrementa el número de clientes simultáneos. En sistemas con una única CPU, esto se manifiesta a través de lentitud en la creación de procesos; puede llevar largo tiempo conectarse a MySQL (hasta un minuto) y puede llevar lo mismo para detenerlo. En sistemas con múltiples CPUs, se observó una caída gradual en la velocidad de las consultas a medida que aumenta el número de clientes. En la búsqueda de una solución, se recibió un parche para el kernel de parte de un usuario que lo necesitó para su sitio web. Este parche puede descargarse de http://www.mysql.com/Downloads/Patches/linux-fork.patch. MySQL AB probó ampliamente este parche tanto en sistemas en desarrollo como en producción. Funcionó incrementando notablemente el rendimiento de MySQL sin causas problemas, por lo tanto se lo recomienda a los usuario que aún ejecuten servidores de altas prestaciones en kernels 2.2.

Este problema se resolvió en el kernel 2.4, de modo que si no se está satisfecho con el rendimiento actual del sistema, en lugar de aplicar un parche al kernel 2.2, podría ser más sencillo actualizarlo a 2.4. En sistemas SMP (multiprocesamiento simétrico), la actualización también favorecerá el desempeño de SMP además de corregir el error.

Al probar MySQL con un kernel 2.4 en un ordenador de dos procesadores, se halló que MySQL escala mucho mejor. Hasta 1,000 clientes prácticamente no se producen retrasos en el rendimiento de las consultas, y el factor de escalado de MySQL (calculado como el máximo rendimiento respecto al rendimiento de un cliente) fue 180%. Se observaron resultados similares en un ordenador de cuatro procesadores: hasta 1,000 clientes prácticamente no se producen retrasos en el rendimiento de las consultas, y el factor de escalado de MySQL fue de 300%. Al basarse en estos resultados, definitivamente se recomienda que los servidores de alta prestación ejecutando un kernel 2.2 se actualicen a 2.4.

A fin de obtener el máximo rendimiento, es esencial ejecutar el proceso mysqld con la prioridad más alta posible en kernel 2.4. Esto puede lograrse agregando un comando renice -20 $$ a mysqld_safe. En las pruebas sobre un ordenador de 4 procesadores, el aumento de la prioridad produjo un 60% de incremento en el rendimiento con 400 clientes.

En la actualidad, MySQL AB se halla recolectando información sobre el desempeño de MySQL sobre un kernel 2.4 en sistemas de cuatro y ocho procesadores. Si se tiene acceso a tales sistemas, y se han hecho algunas pruebas de rendimiento, por favor envíese un mensaje de correo electrónico a <benchmarks@mysql.com> con los resultados. Estos serán revisados para su inclusión en este manual.

Si con ps se advierte un proceso mysqld muerto, generalmente significa un error en MySQL o una tabla corrupta. Consulte Sección A.4.2, “Qué hacer si MySQL sigue fallando (crashing)”.

Para que se genere un volcado de núcleo en Linux cuando mysqld finalice imprevistamente con una señal SIGSEGV, debe iniciarse mysqld con la opción --core-file. También es probable que se necesite aumentar el espacio para el fichero de volcado de núcleo mediante el agregado de ulimit -c 1000000 a mysqld_safe o iniciando mysqld_safe con --core-file-size=1000000. Consulte Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.