En la lección anterior encontraste un problema de rendimiento cuya causa era un valor de configuración mal ajustado: max_conexiones=200 contra un max_connections=100. Lo encontraste midiendo, y lo corregiste comprobando el efecto. Esta lección hace lo mismo un nivel más abajo: los valores que vas a ajustar son los del kernel.

Y empieza con una advertencia, porque el ajuste del kernel es el área de la administración de sistemas con más folclore por metro cuadrado. Internet está lleno de listas de parámetros «para optimizar Linux» que se copian sin entender, que contradicen los valores por defecto sin motivo, y que en el mejor de los casos no hacen nada. La regla que separa el trabajo del ritual es una sola:

No se ajusta lo que no se ha medido.

Y el procedimiento que la aplica, que es el mismo que ya has usado dos veces —en el incidente de la web lenta de 05-07 y en el de la latencia de 07-02—:

1. Medir el estado actual y anotarlo. Sin línea base no hay «después».
2. Formular una hipótesis concreta: qué parámetro, por qué crees que importa, y qué esperas que cambie.
3. Cambiar una sola cosa. Dos cambios simultáneos hacen imposible atribuir el resultado.
4. Medir de nuevo con el mismo método.
5. Documentar el cambio con su motivo, o revertirlo. Un parámetro sin justificación escrita es un parámetro que nadie podrá quitar dentro de un año.

Los valores por defecto de Ubuntu 24.04 son razonables para la mayoría de las cargas. Cambiarlos sin una medición que lo respalde es, con bastante probabilidad, empeorar el sistema.

1. sysctl: la interfaz de parámetros del kernel
2. Memoria virtual
3. Red y pila TCP
4. Límites de ficheros y procesos
5. Planificador de E/S
6. Páginas enormes transparentes
7. Límites por proceso y quién gana
8. Gobernadores de frecuencia y tuned
9. Módulos del kernel
10. Compilar el kernel: cuándo tiene sentido y cuándo no
11. Caso Tramontana: ajustar la pila de red con medición

El kernel expone sus parámetros ajustables como ficheros bajo /proc/sys/. Es «todo es un archivo» del Módulo 1 aplicado a la configuración del núcleo: leer el parámetro es leer un fichero, cambiarlo es escribir en él.

sysctl es la herramienta que hace lo mismo con una sintaxis de puntos, donde cada punto es una barra de la ruta:

Casi mil trescientos parámetros, de los cuales dos tercios son de red. La inmensa mayoría no se toca nunca.

Los tres modos de operación, y cuál usar cuándo:

Ese -w efímero es la herramienta del paso 3 del procedimiento: permite probar un cambio, medir, y si empeora las cosas basta con reiniciar —o volver a escribir el valor anterior— para deshacerlo. Nunca se pone un parámetro directamente en /etc/sysctl.d/ sin haberlo probado antes en caliente.

La persistencia y su precedencia:

Los ficheros se aplican en orden alfabético, y el último en escribir un parámetro gana. De ahí la convención de numerarlos: 10- para lo que viene de la distribución, 60- a 90- para lo propio, y 99- para lo que debe imponerse a todo. Y una nota importante: /etc/sysctl.conf sigue funcionando, pero está en desuso; usa /etc/sysctl.d/ con ficheros separados por propósito.

Fíjate en que ya tienes 60-endurecimiento.conf, de 06-06, con los parámetros de seguridad. Los de rendimiento van en un fichero aparte, y esa separación no es estética: cuando alguien tenga que revisar la postura de seguridad, o cuando haya que revertir un ajuste de rendimiento, se toca un solo fichero y no se mezcla lo que se puede quitar con lo que no.

El subsistema de memoria virtual es donde los ajustes tienen más impacto y donde hay más mitología. Los parámetros que importan:

El más malentendido de todos. No es «cuánto swap usar», ni un porcentaje de memoria. Es la preferencia relativa del kernel entre dos formas de liberar memoria cuando le hace falta: descartar páginas de caché de fichero, o mover páginas anónimas (memoria de proceso) a swap.

Y el dato que hay que interiorizar antes de tocarlo: si el sistema no está usando swap, swappiness no hace nada. Es un parámetro que solo se manifiesta bajo presión de memoria. Antes de cambiarlo, mide si hay presión:

Cero entradas y cero salidas de swap desde el arranque. En srv-tramontana, con 3,8 GB y 2,4 GB disponibles, swappiness es irrelevante hoy. Bajarlo no mejoraría nada.

¿Merece la pena cambiarlo entonces? Sí, pero por un motivo distinto del rendimiento medio: como seguro contra la degradación bajo presión. Si un día la aplicación crece y empieza a haber presión, con swappiness=10 el kernel preferirá descartar caché antes que mandar a swap las páginas activas del proceso, lo que evita el escenario de latencias de cientos de milisegundos. Es una decisión defendible, y así hay que documentarla: no «esto acelera el servidor», sino «esto limita el daño si algún día falta memoria».

Estos sí tienen efecto medible, y son la causa de un patrón de latencia muy característico.

Cuando un proceso escribe en un fichero, los datos van primero a la caché de página y se marcan como sucios (dirty); el kernel los vuelca a disco más tarde. Estos dos parámetros controlan cuándo:

El patrón que producen: escrituras rápidas mientras hay margen, y de golpe una pausa larga cuando se alcanza dirty_ratio y el proceso queda bloqueado. Con 3,8 GB de RAM, el 20 % son unos 760 MB de datos sucios que pueden tener que irse a disco de golpe.

Eso es exactamente el perfil del incidente de 05-07: la copia de seguridad escribiendo en ráfagas, con w_await de 22,85 ms y la aplicación bloqueada. ionice mitigó el síntoma; estos parámetros atacan el mecanismo.

Los valores más pequeños producen volcados más frecuentes y pequeños, con latencia más uniforme:

Y la advertencia honesta: esto no hace el sistema «más rápido» en caudal total —a veces lo hace algo más lento— sino más predecible. Para un servicio interactivo, la latencia uniforme vale más que el caudal máximo. Para una copia de seguridad aislada, lo contrario. Es un compromiso, no una mejora.

vm.overcommit_memory=2 merece un aviso: parece prudente («no prometas memoria que no tienes») y en la práctica hace que aplicaciones perfectamente normales fallen al reservar, porque muchas reservan mucho más de lo que usan. No se toca sin una razón muy concreta.

Aquí es donde srv-tramontana tiene margen real, y donde el incidente de 07-02 dejó una pista sin explorar.

Cuando llega una conexión TCP, pasa por dos colas antes de que la aplicación la acepte:

Y el detalle crucial que hace que este parámetro se ajuste mal la mitad de las veces: somaxconn es un techo, no un valor efectivo. La cola real es el mínimo entre somaxconn y el parámetro backlog que la aplicación pasa a la llamada listen(). Subir somaxconn a 65535 no sirve de nada si la aplicación pide 128.

La medición que dice si la cola se está llenando:

Ese Send-Q 128 del puerto 8080 es la información valiosa: la aplicación pide un backlog de 128, así que el somaxconn de 4096 no la afecta en absoluto. Y ListenOverflows a cero significa que ninguna conexión se ha descartado por cola llena. Conclusión: subir somaxconn en esta máquina no haría nada, y quien lo pusiera en su sysctl.d estaría añadiendo folclore.

Esto es el procedimiento funcionando: la hipótesis razonable («las colas de conexión son el cuello») queda refutada por la medición antes de tocar nada. Refutar hipótesis es tan valioso como confirmarlas, y bastante más barato.

Aquí sí hay algo que el incidente de 07-02 dejó a la vista. Cuando la aplicación abría 300 conexiones cada diez segundos, cada una consumía un puerto efímero que quedaba en estado TIME_WAIT durante 60 segundos:

Setenta y un sockets en TIME_WAIT. Con 28.231 puertos disponibles no es un problema, pero durante el incidente, con 30 conexiones por segundo, llegaron a acumularse unos 1.800 — y una aplicación que abriera diez veces más los agotaría.

TIME_WAIT no es un defecto: garantiza que paquetes retrasados de una conexión cerrada no se confundan con una nueva que reutilice el mismo par de puertos. Los ajustes posibles:

Ese último es el ejemplo perfecto de folclore: tcp_tw_recycle aparece en cientos de guías «para optimizar TCP», rompía las conexiones desde redes con NAT de forma sutil e intermitente, y fue eliminado del kernel hace años. Si encuentras una guía que lo recomienda, sabes que su autor no la ha probado en esta década.

En Ubuntu 24.04, tcp_tw_reuse ya viene en 2 (habilitado solo para direcciones de bucle y enlace local), que es un valor prudente. La corrección real del problema de 07-02 no era ningún sysctl: era arreglar el grupo de conexiones, que es lo que hiciste.

Los tres valores de tcp_rmem son mínimo, por defecto y máximo, y el kernel los ajusta automáticamente dentro de ese rango. Ampliar el máximo importa cuando el producto ancho de banda × latencia es grande: un enlace de 1 Gbit/s con 100 ms de ida y vuelta necesita unos 12 MB de ventana para saturarse, y con 6 MB de máximo se queda a la mitad.

En una red local con 0,4 ms de latencia, como la de Tramontana, esto es completamente irrelevante. Es un ajuste para transferencias de larga distancia, y ponerlo «por si acaso» solo consume memoria.

El control de congestión decide a qué velocidad envía TCP cuando detecta problemas en la red. El algoritmo clásico, CUBIC, interpreta la pérdida de paquetes como señal de congestión. BBR, desarrollado por Google, modela en cambio el ancho de banda y la latencia reales del camino.

La diferencia práctica es grande en enlaces con pérdida o con búferes grandes (el problema del bufferbloat), que es el caso de casi cualquier conexión a través de Internet:

De 77 a 185 Mbit/s en el mismo enlace, y con latencia menor bajo carga. default_qdisc=fq no es opcional: BBR necesita el encolado fair queue para funcionar como está diseñado, y sin él el resultado es peor.

Con la medición hecha, el cambio se hace persistente con su motivo escrito:

Fíjate en el comentario: qué se midió, con qué, el resultado, la fecha y cómo revertirlo. Eso es la diferencia entre un ajuste y una línea copiada.

fs.file-max en kernels modernos es prácticamente ilimitado, así que subirlo —otro clásico de las guías— no hace nada. El límite real que se alcanza en la práctica es el por proceso, que se ve en el apartado siguiente.

fs.inotify.max_user_watches sí se agota de verdad, y con un error desconcertante. Cada inotify watch consume una entrada, y herramientas de desarrollo, sincronizadores de ficheros y logrotate los usan intensamente:

Ese ENOSPC que no es falta de disco es una de las confusiones más frecuentes de Linux, y merece estar en el runbook.

El planificador decide en qué orden se sirven las peticiones al disco. Ubuntu 24.04 usa la infraestructura de multicola (blk-mq):

La regla de none para NVMe tiene un porqué concreto que hay que entender: un planificador reordena peticiones para minimizar el movimiento del cabezal de un disco mecánico. Un NVMe no tiene cabezal, atiende decenas de miles de operaciones por segundo y tiene sus propias colas en hardware. Reordenar solo añade latencia y consumo de CPU. En un disco mecánico, en cambio, reordenar puede multiplicar el caudal.

Como /sys no es persistente, la forma correcta de fijarlo es una regla de udev que decida según el tipo de dispositivo:

Y otros dos parámetros de la cola que a veces importan:

read_ahead_kb es cuánto lee el kernel por adelantado. Subirlo (a 512 o más) ayuda en lecturas secuenciales grandes —una copia de seguridad, un volcado de base de datos—; bajarlo ayuda en accesos aleatorios pequeños, porque evita leer datos que no se van a usar. Es exactamente el compromiso que hay que medir antes de tocar.

Una observación sobre la pila de Tramontana: el volumen de copias es LUKS sobre LVM sobre sda, y cada capa presenta su propio dispositivo de bloque con su propia cola. El planificador que importa es el del dispositivo físico (sda); los dispositivos dm-* pasan las peticiones hacia abajo. Es la misma pila que había que descomponer en el primer ejercicio de 07-02.

El procesador traduce direcciones virtuales a físicas en páginas de 4 KB, usando una caché llamada TLB. Con mucha memoria, la TLB falla a menudo y cada fallo cuesta accesos extra a memoria. Las páginas enormes de 2 MB reducen drásticamente el número de entradas necesarias.

THP (Transparent Huge Pages) hace eso automáticamente. Y es el parámetro que todas las bases de datos piden desactivar:

Por qué las bases de datos lo rechazan, que es la parte interesante: para dar una página de 2 MB, el kernel necesita 2 MB físicamente contiguos. Cuando la memoria está fragmentada, tiene que compactarla, y esa compactación ocurre de forma síncrona en el contexto del proceso que pide memoria. El resultado son pausas impredecibles de decenas o cientos de milisegundos justo en el proceso que menos las tolera. PostgreSQL, MongoDB, Redis, Oracle y Elasticsearch documentan todos la recomendación de madvise o never.

madvise es el mejor compromiso: los procesos que se benefician lo piden explícitamente, y los demás no pagan el coste.

Como /sys no persiste, se fija con una unidad de systemd —aplicando 05-05—, que es más limpio que un rc.local:

El Before=postgresql.service importa: el cambio tiene que estar aplicado antes de que la base de datos reserve su memoria compartida.

Un límite del kernel es global; los que se alcanzan en la práctica son los por proceso, y aquí hay tres mecanismos que se pisan entre sí. Saber cuál gana ahorra horas de desconcierto.

Y la respuesta a «cuál gana», que es la razón de este apartado: para un servicio de systemd, gana la unidad, y limits.conf no se aplica en absoluto. systemd arranca los servicios directamente, sin pasar por PAM. Poner svc-tramontana hard nofile 16384 en limits.conf y esperar que afecte a tramontana.service es un error clásico que no da ningún aviso: simplemente no funciona.

Con MemoryMax=512M y TasksMax=64 ya puestos en 05-05, el límite de ficheros abiertos se ajusta igual, por drop-in:

214 descriptores en uso con un límite de 8192: margen de sobra sin ser absurdo. Ese es el criterio — un límite se dimensiona a partir del uso medido, no de un número redondo copiado.

En una máquina virtual la gestión de frecuencia la hace el anfitrión, así que este apartado no aplica a srv-tramontana. En hardware físico:

El caso de uso real de performance es la latencia de cola: subir de frecuencia lleva microsegundos, y en un servicio con objetivos de latencia estrictos esos microsegundos aparecen en el percentil 99. A cambio de bastante más consumo eléctrico.

tuned es la forma sensata de aplicar conjuntos coherentes de ajustes en lugar de parámetros sueltos:

Ese último comando es el consejo importante: tuned es útil porque aplica conjuntos probados y consistentes, pero leer qué hace un perfil antes de activarlo es obligatorio. Un perfil puede cambiar veinte parámetros, y si uno de ellos entra en conflicto con tu sysctl.d, el resultado depende del orden de aplicación y es difícil de depurar.

Un módulo es un trozo de kernel que se carga y descarga en caliente: drivers, sistemas de ficheros, protocolos.

La configuración persistente:

Dos detalles importantes. El primero: install <modulo> /bin/true es más eficaz que blacklist <modulo>, porque blacklist solo evita la carga automática y no impide que otro módulo lo cargue como dependencia. El segundo: tras tocar modprobe.d, hay que regenerar el initramfs, por lo que aprendiste en 07-01 — el initramfs lleva su propia copia de esa configuración.

Esta lista de módulos bloqueados es, de hecho, una recomendación de los CIS Benchmarks que quedó pendiente en la checklist de 06-06. Es un buen momento para cerrarla.

DKMS (Dynamic Kernel Module Support) resuelve el problema de los módulos de terceros: un módulo compilado para el kernel 6.8.0-41 no funciona en el 6.8.0-45. DKMS lo recompila automáticamente en cada actualización de kernel:

Con Secure Boot activo, un módulo recompilado por DKMS necesita firma, y ahí entra el mmx64.efi (MokManager) que viste en 07-01. Es la causa habitual de que un driver de terceros deje de funcionar tras actualizar el kernel en una máquina con Secure Boot.

Compilar el kernel es un rito de paso en el aprendizaje de Linux, y conviene ser honesto sobre su utilidad en un servidor de producción: casi nunca la tiene.

Y el coste que se subestima: un kernel compilado a mano queda fuera del sistema de paquetes. No recibe actualizaciones de seguridad automáticas —adiós al unattended-upgrades de 05-03—, no está firmado para Secure Boot, y cada CVE del kernel exige recompilar a mano. En una máquina que trata datos personales, eso es un problema de cumplimiento, no solo de comodidad.

Las variantes empaquetadas cubren casi todo:

El procedimiento, para el laboratorio:

make olddefconfig partiendo de /boot/config-$(uname -r) es lo que evita el error del principiante: make defconfig genera una configuración genérica que probablemente no incluya el driver de tu controlador de disco, y el resultado es el prompt (initramfs) de 07-01.

El ejercicio completo, aplicando el procedimiento de cinco pasos. Punto de partida: la línea base de 05-07, el incidente de los db_timeout con conexiones_activas=200, y el ajuste del grupo de conexiones de 07-02.

Tres hipótesis razonables a partir del historial, y qué dice la medición de cada una:

Dos de tres refutadas por la medición, y eso es el resultado normal. Si hubieras copiado una guía de «optimización de red para Linux», habrías puesto somaxconn = 65535 —que aquí no hace nada— y probablemente tcp_tw_recycle, que ya no existe.

La sección final —«NO TOCAMOS, y consta por qué»— es la parte del fichero que más valor tiene a largo plazo. Documenta las hipótesis refutadas, y eso impide que dentro de seis meses alguien —tú incluido— añada somaxconn = 65535 porque lo ha visto en una guía. Un ajuste descartado con su motivo escrito es conocimiento; un ajuste ausente es solo una omisión.

• Copiar listas de sysctl de Internet. La mayoría son de hace diez años, muchas contradicen valores por defecto que ya son correctos, y algunas recomiendan parámetros que ya no existen (tcp_tw_recycle es la señal inequívoca de una guía sin probar).
• Cambiar varias cosas a la vez. Si mejora, no sabes cuál; si empeora, tampoco. Un cambio, una medición.
• Poner un parámetro en /etc/sysctl.d/ sin probarlo con -w. El cambio efímero es reversible con un reinicio; el persistente puede dejarte un sistema que arranca mal.
• Creer que swappiness reduce el uso de memoria. Solo actúa cuando hay presión y el sistema recurre a swap. Sin swap en uso, no hace nada.
• Subir somaxconn sin mirar el backlog de la aplicación. El límite efectivo es el mínimo de los dos. ss -ltn muestra el real en Send-Q.
• Confiar en limits.conf para un servicio de systemd. No se aplica: systemd no pasa por PAM. Se usa LimitNOFILE= en la unidad, y se verifica en /proc/<pid>/limits.
• Dejar THP en always con una base de datos. Provoca pausas síncronas de compactación impredecibles. madvise es el compromiso correcto, y hay que aplicarlo antes de que la base de datos arranque.
• Poner mq-deadline en un NVMe. Reordenar peticiones no tiene sentido sin cabezal: solo añade latencia. none para NVMe.
• Olvidar update-initramfs tras tocar /etc/modprobe.d/. El initramfs lleva su propia copia. Es la lección de 07-01.
• Compilar el kernel en producción. Queda fuera del sistema de paquetes: sin actualizaciones de seguridad automáticas, sin firma para Secure Boot, y con cada CVE a mano. Prueba primero linux-image-virtual o el kernel HWE.
• Ajustar sin línea base. Sin un «antes» registrado, el «después» no significa nada, y la sensación de mejora es notoriamente poco fiable.
• Consejo de método. El comentario de cada parámetro debe responder a cuatro preguntas: qué mediste, con qué comando, qué resultado, y cómo revertirlo. Y documenta también lo que decidiste no tocar: es lo que evita que el folclore vuelva a entrar.

Luis te manda esta lista «para optimizar el servidor», sacada de un blog:

Evalúa cada línea: qué haría, si tiene sentido en srv-tramontana, y con qué comando lo comprobarías. Redacta la respuesta que le enviarías.

Tras el ajuste de 07-02, la aplicación mantiene un grupo de 80 conexiones a PostgreSQL. Comprueba si los límites de descriptores de fichero son adecuados en los tres niveles implicados (el servicio de la aplicación, el de PostgreSQL, y el global), y ajusta lo que haga falta con su medición.

/srv/tramontana/backups es LUKS sobre LVM sobre sda, y quieres saber si el planificador de E/S influye en la duración de la copia nocturna. Diseña el experimento: qué medirías, cómo aislarías la variable, y por qué el resultado podría no ser concluyente.

Solución 1

Re: lista de optimización del kernel

Gracias, Luis. La he revisado línea por línea contra el estado real del servidor. Resumen: una tiene sentido, una es contraproducente, una no existe, y cuatro no harían nada. Te paso el detalle con los comandos, para que lo puedas comprobar tú mismo.

---

1. net.core.somaxconn = 65535 — Sin efecto

somaxconn es un techo. La cola real es el mínimo entre este valor y el backlog que la aplicación pide en listen().

$ ss -ltn | grep 8080
LISTEN  0  128  127.0.0.1:8080  0.0.0.0:*
$ nstat -az | grep ListenOverflows
TcpExtListenOverflows  0  0.0

Send-Q = 128: la aplicación pide 128, así que el valor actual (4096) ya es irrelevante, y 65535 lo sería igual. Y ListenOverflows = 0 significa que nunca se ha descartado una conexión por cola llena. Para que este parámetro sirviera habría que cambiar el backlog en el código de la aplicación, y no hay ninguna evidencia de que haga falta.

2. net.ipv4.tcp_tw_recycle = 1 — No existe

$ sysctl net.ipv4.tcp_tw_recycle
sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory

Se eliminó del kernel en la versión 4.12 (2017) porque rompía las conexiones desde redes con NAT de forma intermitente y muy difícil de diagnosticar. Que aparezca en la guía nos dice algo útil: el autor no la ha probado en esta década, así que conviene desconfiar del resto. Si el objetivo era el reciclado de TIME_WAIT, el parámetro vigente es tcp_tw_reuse, y ya está en 2, que es el valor prudente por defecto en Ubuntu 24.04.

3. net.ipv4.tcp_max_syn_backlog = 65535 — Sin efecto medible

$ nstat -az | grep -iE 'TCPReqQFullDrop|ListenDrops'
TcpExtListenDrops  0  0.0

Es la cola de conexiones a medio establecer, y su utilidad real es resistir una inundación de SYN. Cero descartes con el valor actual de 1024. Además, contra ese ataque ya tenemos tcp_syncookies activo desde 06-03, que es la defensa correcta. Subirlo reservaría memoria del kernel sin beneficio.

4. fs.file-max = 2097152 — Sin efecto (y sería una bajada)

$ sysctl fs.file-max
fs.file-max = 9223372036854775807
$ sysctl fs.file-nr
fs.file-nr  2848  0  9223372036854775807

En kernels modernos ya es prácticamente ilimitado: fijar 2.097.152 sería reducirlo. Y usamos 2.848. El límite que sí se alcanza en la práctica es el de por proceso, que en un servicio de systemd se pone con LimitNOFILE= en la unidad — limits.conf no se aplica a los servicios, que es un detalle que confunde a mucha gente.

5. vm.swappiness = 0 — Contraproducente

Este es el que me preocupa. swappiness = 0 no significa «no uses swap», significa «usa swap solo para evitar el OOM killer». El efecto real es que el kernel agota la caché por completo antes de considerar swap, y en un pico de memoria puede invocar al OOM killer antes de tiempo — matando el proceso de la aplicación o de PostgreSQL.

$ grep -E 'pswpin|pswpout' /proc/vmstat
pswpin 0
pswpout 0
$ free -h | awk 'NR==2 {print "disponible:", $7}'
disponible: 2,4Gi

Hoy da igual porque no hay actividad de swap, pero el día que la haya, 0 es peor que el valor por defecto. He puesto 10, que prefiere descartar caché sin renunciar a swap como red de seguridad, y lo he documentado como seguro contra la degradación, no como mejora de rendimiento.

6 y 7. rmem_max / wmem_max = 128 MB — Sin efecto, y consume memoria

Los búferes grandes importan cuando el producto ancho de banda × latencia es grande.

$ ping -c3 10.0.2.15 | tail -1
rtt min/avg/max/mdev = 0.312/0.398/0.482/0.071 ms

Con 0,4 ms de ida y vuelta en red local, la ventana necesaria para saturar 1 Gbit/s son unos 50 KB. El máximo actual (208 KB de rmem_max, y hasta 6 MB en tcp_rmem) sobra con holgura. Reservar 128 MB por socket en una máquina con 3,8 GB de RAM es un riesgo real si se abren muchas conexiones.

---

Lo que sí he hecho, y por qué

Siguiendo el mismo criterio —medir primero—, el único cambio de red que ha resultado justificado es el control de congestión BBR, que no estaba en tu lista:

# cubic (por defecto)
$ iperf3 -c 198.51.100.20 -t 20 -R | tail -2
[  5]   0.00-20.00  sec   184 MBytes  77.2 Mbits/sec  receiver
# bbr + fq
$ iperf3 -c 198.51.100.20 -t 20 -R | tail -2
[  5]   0.00-20.00  sec   441 MBytes  185 Mbits/sec  receiver

De 77 a 185 Mbit/s hacia clientes remotos. Ese sí es un ajuste con efecto medido, y está en /etc/sysctl.d/70-rendimiento.conf con la medición, la fecha y la forma de revertirlo.

Lo que propongo para la próxima vez. Antes de aplicar un parámetro, tres preguntas: ¿qué contador me dice que este recurso es el cuello? ¿lo he probado con sysctl -w y medido antes y después? ¿está escrito el motivo? Si alguna respuesta es no, el parámetro no entra. He añadido al fichero una sección de «NO TOCAMOS, y consta por qué» con estas siete líneas y su razón, precisamente para que no volvamos a discutirlo dentro de seis meses.

Solución 2

Los tres niveles, medidos de dentro hacia fuera.

Uso real 214 sobre un límite de 8192: holgado y correcto. El desglose confirma que el número tiene sentido:

80 sockets = el grupo de conexiones a PostgreSQL, exactamente el valor de max_conexiones=80 que se ajustó en 07-02. Los descriptores están donde deben.

El límite blando es 1024, y max_files_per_process es 1000. Y aquí está el cálculo que revela el riesgo: cada proceso de backend de PostgreSQL abre descriptores para los ficheros de tabla e índice que toca. Con 100 conexiones posibles y hasta 1000 ficheros por proceso, el límite de 1024 del proceso principal es estrecho.

Hoy no se está alcanzando, pero el margen es escaso y el fallo, cuando llega, se manifiesta como errores de conexión intermitentes bajo carga — difíciles de diagnosticar.

2.848 descriptores en todo el sistema contra un límite prácticamente infinito: no hay nada que ajustar, y esto confirma lo que se le respondió a Luis en el ejercicio anterior sobre fs.file-max.

Aquí hay una decisión de criterio: se podría subir el valor por defecto global, pero es preferible no hacerlo. Un límite por defecto alto oculta las fugas de descriptores: un servicio que no cierra lo que abre falla pronto y de forma visible con un límite razonable, y consume memoria del kernel silenciosamente durante meses con uno alto. Mejor límites explícitos y dimensionados por servicio.

Verificación final:

Cero errores EMFILE/ENFILE, que son los que aparecerían si se agotaran los descriptores. Y la lección de método: el problema estaba en PostgreSQL, no en la aplicación, aunque el síntoma anterior se manifestara en la aplicación. Igual que en 07-02, la causa estaba al otro lado de la relación cliente-servidor. Conviene añadir al runbook la regla: al ajustar un límite de un lado, comprobar el del otro.

Solución 3

Qué mediría, y por qué esas métricas. La duración total de la copia es la variable de interés, pero es demasiado gruesa para atribuirla al planificador. Hay que medir en tres niveles:

Cómo aislaría la variable. Este es el núcleo del ejercicio, y hay cuatro fuentes de contaminación que hay que neutralizar:

Y una decisión de diseño importante: el experimento se hace en srv-tramontana-pruebas, no en producción. Es la VM que crearás en la lección siguiente, y este es exactamente el caso de uso que la justifica: cambiar el planificador de E/S en caliente en el servidor real, con drop_caches y sin ionice, es pedir una degradación del servicio.

Por qué el resultado podría no ser concluyente. Cinco motivos, y son los que hacen de este un buen ejercicio:

1. El planificador que importa es el del dispositivo físico, no el de la pila. /srv/tramontana/backups es dm-1 (LUKS) sobre lv-backups (LVM) sobre sda. Los dispositivos dm-* no tienen planificador propio: pasan las peticiones hacia abajo. Se comprueba:

   $ cat /sys/block/dm-1/queue/scheduler
   none
   

   Un none fijo, sin alternativas entre corchetes, indica que ese dispositivo no planifica. Así que el experimento solo tiene sentido sobre sda.

2. Estamos en una máquina virtual. El planificador del huésped opera sobre un disco que en realidad es un fichero en el anfitrión, que tiene su propio planificador y su propia caché. Las decisiones del huésped pueden quedar completamente anuladas por el anfitrión. Esto es lo que probablemente hará el resultado no concluyente, y es la razón por la que virtual-guest es el perfil de tuned activo.

3. El cuello podría ser el cifrado, no la E/S. Si perf stat da CPUs utilized cerca de 1,00 y offcputime señala funciones de AES, el proceso está limitado por CPU y el planificador de E/S es irrelevante por definición. Este control hay que hacerlo antes del experimento: si el cuello es el cifrado, el experimento no procede.

4. La copia es en su mayoría escritura secuencial, y ahí las diferencias entre planificadores son pequeñas. Donde se separan de verdad es en la mezcla de lectura aleatoria y escritura con varios procesos compitiendo.

5. restic deduplica y comprime, así que la relación entre datos leídos y bloques escritos no es fija. Aunque los datos de origen sean idénticos, la carga de E/S puede variar entre ejecuciones.

Conclusión del diseño. El experimento hay que hacerlo, pero con la expectativa correcta: la hipótesis más probable es que el planificador no influya de forma medible en esta máquina, y el paso 3 —medir si el cuello es CPU o E/S— probablemente lo demostrará antes de empezar. Eso no es un fracaso: es refutar una hipótesis por 30 minutos de trabajo, y evita añadir una regla de udev que no hace nada.

Y si el paso 3 muestra que el cuello es el cifrado, la línea de investigación correcta es otra: comprobar si la CPU expone AES-NI al huésped (grep -m1 aes /proc/cpuinfo) y, si no, activar host-passthrough en la definición de la VM. Eso puede multiplicar por cinco o diez la velocidad del cifrado, y es un cambio de virtualización, no de kernel. Justo el terreno de la lección siguiente.

Sabes ajustar el kernel, y —más importante— sabes cuándo no ajustarlo. Tienes el mapa de los parámetros que de verdad importan: la memoria virtual con swappiness y los umbrales de páginas sucias, la pila de red con sus dos colas de conexión y el control de congestión, los límites de ficheros con la trampa de limits.conf que no se aplica a los servicios de systemd, el planificador de E/S con la regla de none para NVMe y su porqué, y las páginas enormes transparentes que toda base de datos pide en madvise. Has visto los módulos, modprobe.d con install ... /bin/true —cerrando de paso una fila pendiente de la checklist de 06-06—, DKMS, y una respuesta honesta a compilar el kernel: casi nunca en producción, porque saca la máquina del sistema de paquetes y con él de las actualizaciones de seguridad.

Pero lo que te llevas de esta lección no es una lista de parámetros. Es el procedimiento: medir, formular una hipótesis, cambiar una cosa con sysctl -w, medir otra vez, y documentar con la medición y la fecha o revertir. Aplicándolo, de tres hipótesis razonables sobre la red de srv-tramontana dos quedaron refutadas —somaxconn no interviene porque la aplicación pide backlog=128, y swappiness no hace nada sin actividad de swap— y solo una, BBR, resultó tener efecto medible: de 77 a 185 Mbit/s. Ese ratio es lo normal, y la sección «NO TOCAMOS, y consta por qué» de tu 70-rendimiento.conf es lo que impedirá que el folclore vuelva a entrar dentro de seis meses.

Fíjate en dónde te ha dejado el último ejercicio. Para probar el planificador de E/S sin degradar el servicio hacía falta una máquina donde vaciar la caché, quitar el ionice y parar la aplicación sin que nadie se enterase. Para medir si el cifrado de LUKS va por software hacía falta cambiar la configuración de CPU de la VM. Y el despliegue 3.3.0 que no arrancó y provocó un rollback en el Módulo 4 nunca se llegó a diagnosticar, porque no había dónde reproducirlo. Todo apunta a lo mismo: falta un entorno de pruebas, y el curso lleva cuatro módulos echándolo en falta.

En la lección 07-04: Virtualización con Linux lo construyes. Entenderás qué es virtualizar de verdad —los tres modelos, el papel exacto de KVM como módulo que convierte Linux en hipervisor, y su relación con QEMU y libvirt—, manejarás máquinas con virsh y virt-install, aprovisionarás sin intervención con cloud-init, elegirás entre raw y qcow2 sabiendo por qué, harás snapshots recordando que un snapshot no es una copia de seguridad, y conectarás la red por NAT o por puente según convenga —incluida la explicación de aquel virbr0 sin enlace que costaba 35 segundos de arranque en 07-01—. Al final tendrás srv-tramontana-pruebas, clonado del servidor real: el sitio donde probar los cambios de kernel de esta lección, reproducir el despliegue que falló, y ensayar la recuperación de arranque de 07-01 sin arriesgar nada. Y de paso verás la pila de virtualización desde dentro, que es lo que hace que la lección siguiente —contenedores— se entienda por contraste y no por analogía.