- Ajustar el nucli Linux requereix combinar configuració arquitectònica, sysctl i planificació de CPU orientada a latència.
- Els kernels personalitzats i els pegats PREEMPT_RT permeten baixar la latència extrema, però impliquen més complexitat i manteniment.
- L'optimització de xarxa, memòria, disc i serveis del sistema sempre s'ha de mesurar amb monitorització i benchmarking rigorosos.
- Un enfocament iteratiu i basat en mètriques converteix les millores del nucli en beneficis reals per a aplicacions i usuaris.
Quan parlem de rendiment a Linux, gairebé tot acaba apuntant al mateix lloc: el nucli com a peça central que controla latència, estabilitat i ús de recursos . Afinar-ho bé pot marcar la diferència entre un sistema que “va tirant” i un altre que respon amb fluïdesa en servidors, escriptoris, entorns cloud o fins i tot en maquinari molt antic.
Aquesta guia se centra en com optimitzar el nucli de Linux per minimitzar la latència sense carregar-se la seguretat ni la mantenibilitat . Veurem des de conceptes arquitectònics bàsics fins a ajustaments amb sysctl, compilació de kernels personalitzats, ús de pegats de temps real, tuning per a xarxes de baixa latència (com a EC2), i tècniques de monitorització i benchmarking per mesurar si el que toques realment millora alguna cosa.
Arquitectura del nucli de Linux i punts clau per a la latència
El kernel de Linux actua com a capa intermèdia entre aplicacions i maquinari, gestionant memòria, processos, interrupcions, drivers i sistemes de fitxers . El seu disseny monolític però modular , gràcies als mòduls carregables, permet activar o desactivar funcionalitats de manera flexible sense recompilar tot el sistema.
Per entendre d'on surten les latències, és clau conèixer diversos subsistemes: el planificador de processos (scheduler) , la gestió de memòria i el maneig d'interrupcions. Un scheduler mal ajustat, una política de memòria agressiva o un excés d'interrupcions sense controlar es poden traduir en respostes lentes encara que el maquinari sigui potent.
A la configuració del kernel entren en joc opcions com CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY o CONFIG_SMP , que determinen fins a quin punt el kernel es pot interrompre per atendre tasques més urgents i com explota sistemes multinucli. Escollir el model de preemption adequat canvia notablement la latència percebuda en escriptoris, servidors de baixa latència o sistemes industrials.
En servidors moderns també importa la topologia del maquinari: distribució de nuclis, sockets, NUMA i jerarquia de memòria cau . Afinar afinitats de CPU i polítiques NUMA (per exemple, fixar processos i memòria al mateix node) ajuda a reduir temps d'accés ia millorar el cache hit rate, cosa clau quan volem minimitzar jitter i latències impredictibles.
A més, la interacció entre scheduler de CPU i subsistemes d' I/O (disc i xarxa) determina el throughput i la latència end-to-end que veuen les aplicacions. Abans de tocar res, convé documentar l'estat actual (configuració del nucli, sysctl, GRUB, mòduls carregats) per poder revertir ràpidament si un canvi empitjora el rendiment.
Ajustaments via sysctl per millorar latència i rendiment
La interfície sysctl permet modificar paràmetres del nucli en calent mitjançant /proc/sys, sense haver de recompilar. És el punt d'entrada ideal per començar a tunejar sense embolicar-se encara amb compilacions.
Al terreny de xarxa, paràmetres com net.core.rmem_max, net.core.wmem_max o net.ipv4.tcp_congestion_control impacten directament en throughput, latència i comportament de les connexions TCP. Ajustar correctament els memòria intermèdies i l'algorisme de congestió és vital en servidors web d'alt trànsit o instàncies cloud de baixa latència.
Per a la memòria, valors com vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure o vm.overcommit_memory permeten controlar quant es recorre a swap, com es gestiona la memòria cau de pàgina i el comportament de la memòria virtual. Reduir swappiness (per exemple a 10) sol ajudar que el sistema no llenci tan ràpid de swap, reduint pics de latència per I/O de disc.
Si treballeu amb bases de dades grans o aplicacions que usen memòria compartida massivament, és crític ajustar kernel.shmmax, kernel.shmall i el nombre màxim de fitxers oberts amb fs.file-max i fs.nr_open . Aquests límits mal dimensionats poden causar colls dampolla i errors difícils de diagnosticar sota càrrega.
El que és recomanable és aplicar canvis petits, mesurar el seu impacte amb eines de monitorització, i només després persistir-los a /etc/sysctl.conf oa /etc/sysctl.d/ . En entorns amb contenidors recorda que molts paràmetres de kernel són globals al host: tocar sense cura pot afectar tots els serveis, de manera que combinar sysctl amb cgroups i namespaces és gairebé obligatori.
Compilació i manteniment de kernels personalitzats
Compilar un kernel a mida segueix sent una eina molt potent quan vols reduir latència, treure llast innecessari o suportar maquinari rar . Encara que les distribucions porten kernels força versàtils, en certs escenaris un kernel específic marca la diferència.
El flux clàssic consisteix a descarregar el codi des de kernel.org o d'arbres amb pegats com xanmod o liquorix, i utilitzar eines com make menuconfig per triar opcions. Desar el fitxer .config al vostre propi dipòsit git, juntament amb scripts de compilació, permet reproduir builds i mantenir coherència entre versions.
Si utilitzes Debian o derivades, és molt còmode compilar “ a la manera Debian ” per obtenir paquets .deb del nucli, headers i biblioteques associades. Així pots desplegar aquest kernel custom a diverses màquines simplement instal·lant els paquets i gestionant versions amb el teu propi repositori.
Al món real, moltes vegades compilar a mà té sentit quan treballes amb maquinari vell o molt limitat . Un exemple típic és una netbook antiga amb CPU Atom i 1 GB de RAM, on un nucli genèric modern, ple de drivers innecessaris i opcions per a servidors, introdueix latències i consum de CPU extra que no et pots permetre.
Una estratègia habitual és partir de la configuració del nucli actual (per exemple, copiant el config de /boot ), i des d'aquí retallar o ajustar. Podeu canviar el model de preemption a “ Preemptible Kernel (Low-Latency Desktop) ” per prioritzar la resposta interactiva de l'escriptori, o afegir programadors d'E/S específics com BFQ en forma de mòdul per millorar l'experiència en discos mecànics.
Per no llençar-te mitja vida compilant, és lògic fer el build en una màquina més potent i, si cal, fer servir cross-compiling (per exemple, compilar un kernel de 32 bits per a un Atom des d'un PC x86_64 simplement ajustant ARCH i els toolchains corresponents). Després només heu d'instal·lar els .deb a la màquina destinació i afegir l'entrada adequada a GRUB.
La part delicada està en el manteniment: convé provar el nucli nou en nodes canaris , tenir clares les rutes de rollback al gestor d'arrencada i registrar logs i mètriques durant la transició per detectar regressions en rendiment o compatibilitat de drivers.
Models de preemption i pegats PREEMPT_RT per a sistemes de baixa latència
El model de preemption del kernel marca quant pot interrompre's una tasca en execució perquè una altra de major prioritat prengui el control, la qual cosa afecta directament la latència de resposta . Aquí entren tant les opcions de configuració estàndard com els pegats de temps real.
En kernels genèrics tens diverses modalitats: sense preemption (més orientat a throughput de servidor), preemption voluntària i kernel preemptible per a escriptori , que prioritza la resposta ràpida de les aplicacions interactives. Ajustar aquest punt pot donar una bona empenta de fluïdesa a sistemes descriptori, àudio o fins i tot màquines antigues molt carregades.
Quan necessiteu anar un pas més enllà, apareixen els pegats PREEMPT i PREEMPT_RT , que modifiquen trossos importants del nucli per reduir al mínim les seccions no preemptibles. PREEMPT_RT està pensat per a sistemes on el pitjor cas de latència (no només la mitjana) ha de ser molt baix i predictible: automatització industrial, àudio professional, telecomunicacions o trading d'alta freqüència.
La decisió d'introduir PREEMPT_RT no hauria de ser per moda, sinó basada en mesuraments concrets de latència i jitter . Primer convé esprémer al màxim ajustaments de scheduler, afinitats de CPU, sysctl i, si escau, configuracions com a tickless dinàmic abans de complicar el manteniment amb un arbre RT.
També cal considerar la compatibilitat: alguns drivers i subsistemes no estan plenament adaptats a RT i podrien requerir versions específiques o pegats addicionals. El més assenyat és preparar un pla de manteniment on tinguis clar quan i com integrar noves versions del nucli principal amb la branca RT, que se sincronitza periòdicament però no deixa d'anar alguna cosa per darrere.
Tunning de planificació de CPU, tickless i aïllament de nuclis
A més de triar el model de preemption, pots afinar la latència jugant amb la planificació de CPU i el comportament dels temporitzadors del nucli, sobretot en distribucions orientades a empresa com RHEL.
Red Hat Enterprise Linux 8, per exemple, ve amb un kernel tickless per defecte per a CPUs inactives , cosa que redueix consum energètic en evitar interrupcions periòdiques quan el nucli està aturat. Per a càrregues sensibles a latència es pot habilitar un mode de tickless dinàmic en un conjunt de nuclis , de manera que només una CPU (el nucli de casa) s'encarregue de la majoria de les tasques de temps, i la resta quedin el més lliures possible d'interrupcions periòdiques.
Aquesta configuració es fa afegint paràmetres adequats a la línia d'ordres del kernel a GRUB, regenerant la configuració, i després ajustant afinitat de fils de kernel crítics, com els fils de RCU o els fils bdi-flush, perquè resideixin al nucli reservat per a manteniment.
Aquest enfocament es pot complementar amb el paràmetre isolcpus , que permet aïllar nuclis de les tasques normals de l'espai d'usuari. És molt habitual en escenaris de baixa latència reservar diversos cors exclusivament per a una aplicació crítica, mentre que la resta del sistema (daemons, interrupcions, etc.) es queda en altres nuclis.
Per comprovar que el mode tickless dinàmic funciona, es poden llançar proves senzilles amb stress o scripts que mantinguin la CPU ocupada durant un segon i observar amb comptadors de ticks de temporitzador com es passa de milers d'interrupcions per segon a una sola als nuclis aïllats, senyal que el temporitzador periòdic ha desaparegut.
Gestió de memòria i emmagatzematge amb focus en latència
La manera com el kernel gestiona memòria i E/S de disc té un impacte enorme en la latència percebuda per les aplicacions , sobretot en bases de dades i serveis que fan moltes operacions petites i freqüents.
Pel costat de memòria, reduir vm.swappiness minimitza l'ús de swap (que gairebé sempre és molt més lenta que la RAM), vm.vfs_cache_pressure controla quanta pressa té el sistema per alliberar caché d'inodes i dentries, i vm.nr_hugepages permet reservar HugePages overhead de la TLB.
En emmagatzematge, triar el scheduler d'I/O apropiat segons el tipus de disc és crític. A SSD moderns sol ser bona idea utilitzar none o mq-deadline, mentre que en discos mecànics i sistemes multitasca poden venir millor algorismes pensats per a fairness com Bfq. A més, muntar sistemes de fitxers amb opcions com noatime y nodiratime evita escriptures innecessàries cada cop que s'accedeix a un fitxer o directori.
Pel que fa a sistemes de fitxers, ext4 i XFS segueixen sent les opcions més habituals: ext4 ben afinat és un valor segur, mentre que XFS sol escalar millor amb alta concurrència. Per a escenaris molt exigents, barrejar RAID (RAID 10 per a bases de dades, RAID 0 per a scratch temporal) amb un bon scheduler pot rebaixar la latència mitjana i, sobretot, la variabilitat.
Optimització de xarxa i kernel per a baixa latència a Linux i EC2
En aplicacions de xarxa d'alt rendiment, la latència no només depèn del maquinari o la distància, sinó també de com està ajustada la pila TCP/IP i el mateix nucli . Això és especialment visible en instàncies cloud com Amazon EC2 amb interfícies ENA.
Per començar, és clau reduir factors externs com el nombre de salts de xarxa que realitzen els paquets: fer servir topologies més directes, balancejadors propers al backend o zones de disponibilitat optimitzades redueix mil·lisegons de viatge abans fins i tot de tocar el sistema operatiu.
Dins del nucli, la configuració de la xarxa passa per augmentar descriptors de fitxer (ulimit -n) , dimensionar memòria intermèdia de recepció i enviament amb net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem , net.ipv4.tcst_wmem connexions.
A interfícies ENA d'AWS, la moderació d'interrupcions juga un paper important: per defecte, el driver agrupa paquets per reduir el nombre d'IRQ utilitzant rx-usecs i tx-usecs. Si vols esgotar la latència al màxim, pots desactivar aquesta moderació mitjançant ethtool -C, posant rx-usecs i tx-usecs a zero. Això baixa la latència, però puja l'overhead d'interrupcions, així que cal buscar un equilibri segons la càrrega.
També es pot aprofitar irqbalance per distribuir IRQs entre diversos nuclis , o deshabilitar-lo i fixar manualment les afinitats d'interrupcions i cues de xarxa (RSS/RPS) a cors concrets, una cosa molt típica en entorns d'ultra baixa latència o quan s'usa DPDK i se salten bona part de la pila del nucli.
Un altre paràmetre a tenir en compte són els estats C de la CPU : estats de repòs profunds redueixen consum, però introdueixen retards en “despertar” el nucli. Per reduir latència de reacció pots limitar aquests estats profunds, assumint un major consum i menor marge per a Turbo Boost en altres nuclis. Cada entorn té el seu punt dolç entre watts gastats i microsegons guanyats.
Optimització de CPU, serveis i aplicacions per reduir latència
A més del nucli en si, l'entorn que l'envolta té molt a dir sobre la latència global: des dels serveis actius al sistema fins a la configuració específica de cada aplicació.
Un servidor d'alt rendiment només hauria d'executar els dimonis realment necessaris. Serveis com Bluetooth, impressió o autodetecció de xarxa (CUPS, Avahi, etc.) en màquines de backend només consumeixen CPU, memòria i I/O sense aportar res. Revisar amb systemctl list-unit-files --state=enabled i deshabilitar allò innecessari és d'allò més barat i efectiu que pots fer.
Per prioritzar processos crítics, pots recórrer a eines com renice, chrt i taskset . Ajustar la prioritat d'un procés (renice), donar-li planificació en temps real (chrt -f 99) o fixar-lo a nuclis específics (taskset) redueix la interferència amb altres tasques, millorant la predictibilitat de la CPU per a bases de dades, VoIP, streaming o serveis de trading.
A nivell d'aplicació, el tuning és tan important com el del nucli. Servidors web com Nginx o Apache necessiten un ajust fi de workers, keepalive, caixets i compressió. Bases de dades com PostgreSQL o MySQL requereixen revisar mides de memòria intermèdia, checkpoints, pool de connexions i paràmetres d'escriptura síncrona per aconseguir latències baixes i estables.
Les JVM també influeixen: triar recol·lectors d'escombraries com G1GC o ZGC i ajustar les mides de heap pot reduir pauses que, des de fora, es tradueixen en latència. En entorns virtualitzats i de contenidors, repartir bé vCPU, vRAM i quotes d'I/O evita la contenció silenciosa que després es veu com a cues eternes en disc o CPU saturada.
Monitorització i benchmarking del kernel i del sistema
Tot aquest tuning no serveix de gaire si no mesures l'impacte. La clau és combinar monitorització contínua amb proves de rendiment reproduïbles , de manera que cada canvi del nucli o de sysctl es pugui avaluar amb dades objectives.
Per veure l'estat general del sistema pots estirar eines clàssiques com htop, vmstat, iotop o sar. Quan necessites més detall, entren en joc eines específiques del nucli com perf i ftrace, que permeten traçar el comportament del scheduler, interrupcions i trucades internes amb força precisió.
En entorns de producció és recomanable desplegar sistemes de mètriques com Prometheus, collectd o sysstat amb exporters que exposin comptadors de CPU, I/O, latències de disc i xarxa, cues de procés, etc. Aquestes dades, visualitzades a Grafana o eines similars, ajuden a detectar regressions o anomalies abans que l'usuari final noti problemes.
Per al benchmarking, la idea és reproduir la càrrega real i comparar “abans i després” de cada canvi. Eines com sysbench (per a CPU i bases de dades), fio (per a disc) o iperf3 (per a xarxa) permeten construir escenaris repetibles. És fonamental documentar versions de kernel, configuracions de sysctl, maquinari i paràmetres de prova perquè les comparacions tinguin sentit amb el temps.
A la pràctica, l'optimització del nucli Linux és un procés iteratiu: proves una sèrie d'ajustos, mesuris, et quedes amb el que aporta benefici real i descartes la resta. Amb una bona governança de canvis, pots traduir els avenços de noves versions de kernel (com a sèries més recents amb millores de scheduler, gràfics, energia o xarxes) en beneficis mesurables per a les teves aplicacions, ja sigui en servidors on-prem, al núvol o en estacions de treball exigents.
La combinació de coneixement arquitectònic del nucli, ajustaments fins amb sysctl, compilació controlada, ús selectiu de pegats de temps real i un bon sistema de mètriques permet que un administrador o equip d'operacions aconsegueixi respostes més ràpides, latències més baixes i una millor estabilitat general sense haver de canviar de maquinari a la mínima ni renunciar a la seguretat.
