Cómo Optimizar MySQL my.cnf en VPS Pequeña (1-2 GB RAM) sin Caídas

Mira el RSS actual de mysqld y cuánto representa de la RAM:

ps -o pid,rss,cmd -p $(pidof mysqld)
free -m

El valor de rss está en KB. Divide por 1024 para tener MB. En VPS de 1 GB con MySQL 8 por defecto, espera ver entre 380 y 500 MB — muy por encima de lo necesario para la carga real de un sitio pequeño.

Mira el uso real del InnoDB buffer pool — si el pool por defecto de 128 MB sobra o falta:

mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages%';"

Qué interpretar:

• pages_total = tamaño del pool en páginas de 16 KB
• pages_free cerca de cero = pool lleno, MySQL está reciclando páginas
• pages_data / pages_total = cuánto está en uso útil

Si pages_free está alto (>30% del total) y el servidor lleva días de uptime, puedes reducir el pool sin perjuicio. Si está cerca de cero e Innodb_buffer_pool_reads (no read_requests) crece rápido, el pool está infradimensionado.

Revisa performance_schema — solo él consume 70-100 MB:

mysql -u root -p -e "SELECT SUM(MEMORY_USED)/1024/1024 AS mb FROM sys.x\$memory_global_by_current_bytes;"

En VPS de 1 GB sin una herramienta de profiling externa leyéndolo, es el primer candidato a desactivar.

Crea el archivo de override:

sudo nano /etc/mysql/mysql.conf.d/99-hostini-tuning.cnf

En MariaDB: /etc/mysql/mariadb.conf.d/99-hostini-tuning.cnf. El número 99 garantiza que este archivo se lee al final — sobrescribe cualquier valor por defecto.

Pega esta configuración base para VPS de 1 GB de RAM:

[mysqld]
# InnoDB — corazón de MySQL
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 1
innodb_log_buffer_size = 8M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2

# Conexiones — una VPS pequeña no aguanta 150
max_connections = 50
thread_cache_size = 8
table_open_cache = 200
table_definition_cache = 400

# Performance schema — desactivado en 1 GB
performance_schema = OFF

# Binary log — desactivado si NO usas replicación
disable_log_bin
# Para MariaDB usa: skip-log-bin

# Logs lentos para diagnóstico
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

# Temporales — en RAM hasta este límite
tmp_table_size = 16M
max_heap_table_size = 16M

# Sort/join buffers — por conexión, cuidado con max_connections
sort_buffer_size = 256K
join_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 256K

Para VPS de 2 GB, ajusta solo estas líneas:

innodb_buffer_pool_size = 512M
max_connections = 100
performance_schema = ON
performance-schema-instrument='memory/%=COUNTED'

Guarda (Ctrl+O, Enter, Ctrl+X) y valida la sintaxis antes del reinicio:

sudo mysqld --validate-config

Si aparece cualquier error, el servicio no levantará después del reinicio. Corrige antes de continuar. Salida esperada: ninguna línea (el silencio es éxito).

Reinicia MySQL y revisa el estado:

sudo systemctl restart mysql
sudo systemctl status mysql --no-pager

En MariaDB: sudo systemctl restart mariadb. Si el estado muestra active (running), sigues adelante. Si falló, lee el motivo en sudo journalctl -u mysql -n 50 — casi siempre es un typo en el .cnf.

Confirma los valores que entraron en vigor:

mysql -u root -p -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size', 'max_connections', 'performance_schema', 'log_bin', 'tmp_table_size');"

Los valores deben coincidir con lo que pusiste en 99-hostini-tuning.cnf. Si alguno muestra el default antiguo, el archivo no se está leyendo — verifica la ruta y los permisos (debe ser 644 root:root).

Mide el consumo de RAM nuevamente:

ps -o pid,rss,cmd -p $(pidof mysqld)
free -m

Expectativa post-ajuste en VPS de 1 GB: mysqld en ~280-340 MB (caída de ~30%). En 2 GB con performance_schema activado: ~500-580 MB. Espera unos minutos con tráfico real antes de la medición final — el pool se calienta y se estabiliza.

Ejecuta SHOW STATUS después de 1-2 horas de uso real y confirma que el buffer pool no está ahogándose:

mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%';"

Señales de salud: pages_free > 5% del pages_total, reads creciendo despacio comparado con read_requests (ratio de hit > 99%). Si reads explota, sube el buffer pool en 64 MB y vuelve a probar.