Optimización avanzada del kernel Linux con sysctl

Informatec Digital » Recursos » Optimización avanzada del kernel Linux con sysctl

Si llevas tiempo administrando servidores Linux, tarde o temprano descubres que la diferencia entre un sistema normalito y uno que vuela bajo carga intensa está en cómo tengas afinado el kernel. No se trata solo de instalar más RAM o una CPU más potente: muchos cuellos de botella se resuelven ajustando unos cuantos parámetros cuidadosamente elegidos.

El kernel expone cientos de opciones de red, memoria, sistema de archivos y planificación de procesos que se pueden modificar en caliente. Con la herramienta sysctl y algunos ajustes en /proc, es posible exprimir al máximo el hardware y conseguir menos latencia, más throughput y mejor estabilidad tanto en servidores web y bases de datos como en entornos de tiempo real o Kubernetes. Eso sí, hay que saber muy bien qué se toca y cómo medirlo.

Qué es sysctl y cómo organiza los parámetros del kernel

La utilidad sysctl es la puerta de entrada para cambiar parámetros del kernel sin necesidad de recompilar ni reiniciar, permitiendo leer y modificar valores en tiempo de ejecución para probar configuraciones al instante. Estos parámetros están organizados en un árbol jerárquico bajo /proc/sys/, y cada uno controla un comportamiento concreto del sistema.

Los ajustes se agrupan en familias bien diferenciadas, lo que facilita localizar qué necesitas retocar cuando tienes un problema de rendimiento o estabilidad muy específico. Gracias a esta estructura, es posible centrarte, por ejemplo, solo en red (net.*), memoria (vm.*) o sistema de archivos (fs.*) sin perderte en el resto de opciones del kernel.

Las categorías principales que encontrarás en /proc/sys/ son, entre otras:

• kernel.*: opciones generales del núcleo (scheduler, PID, mensajes, NUMA, etc.).
• vm.*: gestión de memoria virtual, swap, cachés y políticas de overcommit.
• net.*: pila de red IPv4/IPv6, buffers TCP/UDP, colas, control de congestión.
• fs.*: límites de descriptores, inodos, inotify, AIO y comportamiento del VFS.
• dev.*: parámetros específicos de ciertos dispositivos y drivers.

Con sysctl -a puedes listar todos los parámetros disponibles, y con comandos del estilo sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse leer valores concretos, lo que resulta clave para auditar la configuración actual antes de cambiar nada. Para localizar algo concreto, es habitual filtrar con grep, por ejemplo: sysctl -a | grep tcp.

Modificar un parámetro al vuelo es tan simple como usar sysctl -w clave=valor, aunque hay que tener claro que estos cambios son temporales. Para conservarlos tras un reinicio, es imprescindible volcar la configuración en /etc/sysctl.conf o en archivos de /etc/sysctl.d/, normalmente usando ficheros numerados (por ejemplo 10-network.conf, 20-memory.conf, 99-custom.conf) que determinan el orden en que se aplican.

Medir antes de tocar: benchmarks y línea base del sistema

Antes de empezar a girar diales a lo loco, conviene establecer una línea base objetiva de rendimiento. Sin cifras previas es imposible saber si los cambios han mejorado o empeorado el sistema, y caerás en el clásico “me parece que va mejor”, que no sirve para tomar decisiones serias.

A nivel global de sistema, es buena idea recoger estadísticas de CPU, carga, memoria, disco y red durante unos minutos bajo una carga representativa. Herramientas como uptime, mpstat, vmstat, iostat -x o sar -n DEV permiten ver cómo se comporta el kernel de serie, qué tanto swap usa, cómo responde el I/O de disco y si la red está saturada o desperdiciando ancho de banda.

Además de esa visión general, resulta clave ejecutar benchmarks específicos de la aplicación que te interese optimizar. En servidores web puedes utilizar ab (Apache Bench) o herramientas similares para medir peticiones por segundo, latencia media y errores. En bases de datos, utilidades como mysqlslap o sysbench ayudan a evaluar transacciones por segundo y tiempos de consulta.

Por ejemplo, en un escenario sin tuning es habitual encontrarse cifras como 500 peticiones HTTP/s con 200 ms de tiempo medio de respuesta, unas 250 consultas SQL/s con 40 ms de latencia, una red rondando los 500 Mbps y una carga de sistema que roza el límite bajo estrés. Esos números servirán para comprobar, tras aplicar cambios en el kernel, si realmente se logra un aumento medible del throughput y una caída en la latencia.

Finalmente, documenta los comandos y los resultados obtenidos antes de tocar nada. Disponer de un histórico te permitirá comparar con rigor distintas tandas de ajustes, y te servirá también para detectar regresiones tras una actualización del kernel o tras introducir un nuevo perfil de sysctl en producción.

Ajustes avanzados de memoria: vm.*

La memoria es uno de los subsistemas donde los cambios de kernel se notan antes. Un servidor con mucha RAM, pero mal configurado, puede acabar tirando de swap sin necesidad, provocando picos de I/O y caídas drásticas de rendimiento. Por eso parámetros como vm.swappiness, los ratios de páginas sucias o el comportamiento del caché VFS son tan importantes.

El parámetro vm.swappiness controla cuánta gana tiene el kernel de mandar páginas de memoria a swap. En muchas distribuciones se sitúa en 60, un valor pensado para entornos de escritorio mixtos. En servidores de base de datos o aplicaciones de baja latencia, suele ser preferible bajarlo a 10 o incluso menos, logrando que el sistema priorice mantener datos en RAM y reduzca el swapping. No es raro ver cómo el tráfico a disco se desploma y las aplicaciones responden con mucho menos jitter tras este ajuste.

Otro bloque fundamental son vm.dirty_ratio y vm.dirty_background_ratio, que deciden qué porcentaje de memoria puede llenarse de páginas sucias antes de que el kernel empiece a volcarlas a disco. Valores demasiado altos pueden provocar grandes ráfagas de escrituras, con latencias enormes para todas las aplicaciones cuando llega el momento del flush. Reducir estos porcentajes a cifras como 15 y 5, respectivamente, suele dar lugar a un patrón de I/O más constante y predecible.

El ajuste de vm.vfs_cache_pressure define cuán agresivo es el kernel a la hora de liberar cachés de inodos y directorios. Un valor por defecto de 100 tiende a purgar el caché con rapidez, mientras que ajustes alrededor de 50 permiten retener metadatos más tiempo, aumentando el hit rate en operaciones de fichero y mejorando el rendimiento percibido del sistema de archivos, algo clave en servidores que manejan millones de archivos pequeños.

Por su parte, vm.min_free_kbytes reserva una cantidad mínima de memoria libre para garantizar que el sistema puede responder a ráfagas de asignación sin caer en situaciones de OOM súbitas. Dimensionarlo aproximadamente entre el 0,5% y el 1% de la RAM total suele ser una barrera de seguridad eficaz para evitar que bajo carga extrema el kernel se quede sin margen y empiece a matar procesos críticos, mejorando así la estabilidad general del host.

Finalmente, merece atención la política de overcommit: parámetros como vm.overcommit_memory y vm.overcommit_ratio determinan cuánta memoria virtual se concede a los procesos en relación con la RAM y el swap disponibles. En algunos casos (por ejemplo, con Redis o ciertas bases de datos) se opta por permitir sobrecompromiso agresivo, mientras que en otros se prefiere una política más conservadora que limite el riesgo de OOM y situaciones de memoria comprometida en exceso. Para técnicas de análisis y diagnóstico de casos complejos, consulta debugging de memoria en Linux.

Optimización de red avanzada: net.* y TCP/IP

La pila de red es quizá el área donde más se nota el tuning en entornos de producción. Un simple cambio en colas de conexión o buffers puede marcar la diferencia entre un servidor que se ahoga a 500 Mbps y uno que satura el gigabit con holgura. Los parámetros bajo net.core.* y net.ipv4.* son, en este terreno, tus mejores aliados.

Para empezar, los tamaños de buffer de sockets influyen directamente en el throughput máximo de una conexión, especialmente cuando hay latencias elevadas o enlaces de gran capacidad. Ajustar net.core.rmem_max y net.core.wmem_max a valores generosos (decenas o cientos de megabytes) y definir correctamente net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (mínimo, valor por defecto y máximo) permite que cada socket disponga del espacio necesario para amortiguar ráfagas de tráfico sin caer en restricciones artificiales impuestas por valores de fábrica muy conservadores.

Otro punto clave es el tamaño de las colas de conexión. Parámetros como net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog definen cuántas conexiones pendientes puede gestionar el sistema antes de empezar a tirar paquetes o rechazar handshakes. En servidores web de alto tráfico, subir estos límites puede evitar colas saturadas y reduce drásticamente los errores de conexión en picos de carga.

El comportamiento de las conexiones TCP también se puede pulir con multitud de opciones: habilitar net.ipv4.tcp_window_scaling para soportar ventanas grandes en enlaces de gran ancho de banda, activar net.ipv4.tcp_sack y net.ipv4.tcp_timestamps para mejorar la gestión de pérdidas y retransmisiones, o ajustar net.ipv4.tcp_fin_timeout y el manejo de TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) a fin de controlar el consumo de recursos en servidores con millones de conexiones cortas por minuto.

La elección del algoritmo de control de congestión también pesa. Aunque cubic sigue siendo el valor por defecto en muchas distribuciones, cambiar a bbr en kernels modernos (4.9 en adelante) mediante net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq puede multiplicar el throughput de TCP en entornos con pérdidas o latencias complicadas, logrando en determinados escenarios mejoras de entre 2 y 25 veces respecto a configuraciones clásicas, a costa de un comportamiento algo distinto en redes congestionadas.

No hay que olvidar parámetros de seguridad y fiabilidad como net.ipv4.tcp_syncookies, el manejo de redirecciones (net.ipv4.conf.all.accept_redirects, send_redirects) o el filtrado en bridges (net.bridge.bridge-nf-call-iptables en entornos Kubernetes). Bien ajustados, permiten proteger el sistema de ataques comunes (SYN flood, spoofing, etc.) sin sacrificar un rendimiento de red sólido. Para una guía práctica sobre reglas y detección, revisa la implementación de netfilter y Suricata.

Sistema de archivos, descriptores y límites globales: fs.* y ulimit

En servidores modernos, un límite bajo de descriptores de archivo es la forma más rápida de romper un sistema en plena hora punta. Cuando un servidor web, un reverse proxy o una base de datos se topan con el clásico error de “too many open files”, suele deberse a que los parámetros del kernel y los límites de usuario no estaban dimensionados para la carga real.

A nivel global, fs.file-max marca cuántos descriptores puede tener abiertos el kernel en total. Para aplicaciones con miles de conexiones simultáneas es habitual subir este valor a varios millones, acompañándolo de un incremento de fs.nr_open, que establece el techo duro de descriptores por proceso. Complementariamente, hay que ajustar /etc/security/limits.conf para que los usuarios (o servicios gestionados por systemd) tengan valores soft y hard coherentes con lo configurado en el kernel.

El subsistema inotify, muy utilizado por IDEs, herramientas de desarrollo web y sistemas de monitorización de ficheros, se controla mediante parámetros como fs.inotify.max_user_watches y fs.inotify.max_user_instances. Si te encuentras con errores relacionados con watchers o procesos que dejan de vigilar cambios en disco, seguramente necesites aumentar estos límites para evitar cuellos de botella silenciosos.

Otra característica relevante es el I/O asíncrono (AIO), cuyo máximo global se define con fs.aio-max-nr. En aplicaciones que dependen fuertemente de I/O asíncrono (ciertos motores de base de datos, sistemas de colas, etc.), incrementarlo evita que el kernel se quede sin slots para operaciones AIO bajo una carga masiva de peticiones.

Además de estos parámetros, el rendimiento del subsistema de disco se ve afectado por el scheduler de I/O configurado en cada dispositivo de bloque. En sistemas con SSD o NVMe suele ser recomendable usar schedulers ligeros como none o mq-deadline, mientras que en discos mecánicos pueden tener sentido otros como bfq según el tipo de carga. Ajustar el scheduler a través de /sys/block/<disco>/queue/scheduler y tunear opciones como la profundidad de cola (nr_requests) o el read_ahead_kb puede marcar una diferencia notable en latencia y throughput de lectura/escritura. También es importante considerar qué sistemas de ficheros y controladores se usan; por ejemplo, artículos sobre NTFSplus en Linux y otros sistemas pueden ayudar al diseñar cargas heterogéneas.

Por último, no hay que olvidar que estos límites de kernel deben ir de la mano de configuraciones de sistema como las de ulimit y unidades systemd, para garantizar que los servicios realmente puedan usar los recursos adicionales definidos y no se queden bloqueados por restricciones en capas superiores.

Kernel general, NUMA, afinidad de CPU y huge pages

Más allá de red, memoria y sistemas de archivos, el propio núcleo ofrece una serie de ajustes que influyen en la forma en que se planifican los procesos, cómo se reparten las cargas entre núcleos y nodos NUMA, y de qué forma se gestiona la memoria a gran escala. En máquinas modernas con muchos cores e incluso varios sockets, estos detalles suelen marcar la diferencia entre un servidor equilibrado y uno con núcleos saturados mientras otros están infrautilizados. También merece la pena probar kernels alternativos como kernel Liquorix en entornos donde se busca un perfil de latencia distinto.

Parámetros como kernel.pid_max establecen el rango máximo de identificadores de proceso que el sistema puede asignar, algo relevante en nodos que ejecutan gran cantidad de contenedores o procesos efímeros. Ajustar las opciones de logging del kernel (kernel.printk) ayuda a reducir ruido excesivo en dmesg sin dejar de registrar eventos críticos, lo que también influye, indirectamente, en la capacidad de diagnóstico y la estabilidad.

En cuanto a la topología de memoria, el parámetro kernel.numa_balancing controla hasta qué punto el kernel decide mover páginas entre nodos NUMA de forma automática. Desactivarlo en ciertos entornos permite gestionar de manera más explícita la afinidad de procesos y memoria, utilizando herramientas como numactl para garantizar que procesos muy intensivos en CPU y RAM se mantienen en el mismo nodo, reduciendo la latencia derivada de accesos remotos. Para entender mejor la interacción entre hardware y planificación de núcleos, también es útil revisar tecnologías como Intel Thread Director.

Las huge pages (vm.nr_hugepages) son otra pieza clave en sistemas de bases de datos u otras cargas que manejan grandes regiones de memoria contigua. Reservar un número adecuado de páginas gigantes (de 2 MB o incluso 1 GB, según la arquitectura) puede disminuir el overhead de la TLB y mejorar sensiblemente el rendimiento de aplicaciones que realizan muchas operaciones sobre grandes bloques de memoria. Para que sea efectivo, hay que coordinar la configuración del kernel con la propia aplicación, de modo que use esa memoria de forma explícita.

En el campo de la latencia y la planificación, existen parámetros del scheduler como kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_ns, que afinan el tamaño de los “trozos” de CPU asignados a cada tarea y la agresividad con la que el kernel mueve procesos entre cores. Valores más pequeños representan un sistema más preemptible, que tiende a ofrecer mejor respuesta para tareas interactivas a costa, en ocasiones, de un poco de throughput bruto.

En sistemas donde la memoria es un recurso delicado, algunos administradores optan por activar el panic ante OOM (vm.panic_on_oom) y establecer kernel.panic con un tiempo de reinicio automático. Esta estrategia, si bien algo drástica, puede resultar útil en entornos de alta disponibilidad donde es preferible un reinicio rápido y controlado a un host colgado e inestable durante horas.

Perfiles especializados: web, bases de datos, baja latencia y Kubernetes

En lugar de aplicar una única receta mágica, resulta más eficaz crear perfiles de sysctl adaptados a distintos tipos de carga: servidores web, bases de datos, plataformas de contenedores o sistemas de baja latencia. Distribuir estos ajustes en ficheros como 99-webserver.conf, 99-database.conf o 90-kubernetes.conf ayuda a mantener una configuración ordenada y fácil de versionar. También puedes considerar distribuciones y ediciones orientadas a rendimiento como CachyOS edición para servidores para entornos muy específicos.

Para servidores web (Nginx, Apache, proxies, etc.), lo esencial es manejar grandes volúmenes de conexiones simultáneas con colas amplias, tiempos de FIN_WAIT ajustados, rango de puertos efímeros ampliado y límites de descriptores muy altos. Bien afinado, es habitual pasar de unas pocas centenas de peticiones HTTP por segundo a varios miles, reduciendo la latencia media y eliminando errores por colas saturadas o puertos agotados.

En el lado de las bases de datos (MySQL, PostgreSQL y similares), se prioriza un uso mínimo de swap, un control fino de la escritura de páginas sucias y ajustes de shared memory y semáforos adecuados al motor. Parámetros como kernel.shmmax, kernel.shmall, kernel.sem y la configuración de huge pages marcan la diferencia en términos de transacciones por segundo y tiempo de respuesta, multiplicando por dos o tres el rendimiento frente a los valores por defecto en muchos escenarios.

Para aplicaciones de baja latencia extrema (trading, juegos online, procesamiento en tiempo real), se añaden todavía más ajustes específicos: net.ipv4.tcp_low_latency, desactivación de slow start tras inactividad, uso de tcp_fastopen, parámetros de busy poll (net.core.busy_poll, busy_read) y, en muchos casos, la desactivación de transparent huge pages mediante /sys/kernel/mm/transparent_hugepage/enabled. Todo ello persigue reducir al máximo la cola de procesamiento y los picos de latencia en percentiles altos, llegando a mejoras espectaculares en P99.

En entornos de contenedores y Kubernetes, el stack de red y el seguimiento de conexiones se estresan especialmente. Parámetros como net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_max, el uso de puertos reservados para NodePort o el ajuste de las tablas ARP son habituales en nodos que manejan cientos o miles de pods. Ajustarlos correctamente evita problemas de conexiones truncadas, timeouts o saturación de tablas conntrack.

Al margen de estos perfiles específicos, algunas organizaciones optan por un archivo centrado en rendimiento con seguridad reforzada, donde se combinan buffers de red grandes y swappiness reducida con medidas como tcp_syncookies o el bloqueo de redirecciones peligrosas. El objetivo es conseguir un punto de equilibrio entre rendimiento agresivo y hardening razonable.

Herramientas de profiling y monitorización del kernel

Ajustar el kernel sin medir es como tocar un mezclador de audio con los ojos cerrados. Linux ofrece un arsenal de herramientas para entender qué está haciendo realmente el sistema, desde simples contadores hasta trazas detalladas de funciones de kernel, lo que permite correlacionar cambios de configuración con efectos medibles.

Entre las utilidades de uso diario están vmstat, iostat, sar, ss, slabtop, htop o pidstat, que proporcionan información rápida sobre procesos, CPU, I/O, sockets y uso de cachés. Combinadas con logs del sistema y métricas exportadas a Prometheus, Grafana o collectd, y con recursos como monitor de sistema avanzado para Linux, dan una imagen bastante completa de cómo se comporta el host antes y después de cada afinado.

Para ir más al detalle, herramientas como perf permiten perfilar el uso de CPU a nivel de funciones, tanto de usuario como de kernel, registrando eventos durante unos segundos o minutos y luego ofreciendo un informe interactivo. Con perf stat, perf record y perf report puedes ver dónde se consume realmente el tiempo de CPU y qué parte corresponde al núcleo, identificando, por ejemplo, una tormenta de interrupciones o un scheduler mal ajustado.

Si necesitas aún más granularidad, ftrace y el subsistema de tracing del kernel ofrecen la posibilidad de activar tracers específicos (por ejemplo, el tracer de funciones) y examinar en tiempo real o post mortem qué llamadas están ocurriendo. Habilitar el tracer adecuado y analizar el contenido de /sys/kernel/debug/tracing/trace te revela puntos calientes dentro del propio kernel, algo muy útil cuando las métricas de alto nivel no bastan.

En paralelo, es recomendable instrumentar scripts de monitorización automatizados que vuelquen periódicamente datos clave (estadísticas de red, contadores de memoria, número de descriptores abiertos, etc.) en logs rotados. A partir de ciertos umbrales (por ejemplo, más de un número determinado de file descriptors abiertos), esos scripts pueden generar alertas por correo u otros canales, ayudando a detectar tendencias peligrosas antes de que exploté el problema.

Por último, en fases de prueba de estrés prolongadas (24 horas o más), herramientas como stress-ng combinadas con la recogida continua de métricas (via vmstat, iostat, sar) permiten valorar la estabilidad del sistema con la nueva configuración de kernel, verificando que no aparecen eventos OOM, bloqueos, reinicios inesperados ni degradaciones progresivas de rendimiento bajo carga sostenida.

Optimizar el kernel de Linux con sysctl y otros mecanismos no es un trabajo de una tarde, sino un proceso iterativo en el que se miden resultados, se ajustan parámetros y se documenta todo con rigor. Con una metodología clara, perfiles específicos por tipo de carga, una buena batería de herramientas de profiling y un control estricto de los cambios, es posible conseguir servidores que aprovechen al máximo su hardware, con mayor throughput, menor latencia y una estabilidad muy superior a la que ofrece la configuración genérica de fábrica.