MySQL tiene problemas. free -h: intercambio de 512 MB usado, RAM “completa”. El equipo duplica el intercambio de 2 a 8 GB; la lentitud empeora. El verdadero problema: la consulta sin índice + grupo de búfer demasiado pequeño, no la ausencia de intercambio.
El intercambio no siempre es malo ni siempre bueno: contexto y métricas.
Leer gratis y vmstat
disponible más confiable que la línea de caché gratuita. vmstat 1: si bi/s intercambia entrada/salida constante bajo carga → RAM insuficiente.
Distinga el swap utilizado del swap actividad.
Roles de intercambio
Net: evita el asesino OOM en un pico corto.
Síntoma: conjunto de trabajo > RAM sostenida.
Mala idea: compensar indefinidamente el VPS barato con RAM de tamaño insuficiente.
Por carga de trabajo
| Carga de trabajo | Recomendación |
|---|---|
| PostgreSQL/MySQL | RAM primero, intercambia actividad mínima |
| Web PHP sin estado | intercambiar OK pequeño, ver OOM |
| Redis | intercambio, deshabilitación o intercambio casi inútil 1 |
| Noche de lotes | intercambio puede suavizar los picos |
Alinearse con el host: algunos VPS sin intercambio por diseño.
Sintonización
swappiness=10 /etc/sysctl.d. El intercambio de SSD es mejor que el de HDD, pero la latencia sigue siendo ms frente a µs de RAM.
zram en VPS de 1 a 2 GB si el kernel es reciente.
Decisión de actualización
Si swapin/swapout > 0 sostenido + latencia SLO interrumpida → actualice la RAM o el servicio de fragmentos. Cambie el intercambio solo = aspirina.
Matriz de decisión
| Señal | Acción |
|---|---|
| intercambio usado, intercambio/salida ~0 | monitorear |
| intercambio/salida sostenida + latencia | actualizar RAM |
| OOM mata | Límite de RAM + aplicación |
| Intercambio de Redis | arreglar inmediatamente |
| Intercambio nocturno por lotes OK | documento esperado |
Revisión después del cambio de tipo de instancia de nube: cambios en la relación RAM/intercambio.
Alerta
Alerta si el swap se utiliza >50 % y la tasa de swapin >0 se mantiene durante 5 minutos; no se alerta sobre el swap utilizado solo.
Panel de control: RAM disponible + actividad de intercambio en el mismo panel.
Plan de capacidad: activador de actualización de RAM definido (por ejemplo, intercambio >10/s 15 min).
Política de intercambio de nodos de Kubernetes: ciertos clústeres lo prohíben: planifique las solicitudes/límites de memoria antes de implementar el montón de Java codicioso.
Contenedores JVM sin límite de memoria + host de intercambio = latencia de GC impredecible.
Contenedores e intercambio
Docker sin límite de memoria: el contenedor puede activar el intercambio de host; defina mem_limit.
Kubernetes: intercambia de forma predeterminada muchos clústeres: política de intercambio de pod vs host de OOMKill explícita.
Monitoreo: alerta si la espera de IO de intercambio se correlaciona con la latencia de API, no solo con la métrica utilizada de intercambio.
Resumen operativo
El swap utilizado no está alerta; El intercambio activo bajo carga es. Producción de bases de datos: primero la RAM. VPS pequeño: un pequeño cambio evita un OOM brutal. Mida vmstat, no solo gratis.
Kubernetes y Redis: evite el intercambio de host para cargas de trabajo sensibles a la latencia.
Panel de lectura
Panel 1: Tendencia de RAM disponible 7 días. Panel 2: tasa de entrada/salida de swap. Panel 3: superposición de latencia de la aplicación p95. Intercambio de correlación + latencia = ticket de actualización de RAM cifrada.
Documentación de Runbook: cuándo ignorar el intercambio estático utilizado y cuándo buscar de guardia.
Monitoreo operativo
Intercambio de referencia de documentos posterior al incidente: comparación futura. Latencia correlacionada de intercambio de alertas. Revisión del registro asesino de OOM después del pico de intercambio: qué proceso es la víctima. Documente las brechas entre la promesa del proveedor de hosting y la medición de campo en la revisión trimestral.
Continuación trimestral
Intercambio de referencia de documentos posterior al incidente: comparación futura. Latencia correlacionada de intercambio de alertas. Revisión del registro asesino de OOM después del pico de intercambio: qué proceso es la víctima. Documente las brechas entre la promesa del proveedor de hosting y la medición de campo en la revisión trimestral.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Intercambio de matriz
| Señal | Acción |
|---|---|
| swap usado, swapin ~0 | monitorear |
| intercambio + latencia | Actualización de RAM |
| Intercambio de Redis | arreglar ahora |
PaaS: OOM solo visible: tamaño de RAM.
Decide y avanza sin puntos ciegos
- Correlacionar el intercambio de entrada/salida y la latencia de la aplicación: intercambio utilizado sin actividad = monitor; swapin admitido = ticket de RAM.
- Panel de control de tres paneles: RAM disponible, E/S intercambiables, superposición de latencia p95.
- Redis y las bases de datos nunca se intercambian: solución inmediata si se detecta.
- Lote nocturno aceptable de documentos: intercambio predecible frente a pérdida de memoria.
- Revisión después del cambio de instancia de nube: la relación RAM/intercambio cambia según el tipo.
Actualización de RAM: números a mano mediante los archivos comparador y directorio.
Preguntas frecuentes
Intercambio 100% usado = ¿emergencia?
Emergencia si la latencia explota y la mayoría de la RAM activa está en intercambio (si la columna disponible es baja). Puede ser benigno si las páginas frías están inactivas.
¿intercambio 60 o 10?
10–20 en servidores de caché/base de datos prod para evitar un intercambio agresivo. 60 predeterminado orientado al escritorio.
¿Deberíamos desactivar el intercambio?
Rara vez en VPS pequeños: un pequeño cambio evita una muerte brutal de OOM. Base de datos crítica: bastante más RAM que swap cero.
¿zram es útil?
En VPS pequeños con poca RAM, zram comprime la RAM, mejor que el intercambio lento de disco, no sustituye a la RAM real para un conjunto de trabajo grande.
Verifique vmstat antes de comprar el intercambio en la nube: a veces faltan 4 GB de RAM, no 4 GB de intercambio.