Ir al contenido 
A Servidor de paginación de memoria puede perder significativamente tiempo de respuesta y rendimiento bajo carga si demasiadas páginas se mueven de RAM a swap. En este artículo, le mostraré las causas, los valores medidos y los ajustes específicos que puedo realizar para ralentizar la paginación y aumentar notablemente el rendimiento del servidor.
Puntos centrales
Para ofrecer una orientación clara, resumiré brevemente los mensajes clave y le mostraré dónde se encuentran los cuellos de botella típicos y cómo resolverlos. Las altas tasas de paginación cuestan mucho Actuación, porque los accesos al soporte de datos son mucho más lentos que la RAM. Valores medidos como MBytes disponibles, Bytes accedidos y Páginas/Segundo me proporcionan Señales para el thrashing inminente. La virtualización agrava los efectos del swapping a través del ballooning y el swap del hipervisor cuando los hosts están sobrecargados. Reduzco los fallos de página con actualizaciones de RAM, THP/páginas enormes, ajuste NUMA y patrones de asignación limpios. La supervisión periódica mantiene Riesgos y permite calcular los picos de carga.
- Swap vs RAMNanosegundos en RAM frente a micro/milisegundos en soportes de datos
- Thrashing: Más transferencias de páginas que trabajo útil, se disparan las latencias
- Fragmentación: Las asignaciones grandes fallan a pesar de la memoria „libre
- IndicadoresMBytes disponibles, Bytes accedidos, Páginas/Seg.
- SintonizaciónTHP/Huge Pages, vm.min_free_kbytes, NUMA, RAM
Cómo funciona la paginación en los servidores
Separo la memoria virtual y física en páginas fijas, normalmente de 4 KB, que es la MMU mediante tablas de páginas. Si la RAM escasea, el sistema operativo mueve las páginas inactivas a las áreas de intercambio o swap. Cada fallo de página obliga al núcleo a obtener datos del soporte de datos y cuesta una valiosa memoria RAM. Tiempo. Las páginas grandes, como las Transparent Huge Pages (THP), reducen el esfuerzo administrativo y minimizan las pérdidas de TLB. Para los principiantes, merece la pena echar un vistazo a memoria virtual, para comprender mejor las relaciones entre procesos, marcos de página y swap.
Swap frente a RAM: latencias y thrashing
La RAM responde en nanosegundos, mientras que las SSD/HDD lo hacen en micro o milisegundos y, por tanto, son órdenes de magnitud más rápidas. más lento son. Si la carga excede la memoria de trabajo física, la tasa de paginación aumenta y la CPU espera la E/S. Este efecto puede conducir fácilmente al thrashing, en el que se dedica más tiempo al swapping que al trabajo productivo. Trabajo se pierde. Especialmente con la utilización del 80-90%, la interactividad y las sesiones remotas se deterioran. Compruebo el Utilización de swaps y trazar límites antes de que el sistema vuelque.
Indicadores y valores umbral
Los valores medidos limpios toman decisiones RAM y puesta a punto. En Windows presto atención a los MBytes disponibles, cessed Bytes, Pages/Second y Pool paged/nonpaged bytes. En Linux, compruebo vmstat, free, sar, ps meminfo y dmesg en busca de eventos de falta de memoria. El aumento de los problemas de páginas con la disminución de MBytes libres indica cuellos de botella inminentes. Planifico los umbrales críticos de forma conservadora para poder evitar picos de carga sin Robo interceptar.
| Indicador de resultados | Saludable | Advertencia | Crítica |
|---|---|---|---|
| \Memory\Pool bytes paginados / bytes no paginados | 0-50% | 60-80% | 80-100% |
| MBytes disponibles | >10% o 4 GB | <10% | <1% o <500 MB |
| % Bytes guardados | 0-50% | 60-80% | 80-100% |
Linux: Parámetros de intercambio, Zswap/ZRAM y writeback
Además de THP/Huge Pages, reduzco notablemente la paginación controlando la agresividad de swapping y writeback. vm.swappiness controla lo pronto que el kernel empuja las páginas a la swap. En servidores con mucha RAM, suelo usar 1-10 para que la caché de páginas permanezca grande y los heaps inactivos no migren prematuramente. En sistemas muy escasos, un valor ligeramente superior puede salvar la interactividad porque la caché no se seca completamente - el factor decisivo es la medición bajo carga real.
Con Zswap (swap comprimido en RAM), reduzco la presión de E/S si hay muchas páginas frías durante un corto periodo de tiempo. Esto cuesta ciclos de CPU, pero a menudo es más barato que la E/S en bloque. Para sistemas de borde o de laboratorio, a veces uso ZRAM como swap primario para hacer más robustos los hosts pequeños; yo lo utilizo de forma puntual en producción cuando hay espacio de CPU disponible.
Controlo las rutas de escritura mediante vm.dirty_*-parámetros. En lugar de valores porcentuales, prefiero trabajar con bytes absolutos para evitar tormentas de escritura con grandes capacidades de RAM. La descarga en segundo plano comienza lo suficientemente pronto, mientras que bytes_sucios establece límites máximos estrictos para cargas de trabajo perezosas. Valores de ejemplo que utilizo como punto de partida:
# intercambio restringido
sysctl -w vm.swappiness=10
# Comprobar writeback (bytes en lugar de porcentaje)
sysctl -w vm.dirty_background_bytes=67108864 # 64 MB
sysctl -w vm.dirty_bytes=268435456 # 256 MB
# No descartar la caché VFS de forma demasiado agresiva
sysctl -w vm.vfs_cache_pressure=50
En Intercambiar diseño Yo prefiero dispositivos NVMe rápidos y establezco prioridades para que el kernel utilice primero la swap más rápida. Un dispositivo de intercambio dedicado evita la fragmentación de los archivos de intercambio.
# Comprobar prioridades de swap
swapon --mostrar
Habilitar swap # en dispositivo rápido con prioridad alta
swapon -p 100 /dev/nvme0n1p3
Importante: Observo la fallos mayores/menores y la profundidad de la cola de E/S en paralelo - esta es la única forma en que puedo reconocer si la swappiness reducida o Zswap está suavizando los picos de latencia reales.
Causas de las altas tasas de paginación
Si no hay memoria de trabajo física, los bytes de acceso aumentan a través de la memoria integrada. RAM y el sistema pasa a swap. La fragmentación de la memoria dificulta las grandes asignaciones, de modo que las aplicaciones se bloquean a pesar de la RAM „libre“. Las consultas deficientes o la falta de índices inflan innecesariamente los accesos a los datos y aumentan las cargas de trabajo. Los picos de carga debidos a copias de seguridad, despliegues, ETL o cron jobs concentran los requisitos de memoria en breves ventanas de tiempo. Las máquinas virtuales se ven sometidas a una presión adicional cuando los hosts sobrecargan la RAM y realizan en secreto swaps de hipervisor. Activar.
Virtualización, "ballooning" y exceso de compromisos
En los entornos virtualizados, el hipervisor disfraza la situación real de la RAM y confía en el ballooning y el swapping dentro de la Invitados. Si el host se encuentra con cuellos de botella, las máquinas virtuales pierden rendimiento al mismo tiempo, aunque cada una es „verde“ por derecho propio. La paginación inteligente durante el arranque oculta los arranques en frío, pero traslada los costes al canal de E/S. Compruebo las métricas del anfitrión y del invitado conjuntamente y reduzco el sobrecompromiso antes de que los usuarios se den cuenta. Describo en detalle el efecto del sobrecompromiso en la sección sobre Exceso de memoria, para que la planificación de la capacidad siga siendo resistente.
Contenedores y Kubernetes: cgroups, límites y desalojos
Los contenedores desplazan los límites de memoria de la VM al cgroups. El factor decisivo es que solicita y límites se fijan de forma realista: Los límites que son demasiado ajustados causan muertes tempranas por falta de memoria, las peticiones que son demasiado generosas empeoran la utilización y fingen reservas. Mantengo los heaps de JVM/Node/.NET consistentemente ligados a los límites del contenedor (por ejemplo, heurística porcentual) para que el GC en tiempo de ejecución no se tope con el cgroup.
En Kubernetes, presto atención a las clases de QoS (Guaranteed, Burstable, BestEffort) y Umbrales de desahucio a nivel de nodo. Bajo presión de memoria, Kubelet favorece los pods BestEffort - si quieres mantener SLOs, tienes que presupuestar los recursos adecuadamente. PSI (Pressure Stall Information) hace visible la presión cgroup-local; utilizo estas señales para escalar o reprogramar proactivamente los pods. Para cargas de trabajo con páginas grandes, defino solicitudes explícitas de HugePage por pod para que el programador seleccione los nodos adecuados.
Estrategias de optimización: Hardware y sistema operativo
Empezaré por el tornillo de ajuste más sobrio: más RAM a menudo elimina las mayores latencias inmediatamente. Paralelamente, reduzco los fallos de página mediante THP en modo „on“ o „madvise“, si los perfiles de latencia lo permiten. Las páginas enormes reservadas proporcionan previsibilidad para los motores en memoria, pero requieren una planificación precisa de la capacidad. Con vm.min_free_kbytes creo reservas sensatas para hacer frente a los picos de asignación sin compensar la compactación. Las actualizaciones del firmware y el kernel eliminan los errores de borde, la gestión de la memoria y la NUMA-equilibrio.
| Configuración | Objetivo | Beneficio | Nota |
|---|---|---|---|
| vm.min_free_kbytes | Reserva para picos de asignación | Menos OOM/compactación | 5-10% de la RAM |
| THP (en/consejo) | Utilizar páginas más grandes | Menos fragmentación | Observar latencias |
| Páginas enormes | Bloques continuos | Asignaciones previsibles | Capacidad de reserva firme |
Bases de datos y cargas de trabajo de alojamiento
Las bases de datos se resienten rápidamente cuando la caché del búfer se reduce y las consultas se ejecutan debido al intercambio en E/S ahogado. Una configuración de memoria máxima limitada protege a SQL/NoSQL del desplazamiento mutuo con la caché del sistema de archivos. Los índices, la sargabilidad y las estrategias de join personalizadas reducen las cargas de trabajo y, por tanto, la presión sobre la RAM. En las configuraciones de alojamiento, planifico los índices de búsqueda, las cachés y los trabajadores PHP FPM en las horas punta para que los perfiles de carga no colisionen. La supervisión de la vida útil de los búferes y las páginas me advierte a tiempo de Tendencias a la baja.
Práctica: Plan de medición y calendario de puesta a punto
Empiezo con una línea de base de 24-72 horas para que los patrones y trabajos diarios sean visibles. convertirse en. A continuación, establezco un perfil objetivo de RAM libre, páginas/segundo aceptables y tiempos de espera de E/S máximos. A continuación, introduzco cambios graduales: primero los límites, luego THP/páginas enormes y, por último, la capacidad. Mido cada cambio durante al menos un ciclo de carga utilizando la misma metodología. Planifico las cancelaciones y deconstrucciones con antelación para poder reaccionar rápidamente en caso de efectos negativos. redirigir.
Pruebas de carga y previsiones de capacidad reproducibles
Para tomar decisiones fiables, reproduzco conjuntos de trabajo típicos: Cachés calientes/frías, ventanas de lotes, picos de entrada/salida. Utilizo herramientas sintéticas (por ejemplo, stress-ng para rutas de memoria, fio para E/S y benchmarks memcached/Redis para tipos de caché) para simular específicamente la presión de la memoria. Ejecuto pruebas en tres variantes en cada caso: sólo app, app+co-runners (backup, escáner AV), app+picos de E/S. Esto me permite reconocer interferencias que permanecen ocultas en las pruebas de sólo aplicación.
Recopilo paneles métricos idénticos (memoria, PSI, espera de E/S, robo de CPU/listo, fallos) para cada cambio. Un despliegue canario con tráfico 5-10% descubre los riesgos en una fase temprana, antes de desplegar la configuración de forma generalizada. En cuanto a la capacidad, planifico con los peores conjuntos de trabajo más la reserva, no con medias suavizadas.
Resolución de problemas: herramientas y firmas
En Linux, vmstat, sar, iostat, perf y strace me proporcionan las Notas para fallos de página, tiempos de espera y heaps. En cuanto a Windows, me baso en Performance Monitor, Resource Monitor y ETW traces. Mensajes como „compaction stalls“, „kswapd high CPU“ u OOM kills indican graves cuellos de botella. Interactividad fluctuante, largas pausas de GC y páginas sucias crecientes confirman la sospecha. Utilizo volcados de memoria y perfiladores de memoria para encontrar fugas y errores. Asignaciones.
Práctica específica de Windows: Pagefile, Working Set y Paged Pools
En los servidores Windows, me aseguro de que haya un Archivo Swap en unidades SSD rápidas y evitar configuraciones „sin archivo de página“. Los tamaños mínimos fijos evitan que el sistema se contraiga y recorte inesperadamente en horas punta. Distribuyo los archivos de páginas entre varios volúmenes si es necesario y observo Fallos graves/seg y la utilización de los pools paginados/no paginados.
Para los servicios que consumen mucha memoria, activo específicamente Bloquear páginas en memoria (por ejemplo, para servidores SQL) para que el núcleo no empuje las cargas de trabajo fuera del conjunto de trabajo. Al mismo tiempo, limito limpiamente las cachés de aplicaciones para que el sistema no se seque de otras formas. Identifico las fugas de controladores o pools con PoolMon/RAMMap; en caso de fallos, un recorte controlado de la lista de espera ayuda a restablecer la interactividad a corto plazo, sólo como diagnóstico, no como solución permanente.
También importante: planes de ahorro de energía configurados a „máximo rendimiento“, controladores NIC/almacenamiento y firmware actualizados. Las peculiaridades del programador o los controladores de filtro obsoletos sorprendentemente a menudo conducen a picos de memoria y E/S, que podría malinterpretar como una pura escasez de RAM.
Utilice THP, NUMA y los tamaños de página con prudencia
Las páginas transparentes enormes reducen la presión de la TLB, pero las promociones esporádicas pueden provocar picos de latencia. producir. Por eso, para cargas de trabajo con SLO estrictos, suelo recurrir a „madvise“ o a páginas fijas enormes. El equilibrio NUMA es rentable en sistemas multisocket si los hilos y la memoria permanecen locales. Vinculo los servicios a los nodos NUMA y controlo las tasas de fallos locales. Las páginas enormes aumentan el rendimiento, pero compruebo la fragmentación interna para no tener que recurrir a la "madvise". regalar.
Caché del sistema de archivos, mmap y rutas de E/S
Una gran parte de la memoria „libre“ se encuentra en el Caché de página. Decido conscientemente si un motor utiliza la caché del sistema operativo (E/S con búfer) o se cachea a sí mismo (E/S directa). Las cachés dobles desperdician RAM; si falta la caché del SO anticipada-latencias. Para las cargas de trabajo de flujo, puedo aumentar la readahead por dispositivo; las bases de datos aleatorias pesadas funcionan mejor con E/S directa.
# Ejemplo: Aumentar la readahead a 256 sectores
blockdev --setra 256 /dev/nvme0n1
E/S mapeada en memoria (mmap) ahorra copias, pero desplaza la presión a la caché de páginas. En casos excepcionales, fijo las páginas críticas con mlock (o memlock ulimits) para evitar jitter debido a reclaim - siempre con un ojo en las reservas del sistema.
Medidas de emergencia rápidas para la presión de la memoria
- Identifique los principales consumidores (ps/top/procdump) y reinicie o reprograme si es necesario.
- Estrangular temporalmente la concurrencia (workers/threads) para reducir la tasa de fallos y writeback.
- Reducir los límites sucios a corto plazo para que el saneamiento surta efecto antes y se liberen reservas.
- Para el overcommit de contenedores, evacue pods específicos; aumente temporalmente los recursos en las máquinas virtuales o relaje el ballooning.
- Compruebe la estrategia OOM: active systemd-oomd/earlyoom y cgroup-para que los procesos „correctos“ vayan primero.
Planificación y costes de capacidad
RAM cuesta dinero, pero los fallos repetidos cuestan ingresos y Reputación. Para servidores web y de bases de datos, suelo calcular una reserva de 20-30% para cubrir picos poco frecuentes. Un módulo adicional de 64 GB por 180-280 euros suele amortizarse más rápido que la extinción constante de incendios. En entornos de nube, evito el exceso de reservas y reservo los buffers por etapas que se ajusten a los patrones de carga. Los cálculos sobrios del coste total de propiedad superan a los gráficos bonitos porque tienen en cuenta los daños por latencia y el tiempo del operador. precio en.
Brevemente resumido
A Servidor de paginación de memoria se beneficia más de una RAM suficiente, una configuración limpia de THP/páginas enormes y un overcommit realista. Me baso en indicadores claros como MBytes disponibles, Bytes accedidos y Páginas/segundo. Compruebo dos veces los entornos virtualizados para que el ballooning y el host swap no roben rendimiento oculto. Mantengo las bases de datos alejadas del swap con cachés y límites definidos. Si se aplican estos pasos de forma coherente, se reducen las latencias, se evita el thrashing y se mantiene el Actuación estable durante los picos de carga.
