El uso máximo de memoria de MySQL depende en gran medida del hardware, su configuración y la base de datos en sí.
Hardware
El hardware es la parte obvia. Cuanta más RAM, mejores y más rápidos discos ftw . Sin embargo, no crea esos boletines de noticias mensuales o semanales. MySQL no escala de forma lineal, ni siquiera en hardware de Oracle. Es un poco más complicado que eso.
La conclusión es: no existe una regla general para lo que se recomienda para su configuración de MySQL. Todo depende del uso actual o de las proyecciones.
Configuración y base de datos
MySQL ofrece innumerables variables y conmutadores para optimizar su comportamiento. Si tiene problemas, realmente necesita sentarse y leer el (f'ing) manual.
En cuanto a la base de datos, algunas limitaciones importantes:
- motor de la mesa (
InnoDB
, MyISAM
, ...)
- Talla
- índices
- uso
La mayoría de los consejos de MySQL sobre stackoverflow le informarán sobre 5-8 de las llamadas configuraciones importantes. En primer lugar, no todos importan, por ejemplo, asignar muchos recursos a InnoDB y no usar InnoDB no tiene mucho sentido porque esos recursos se desperdician.
O, mucha gente sugiere aumentar la max_connection
variable, bueno, poco saben que también implica que MySQL asignará más recursos para atenderlos max_connections
, si alguna vez es necesario. La solución más obvia podría ser cerrar la conexión de la base de datos en su DBAL o bajar el wait_timeout
para liberar esos hilos.
Si me entiendes, hay mucho, mucho para leer y aprender.
Motores
Los motores de tabla son una decisión bastante importante, muchas personas se olvidan de ellos desde el principio y luego de repente se encuentran peleando con una MyISAM
tabla de 30 GB que bloquea y bloquea toda su aplicación.
No quiero decir que MyISAM apesta , pero InnoDB
se puede modificar para responder casi o casi tan rápido como MyISAM
y ofrece el bloqueo de filas, UPDATE
mientras que MyISAM
bloquea toda la tabla cuando se escribe.
Si tiene la libertad de ejecutar MySQL en su propia infraestructura, es posible que también desee verificar el servidor percona porque, además de incluir muchas contribuciones de compañías como Facebook y Google (lo saben rápido), también incluye el propio servidor de Percona. en reemplazo de InnoDB
, llamado XtraDB
.
Consulte mi esencia para la configuración de percona-server (y -client) (en Ubuntu): http://gist.github.com/637669
Talla
El tamaño de la base de datos es muy, muy importante; lo crea o no, la mayoría de la gente en Intarwebs nunca ha manejado una configuración de MySQL grande y de escritura intensa, pero esas realmente existen. Algunas personas dirán algo como, "¡¡¡Usa PostgreSQL !!! 111", pero ignorémoslos por ahora.
La conclusión es: a juzgar por el tamaño, se debe tomar una decisión sobre el hardware. Realmente no puede hacer que una base de datos de 80 GB se ejecute rápidamente en 1 GB de RAM.
Índices
No lo es: cuanto más, mejor. Solo se deben establecer los índices necesarios y se debe verificar el uso EXPLAIN
. Agregue a eso que MySQL EXPLAIN
es realmente limitado, pero es un comienzo.
Configuraciones sugeridas
Sobre estos my-large.cnf
y my-medium.cnf
archivos, ni siquiera sé para quién fueron escritos. Enrolla el tuyo.
Primer tuning
Un gran comienzo es el manual de afinación . Es un script de bash (pista: necesitará Linux) que toma la salida de SHOW VARIABLES
y SHOW STATUS
y la envuelve en una recomendación útil. Si su servidor ha funcionado durante algún tiempo, la recomendación será mejor ya que habrá datos en los que basarlos.
Sin embargo, la cartilla de afinación no es una salsa mágica. Aún debe leer todas las variables que sugiere cambiar.
Leyendo
Realmente me gusta recomendar el mysqlperformanceblog . Es un gran recurso para todo tipo de consejos relacionados con MySQL. Y no es solo MySQL, también saben mucho sobre el hardware adecuado o recomiendan configuraciones para AWS, etc. Estos muchachos tienen años y años de experiencia.
Otro gran recurso es planet-mysql , por supuesto.