Deep Dive: ajuste de rendimiento con mediciones – qué cambió el 16 de octubre de 2026 y qué no

🌐 También en: English · Deutsch · Français

Deep Dive de la serie en torno al Ansible Tour. Nivel: administración Linux avanzada. El tour explica los roles; los deep dives explican la técnica que hay debajo – cómo funciona, por qué está aquí, qué hace exactamente esta instalación con ella, cómo operarla en el día a día y qué otras opciones habría habido.

El 16 de octubre de 2026 los tres servidores recibieron una ronda de ajuste: el blog y dos servidores Nextcloud. Ninguno era lento. La pregunta era otra: en los tres había memoria libre – ¿dónde ayudaría de verdad y dónde solo parecería ocupada? Este artículo recorre el método, cada cambio con la cifra que lo respalda, lo que se dejó igual a propósito y lo que dicen las mediciones cuatro días después.

🧭 El método

• Picos de siete días, no instantáneas. Un vistazo a top muestra un momento. Prometheus guarda 30 días de muestras cada 15 segundos; max_over_time(…[7d]) da el peor minuto de la semana, que es lo que los límites deben aguantar.
• Contar en lugar de suponer. Cuántos ficheros PHP hay, cuántas tablas temporales van a disco al día, cuántas instancias de inotify están en uso – cada cosa, un único comando.
• Un motivo por cambio. Cada ajuste de abajo tiene una medición al lado. Los ajustes sin medición no se tocaron.
• Antes y después. Las mismas consultas tras el despliegue, más métricas de contenedores que muestran si un límite ha quedado demasiado justo.

Los recursos y qué leer en ellos

🛡️ Por qué molestarse si nada es lento

• Subir un límite es barato antes de que muerda y caro de diagnosticar después, cuando el síntoma es un cliente de sincronización que se cuelga una vez por semana.
• Los valores por defecto son la suposición de otro. Dos de ellos se equivocaban para Nextcloud por un factor de cuatro.
• Saber qué no cambiar es la mitad del resultado: búferes más grandes en el sitio equivocado solo desplazan el cuello de botella o lo esconden.

🔧 Qué se cambió

Por qué estos y no otros

• Workers: 17 de 20 es un 85 % en el pico – la siguiente tarde con carga habría hecho cola. Los límites de los contenedores siguieron a los pools, no al revés: PSS por worker por max_children, más OPcache y APCu, con margen.
• OPcache: en el servidor Nextcloud pequeño 1.500 ficheros nunca cabían y se compilaban en cada petición. Eso lo decide el número de ficheros, no una impresión.
• Las tablas temporales con columnas TEXT nunca pueden usar el motor de memoria, así que subir tmp_table_size no habría cambiado nada. Llevar a la RAM el directorio donde se escriben, sí. Una trampa por el camino: junto con PrivateTmp=yes gana el directorio privado de systemd en disco y el tmpfs se ignora sin avisar – descubierto probando con systemd-run, no leyendo. Y en el pod del blog un volumen en memoria cuenta contra el límite de memoria del contenedor, que por eso pasó de 768 MiB a 1.280 MiB.
• inotify: K3s, containerd y cada pod con un vigilante de ficheros ocupan instancias como root. 63 de 128 está bien hoy y es un error misterioso tras los próximos pods.
• La escritura diferida al 10 % en lugar del 30 % de 23 GB significa como mucho 2,3 GB de datos sin escribir en lugar de 7 GB – bloqueos más cortos cuando el kernel por fin tiene que escribir y menos datos perdidos en una caída brusca.

tuned y sysctl: quién gana

AlmaLinux ejecuta tuned con el perfil virtual-guest, que fija por su cuenta vm.dirty_ratio = 30. Nuestro 10 es lo que informa el kernel, porque tuned vuelve a aplicar /etc/sysctl.d/ después de su propio perfil (reapply_sysctl = 1, el valor por defecto). Sin eso, el perfil desharía el ajuste en silencio en cada arranque. La única prueba fiable es el valor en vivo con sysctl -n tras un reinicio.

🧊 Qué se dejó igual a propósito

La memoria libre que nada usa tampoco se pierde: Linux la llena de caché de ficheros, justo lo que quiere un servidor de ficheros.

📊 Cuatro días después

Ningún pool se acercó a su límite, ningún contenedor a su límite de memoria, la limitación de CPU se queda en pocas unidades porcentuales y los hosts conservan libre la mayor parte de su memoria. Los cambios costaron poco y eliminaron tres techos reales – workers, huecos de bytecode, un límite de tiempo – antes de que nadie chocara con ellos.

El error de medición

Al reunir las cifras de arriba, la primera consulta para el contenedor PHP del blog devolvió un pico de 940 MiB con un límite de 1 GiB – lo que habría pedido de inmediato un límite mayor. La consulta sumaba todas las series del contenedor: durante un despliegue el pod antiguo y el nuevo existen a la vez, y justo tras reiniciar un contenedor cAdvisor informa brevemente del cgroup antiguo y del nuevo. El pico de un solo pod fue de 538 MiB. Sumar por pod, o tomar el máximo por pod, es la lectura correcta; un simple sum por nombre de contenedor suma cosas que nunca existieron en el mismo momento en un mismo proceso.

🧰 Repetir el ejercicio

# worst minute of the week, per pod (not summed over pods!)
max_over_time(max by (pod) (container_memory_working_set_bytes{container="nextcloud-fpm"})[7d:1m])

# share of CPU periods throttled
sum(increase(container_cpu_cfs_throttled_periods_total{container="nextcloud-fpm"}[7d]))
  / sum(increase(container_cpu_cfs_periods_total{container="nextcloud-fpm"}[7d]))

# PHP-FPM peak and queue
max_over_time(sum(phpfpm_active_processes)[7d:1m])
max_over_time(max(phpfpm_listen_queue)[7d:1m])

• Cuándo: tras un cambio de carga (usuarios nuevos, una app nueva), tras una actualización mayor y, si no, cada pocos meses.
• Dónde mirar primero: el panel «Container-Ressourcen» (límites, limitación, OOM kills) y las alertas de memoria y limitación de contenedores, que envían un correo cuando un límite se queda justo.
• Qué apuntar: la medición junto al ajuste. La guía de operación tiene una tabla exactamente para eso, para que la próxima ronda parta de cifras y no de recuerdos.

🆘 Chuleta: síntoma → comando

La versión corta de este artículo para el momento en que algo va mal. Ejecutar en el host como root; <…> son marcadores.

🔭 Lo que viene

• Pruebas de carga con k6 contra una instancia de pruebas, para ver dónde están los techos en lugar de esperarlos.
• Umbrales de alerta a partir de picos medidos en lugar de números redondos: el primero, para la cola de PHP-FPM, salió de 14 días de datos en octubre de 2026.
• Planificación de capacidad: crecimiento mensual de los datos del servidor Nextcloud mayor frente a su disco.

⚖️ Alternativas – y por qué medir primero

El resultado más valioso del día no fue un ajuste sino una lista: ocho cambios, cada uno con una cifra, y cinco cosas que se dejaron igual, cada una también con una cifra. La próxima ronda partirá de ahí, y si un valor resulta equivocado, quedará claro en qué se basaba.