A la lliçó anterior vas trobar un problema de rendiment la causa del qual era un valor de configuració mal ajustat: max_connexions=200 contra un max_connections=100. El vas trobar mesurant, i el vas corregir comprovant-ne l'efecte. Aquesta lliçó fa el mateix un nivell més avall: els valors que ajustaràs són els del nucli.

I comença amb un advertiment, perquè l'ajust del nucli és l'àrea de l'administració de sistemes amb més folklore per metre quadrat. Internet és ple de llistes de paràmetres «per optimitzar Linux» que es copien sense entendre, que contradiuen els valors per defecte sense motiu, i que en el millor dels casos no fan res. La regla que separa la feina del ritual és una de sola:

No s'ajusta el que no s'ha mesurat.

I el procediment que l'aplica, que és el mateix que ja has fet servir dues vegades —a l'incident del web lent de 05-07 i al de la latència de 07-02—:

1. Mesurar l'estat actual i anotar-lo. Sense línia base no hi ha «després».
2. Formular una hipòtesi concreta: quin paràmetre, per què creus que importa, i què esperes que canviï.
3. Canviar una sola cosa. Dos canvis simultanis fan impossible atribuir el resultat.
4. Mesurar de nou amb el mateix mètode.
5. Documentar el canvi amb el seu motiu, o revertir-lo. Un paràmetre sense justificació escrita és un paràmetre que ningú no podrà treure d'aquí a un any.

Els valors per defecte d'Ubuntu 24.04 són raonables per a la majoria de les càrregues. Canviar-los sense una mesura que ho avali és, amb força probabilitat, empitjorar el sistema.

1. sysctl: la interfície de paràmetres del nucli
2. Memòria virtual
3. Xarxa i pila TCP
4. Límits de fitxers i processos
5. Planificador d'E/S
6. Pàgines enormes transparents
7. Límits per procés i qui guanya
8. Governadors de freqüència i tuned
9. Mòduls del nucli
10. Compilar el nucli: quan té sentit i quan no
11. Cas Tramontana: ajustar la pila de xarxa amb mesura

El nucli exposa els seus paràmetres ajustables com a fitxers sota /proc/sys/. És el «tot és un fitxer» del Mòdul 1 aplicat a la configuració del nucli: llegir el paràmetre és llegir un fitxer, canviar-lo és escriure-hi.

sysctl és l'eina que fa el mateix amb una sintaxi de punts, on cada punt és una barra de la ruta:

Gairebé mil tres-cents paràmetres, dels quals dos terços són de xarxa. La immensa majoria no es toquen mai.

Els tres modes d'operació, i quin fer servir quan:

Aquell -w efímer és l'eina del pas 3 del procediment: permet provar un canvi, mesurar, i si empitjora les coses n'hi ha prou de reiniciar —o tornar a escriure el valor anterior— per desfer-ho. Mai es posa un paràmetre directament a /etc/sysctl.d/ sense haver-lo provat abans en calent.

La persistència i la seva precedència:

Els fitxers s'apliquen en ordre alfabètic, i l'últim a escriure un paràmetre guanya. D'aquí la convenció de numerar-los: 10- per al que ve de la distribució, 60- a 90- per al propi, i 99- per al que s'ha d'imposar a tot. I una nota important: /etc/sysctl.conf continua funcionant, però està en desús; fes servir /etc/sysctl.d/ amb fitxers separats per propòsit.

Fixa't que ja tens 60-enfortiment.conf, de 06-06, amb els paràmetres de seguretat. Els de rendiment van en un fitxer a part, i aquella separació no és estètica: quan algú hagi de revisar la postura de seguretat, o quan calgui revertir un ajust de rendiment, es toca un sol fitxer i no es barreja el que es pot treure amb el que no.

El subsistema de memòria virtual és on els ajustos tenen més impacte i on hi ha més mitologia. Els paràmetres que importen:

El més mal entès de tots. No és «quant intercanvi fer servir», ni un percentatge de memòria. És la preferència relativa del nucli entre dues maneres d'alliberar memòria quan li'n cal: descartar pàgines de memòria cau de fitxer, o moure pàgines anònimes (memòria de procés) a l'intercanvi.

I la dada que cal interioritzar abans de tocar-lo: si el sistema no fa servir intercanvi, swappiness no fa res. És un paràmetre que només es manifesta sota pressió de memòria. Abans de canviar-lo, mesura si hi ha pressió:

Zero entrades i zero sortides d'intercanvi des de l'arrencada. A srv-tramontana, amb 3,8 GB i 2,4 GB disponibles, swappiness és irrellevant avui. Abaixar-lo no milloraria res.

Val la pena canviar-lo, doncs? Sí, però per un motiu diferent del rendiment mitjà: com a assegurança contra la degradació sota pressió. Si un dia l'aplicació creix i comença a haver-hi pressió, amb swappiness=10 el nucli preferirà descartar memòria cau abans que enviar a l'intercanvi les pàgines actives del procés, cosa que evita l'escenari de latències de centenars de mil·lisegons. És una decisió defensable, i així cal documentar-la: no «això accelera el servidor», sinó «això limita el dany si algun dia falta memòria».

Aquests sí que tenen efecte mesurable, i són la causa d'un patró de latència molt característic.

Quan un procés escriu en un fitxer, les dades van primer a la memòria cau de pàgina i es marquen com a brutes (dirty); el nucli les aboca al disc més tard. Aquests dos paràmetres controlen quan:

El patró que produeixen: escriptures ràpides mentre hi ha marge, i de cop una pausa llarga quan s'assoleix dirty_ratio i el procés queda bloquejat. Amb 3,8 GB de RAM, el 20 % són uns 760 MB de dades brutes que poden haver d'anar-se'n al disc de cop.

Això és exactament el perfil de l'incident de 05-07: la còpia de seguretat escrivint a ràfegues, amb w_await de 22,85 ms i l'aplicació bloquejada. ionice va mitigar el símptoma; aquests paràmetres ataquen el mecanisme.

Els valors més petits produeixen abocaments més freqüents i petits, amb latència més uniforme:

I l'advertiment honest: això no fa el sistema «més ràpid» en cabal total —de vegades el fa una mica més lent— sinó més predictible. Per a un servei interactiu, la latència uniforme val més que el cabal màxim. Per a una còpia de seguretat aïllada, el contrari. És un compromís, no una millora.

vm.overcommit_memory=2 mereix un avís: sembla prudent («no prometis memòria que no tens») i a la pràctica fa que aplicacions perfectament normals fallin en reservar, perquè moltes en reserven molta més de la que fan servir. No es toca sense una raó molt concreta.

Aquí és on srv-tramontana té marge real, i on l'incident de 07-02 va deixar una pista sense explorar.

Quan arriba una connexió TCP, passa per dues cues abans que l'aplicació l'accepti:

I el detall crucial que fa que aquest paràmetre s'ajusti malament la meitat de les vegades: somaxconn és un sostre, no un valor efectiu. La cua real és el mínim entre somaxconn i el paràmetre backlog que l'aplicació passa a la crida listen(). Pujar somaxconn a 65535 no serveix de res si l'aplicació en demana 128.

La mesura que diu si la cua s'està omplint:

Aquell Send-Q 128 del port 8080 és la informació valuosa: l'aplicació demana un backlog de 128, així que el somaxconn de 4096 no l'afecta en absolut. I ListenOverflows a zero significa que cap connexió no s'ha descartat per cua plena. Conclusió: pujar somaxconn en aquesta màquina no faria res, i qui el posés al seu sysctl.d estaria afegint folklore.

Això és el procediment funcionant: la hipòtesi raonable («les cues de connexió són el coll») queda refutada per la mesura abans de tocar res. Refutar hipòtesis és tan valuós com confirmar-les, i força més barat.

Aquí sí que hi ha una cosa que l'incident de 07-02 va deixar a la vista. Quan l'aplicació obria 300 connexions cada deu segons, cadascuna consumia un port efímer que quedava en estat TIME_WAIT durant 60 segons:

Setanta-un sòcols en TIME_WAIT. Amb 28.231 ports disponibles no és un problema, però durant l'incident, amb 30 connexions per segon, se'n van arribar a acumular uns 1.800 — i una aplicació que n'obrís deu vegades més els esgotaria.

TIME_WAIT no és un defecte: garanteix que paquets endarrerits d'una connexió tancada no es confonguin amb una de nova que reutilitzi la mateixa parella de ports. Els ajustos possibles:

Aquell últim és l'exemple perfecte de folklore: tcp_tw_recycle apareix en centenars de guies «per optimitzar TCP», trencava les connexions des de xarxes amb NAT de forma subtil i intermitent, i va ser eliminat del nucli fa anys. Si trobes una guia que el recomana, saps que el seu autor no l'ha provada en aquesta dècada.

A Ubuntu 24.04, tcp_tw_reuse ja ve en 2 (habilitat només per a adreces de bucle i enllaç local), que és un valor prudent. La correcció real del problema de 07-02 no era cap sysctl: era arreglar el grup de connexions, que és el que vas fer.

Els tres valors de tcp_rmem són mínim, per defecte i màxim, i el nucli els ajusta automàticament dins d'aquell rang. Ampliar el màxim importa quan el producte amplada de banda × latència és gran: un enllaç d'1 Gbit/s amb 100 ms d'anada i tornada necessita uns 12 MB de finestra per saturar-se, i amb 6 MB de màxim es queda a la meitat.

En una xarxa local amb 0,4 ms de latència, com la de Tramontana, això és completament irrellevant. És un ajust per a transferències de llarga distància, i posar-lo «per si de cas» només consumeix memòria.

El control de congestió decideix a quina velocitat envia TCP quan detecta problemes a la xarxa. L'algorisme clàssic, CUBIC, interpreta la pèrdua de paquets com a senyal de congestió. BBR, desenvolupat per Google, modela en canvi l'amplada de banda i la latència reals del camí.

La diferència pràctica és gran en enllaços amb pèrdua o amb memòries intermèdies grans (el problema del bufferbloat), que és el cas de gairebé qualsevol connexió a través d'Internet:

De 77 a 185 Mbit/s en el mateix enllaç, i amb latència menor sota càrrega. default_qdisc=fq no és opcional: BBR necessita l'encuament fair queue per funcionar tal com està dissenyat, i sense ell el resultat és pitjor.

Amb la mesura feta, el canvi es fa persistent amb el seu motiu escrit:

Fixa't en el comentari: què es va mesurar, amb què, el resultat, la data i com revertir-ho. Això és la diferència entre un ajust i una línia copiada.

fs.file-max en nuclis moderns és pràcticament il·limitat, així que pujar-lo —un altre clàssic de les guies— no fa res. El límit real que s'assoleix a la pràctica és el per procés, que es veu a l'apartat següent.

fs.inotify.max_user_watches sí que s'esgota de debò, i amb un error desconcertant. Cada inotify watch consumeix una entrada, i eines de desenvolupament, sincronitzadors de fitxers i logrotate en fan un ús intensiu:

Aquell ENOSPC que no és falta de disc és una de les confusions més freqüents de Linux, i mereix ser al manual d'operació.

El planificador decideix en quin ordre se serveixen les peticions al disc. Ubuntu 24.04 fa servir la infraestructura de multicua (blk-mq):

La regla de none per a NVMe té un perquè concret que cal entendre: un planificador reordena peticions per minimitzar el moviment del capçal d'un disc mecànic. Un NVMe no té capçal, atén desenes de milers d'operacions per segon i té les seves pròpies cues al maquinari. Reordenar només hi afegeix latència i consum de CPU. En un disc mecànic, en canvi, reordenar pot multiplicar el cabal.

Com que /sys no és persistent, la manera correcta de fixar-ho és una regla d'udev que decideixi segons el tipus de dispositiu:

I dos paràmetres més de la cua que de vegades importen:

read_ahead_kb és quant llegeix el nucli per endavant. Pujar-lo (a 512 o més) ajuda en lectures seqüencials grans —una còpia de seguretat, un abocament de base de dades—; abaixar-lo ajuda en accessos aleatoris petits, perquè evita llegir dades que no es faran servir. És exactament el compromís que cal mesurar abans de tocar.

Una observació sobre la pila de Tramontana: el volum de còpies és LUKS sobre LVM sobre sda, i cada capa presenta el seu propi dispositiu de bloc amb la seva pròpia cua. El planificador que importa és el del dispositiu físic (sda); els dispositius dm-* passen les peticions cap avall. És la mateixa pila que calia descompondre al primer exercici de 07-02.

El processador tradueix adreces virtuals a físiques en pàgines de 4 KB, fent servir una memòria cau anomenada TLB. Amb molta memòria, la TLB falla sovint i cada fallada costa accessos extra a memòria. Les pàgines enormes de 2 MB redueixen dràsticament el nombre d'entrades necessàries.

THP (Transparent Huge Pages) fa això automàticament. I és el paràmetre que totes les bases de dades demanen desactivar:

Per què les bases de dades ho rebutgen, que és la part interessant: per donar una pàgina de 2 MB, el nucli necessita 2 MB físicament contigus. Quan la memòria està fragmentada, l'ha de compactar, i aquella compactació passa de forma síncrona en el context del procés que demana memòria. El resultat són pauses impredictibles de desenes o centenars de mil·lisegons justament al procés que menys les tolera. PostgreSQL, MongoDB, Redis, Oracle i Elasticsearch documenten tots la recomanació de madvise o never.

madvise és el millor compromís: els processos que se'n beneficien ho demanen explícitament, i els altres no en paguen el cost.

Com que /sys no persisteix, es fixa amb una unitat de systemd —aplicant 05-05—, que és més net que un rc.local:

El Before=postgresql.service importa: el canvi ha d'estar aplicat abans que la base de dades reservi la seva memòria compartida.

Un límit del nucli és global; els que s'assoleixen a la pràctica són els per procés, i aquí hi ha tres mecanismes que es trepitgen entre ells. Saber quin guanya estalvia hores de desconcert.

I la resposta a «quin guanya», que és la raó d'aquest apartat: per a un servei de systemd, guanya la unitat, i limits.conf no s'aplica en absolut. systemd arrenca els serveis directament, sense passar per PAM. Posar svc-tramontana hard nofile 16384 a limits.conf i esperar que afecti tramontana.service és un error clàssic que no dona cap avís: simplement no funciona.

Amb MemoryMax=512M i TasksMax=64 ja posats a 05-05, el límit de fitxers oberts s'ajusta igual, per drop-in:

214 descriptors en ús amb un límit de 8192: marge de sobres sense ser absurd. Aquell és el criteri — un límit es dimensiona a partir de l'ús mesurat, no d'un número rodó copiat.

En una màquina virtual la gestió de freqüència la fa l'amfitrió, així que aquest apartat no s'aplica a srv-tramontana. En maquinari físic:

El cas d'ús real de performance és la latència de cua: pujar de freqüència triga microsegons, i en un servei amb objectius de latència estrictes aquells microsegons apareixen al percentil 99. A canvi de força més consum elèctric.

tuned és la manera sensata d'aplicar conjunts coherents d'ajustos en lloc de paràmetres solts:

Aquella última ordre és el consell important: tuned és útil perquè aplica conjunts provats i consistents, però llegir què fa un perfil abans d'activar-lo és obligatori. Un perfil pot canviar vint paràmetres, i si un d'ells entra en conflicte amb el teu sysctl.d, el resultat depèn de l'ordre d'aplicació i és difícil de depurar.

Un mòdul és un tros de nucli que es carrega i es descarrega en calent: controladors, sistemes de fitxers, protocols.

La configuració persistent:

Dos detalls importants. El primer: install <modul> /bin/true és més eficaç que blacklist <modul>, perquè blacklist només evita la càrrega automàtica i no impedeix que un altre mòdul el carregui com a dependència. El segon: després de tocar modprobe.d, cal regenerar l'initramfs, pel que vas aprendre a 07-01 — l'initramfs porta la seva pròpia còpia d'aquella configuració.

Aquesta llista de mòduls bloquejats és, de fet, una recomanació dels CIS Benchmarks que va quedar pendent a la llista de comprovació de 06-06. És un bon moment per tancar-la.

DKMS (Dynamic Kernel Module Support) resol el problema dels mòduls de tercers: un mòdul compilat per al nucli 6.8.0-41 no funciona al 6.8.0-45. DKMS el recompila automàticament a cada actualització del nucli:

Amb Secure Boot actiu, un mòdul recompilat per DKMS necessita signatura, i aquí entra el mmx64.efi (MokManager) que vas veure a 07-01. És la causa habitual que un controlador de tercers deixi de funcionar després d'actualitzar el nucli en una màquina amb Secure Boot.

Compilar el nucli és un ritu de pas en l'aprenentatge de Linux, i convé ser honest sobre la seva utilitat en un servidor de producció: gairebé mai no en té.

I el cost que se subestima: un nucli compilat a mà queda fora del sistema de paquets. No rep actualitzacions de seguretat automàtiques —adeu a l'unattended-upgrades de 05-03—, no està signat per a Secure Boot, i cada CVE del nucli exigeix recompilar a mà. En una màquina que tracta dades personals, això és un problema de compliment, no només de comoditat.

Les variants empaquetades cobreixen gairebé tot:

El procediment, per al laboratori:

make olddefconfig partint de /boot/config-$(uname -r) és el que evita l'error del principiant: make defconfig genera una configuració genèrica que probablement no inclogui el controlador del teu controlador de disc, i el resultat és l'indicador (initramfs) de 07-01.

L'exercici complet, aplicant el procediment de cinc passos. Punt de partida: la línia base de 05-07, l'incident dels db_timeout amb connexions_actives=200, i l'ajust del grup de connexions de 07-02.

Tres hipòtesis raonables a partir de l'historial, i què diu la mesura de cadascuna:

Dues de tres refutades per la mesura, i aquest és el resultat normal. Si haguessis copiat una guia d'«optimització de xarxa per a Linux», hauries posat somaxconn = 65535 —que aquí no fa res— i probablement tcp_tw_recycle, que ja no existeix.

La secció final —«NO TOQUEM, i consta per què»— és la part del fitxer que més valor té a llarg termini. Documenta les hipòtesis refutades, i això impedeix que d'aquí a sis mesos algú —tu inclòs— afegeixi somaxconn = 65535 perquè ho ha vist en una guia. Un ajust descartat amb el seu motiu escrit és coneixement; un ajust absent és només una omissió.

• Copiar llistes de sysctl d'Internet. La majoria són de fa deu anys, moltes contradiuen valors per defecte que ja són correctes, i algunes recomanen paràmetres que ja no existeixen (tcp_tw_recycle és el senyal inequívoc d'una guia sense provar).
• Canviar diverses coses alhora. Si millora, no saps quina; si empitjora, tampoc. Un canvi, una mesura.
• Posar un paràmetre a /etc/sysctl.d/ sense provar-lo amb -w. El canvi efímer és reversible amb un reinici; el persistent et pot deixar un sistema que arrenca malament.
• Creure que swappiness redueix l'ús de memòria. Només actua quan hi ha pressió i el sistema recorre a l'intercanvi. Sense intercanvi en ús, no fa res.
• Pujar somaxconn sense mirar el backlog de l'aplicació. El límit efectiu és el mínim dels dos. ss -ltn mostra el real a Send-Q.
• Confiar en limits.conf per a un servei de systemd. No s'aplica: systemd no passa per PAM. Es fa servir LimitNOFILE= a la unitat, i es verifica a /proc/<pid>/limits.
• Deixar THP en always amb una base de dades. Provoca pauses síncrones de compactació impredictibles. madvise és el compromís correcte, i cal aplicar-lo abans que la base de dades arrenqui.
• Posar mq-deadline en un NVMe. Reordenar peticions no té sentit sense capçal: només hi afegeix latència. none per a NVMe.
• Oblidar update-initramfs després de tocar /etc/modprobe.d/. L'initramfs porta la seva pròpia còpia. És la lliçó de 07-01.
• Compilar el nucli en producció. Queda fora del sistema de paquets: sense actualitzacions de seguretat automàtiques, sense signatura per a Secure Boot, i amb cada CVE a mà. Prova primer linux-image-virtual o el nucli HWE.
• Ajustar sense línia base. Sense un «abans» registrat, el «després» no significa res, i la sensació de millora és notòriament poc fiable.
• Consell de mètode. El comentari de cada paràmetre ha de respondre a quatre preguntes: què vas mesurar, amb quina ordre, quin resultat, i com revertir-ho. I documenta també el que vas decidir no tocar: és el que evita que el folklore torni a entrar.

El Luis t'envia aquesta llista «per optimitzar el servidor», treta d'un blog:

Avalua cada línia: què faria, si té sentit a srv-tramontana, i amb quina ordre ho comprovaries. Redacta la resposta que li enviaries.

Després de l'ajust de 07-02, l'aplicació manté un grup de 80 connexions a PostgreSQL. Comprova si els límits de descriptors de fitxer són adequats als tres nivells implicats (el servei de l'aplicació, el de PostgreSQL, i el global), i ajusta el que calgui amb la seva mesura.

/srv/tramontana/backups és LUKS sobre LVM sobre sda, i vols saber si el planificador d'E/S influeix en la durada de la còpia nocturna. Dissenya l'experiment: què mesuraries, com aïllaries la variable, i per què el resultat podria no ser concloent.

Solució 1

Re: llista d'optimització del nucli

Gràcies, Luis. L'he revisada línia per línia contra l'estat real del servidor. Resum: una té sentit, una és contraproduent, una no existeix, i quatre no farien res. Et passo el detall amb les ordres, perquè ho puguis comprovar tu mateix.

---

1. net.core.somaxconn = 65535 — Sense efecte

somaxconn és un sostre. La cua real és el mínim entre aquest valor i el backlog que l'aplicació demana a 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: l'aplicació en demana 128, així que el valor actual (4096) ja és irrellevant, i 65535 ho seria igual. I ListenOverflows = 0 significa que mai no s'ha descartat una connexió per cua plena. Perquè aquest paràmetre servís caldria canviar el backlog al codi de l'aplicació, i no hi ha cap evidència que calgui.

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

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

Es va eliminar del nucli a la versió 4.12 (2017) perquè trencava les connexions des de xarxes amb NAT de forma intermitent i molt difícil de diagnosticar. Que aparegui a la guia ens diu una cosa útil: l'autor no l'ha provada en aquesta dècada, així que convé desconfiar de la resta. Si l'objectiu era el reciclatge de TIME_WAIT, el paràmetre vigent és tcp_tw_reuse, i ja és en 2, que és el valor prudent per defecte a Ubuntu 24.04.

3. net.ipv4.tcp_max_syn_backlog = 65535 — Sense efecte mesurable

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

És la cua de connexions a mig establir, i la seva utilitat real és resistir una inundació de SYN. Zero descarts amb el valor actual de 1024. A més, contra aquell atac ja tenim tcp_syncookies actiu des de 06-03, que és la defensa correcta. Pujar-lo reservaria memòria del nucli sense benefici.

4. fs.file-max = 2097152 — Sense efecte (i seria una baixada)

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

En nuclis moderns ja és pràcticament il·limitat: fixar 2.097.152 seria reduir-lo. I en fem servir 2.848. El límit que sí que s'assoleix a la pràctica és el de per procés, que en un servei de systemd es posa amb LimitNOFILE= a la unitat — limits.conf no s'aplica als serveis, que és un detall que confon molta gent.

5. vm.swappiness = 0 — Contraproduent

Aquest és el que em preocupa. swappiness = 0 no significa «no facis servir intercanvi», significa «fes servir intercanvi només per evitar l'OOM killer». L'efecte real és que el nucli esgota la memòria cau per complet abans de considerar l'intercanvi, i en un pic de memòria pot invocar l'OOM killer abans d'hora — matant el procés de l'aplicació o de PostgreSQL.

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

Avui tant se val perquè no hi ha activitat d'intercanvi, però el dia que n'hi hagi, 0 és pitjor que el valor per defecte. He posat 10, que prefereix descartar memòria cau sense renunciar a l'intercanvi com a xarxa de seguretat, i ho he documentat com a assegurança contra la degradació, no com a millora de rendiment.

6 i 7. rmem_max / wmem_max = 128 MB — Sense efecte, i consumeix memòria

Les memòries intermèdies grans importen quan el producte amplada de banda × latència és gran.

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

Amb 0,4 ms d'anada i tornada en xarxa local, la finestra necessària per saturar 1 Gbit/s són uns 50 KB. El màxim actual (208 KB de rmem_max, i fins a 6 MB a tcp_rmem) sobra amb escreix. Reservar 128 MB per sòcol en una màquina amb 3,8 GB de RAM és un risc real si s'obren moltes connexions.

---

El que sí que he fet, i per què

Seguint el mateix criteri —mesurar primer—, l'únic canvi de xarxa que ha resultat justificat és el control de congestió BBR, que no era a la teva llista:

# cubic (per defecte)
$ 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 cap a clients remots. Aquell sí que és un ajust amb efecte mesurat, i és a /etc/sysctl.d/70-rendiment.conf amb la mesura, la data i la manera de revertir-lo.

El que proposo per a la propera vegada. Abans d'aplicar un paràmetre, tres preguntes: quin comptador em diu que aquest recurs és el coll? l'he provat amb sysctl -w i mesurat abans i després? està escrit el motiu? Si alguna resposta és no, el paràmetre no entra. He afegit al fitxer una secció de «NO TOQUEM, i consta per què» amb aquestes set línies i la seva raó, precisament perquè no ho tornem a discutir d'aquí a sis mesos.

Solució 2

Els tres nivells, mesurats de dins cap enfora.

Ús real 214 sobre un límit de 8192: folgat i correcte. El desglossament confirma que el número té sentit:

80 sòcols = el grup de connexions a PostgreSQL, exactament el valor de max_connexions=80 que es va ajustar a 07-02. Els descriptors són on han de ser.

El límit tou és 1024, i max_files_per_process és 1000. I aquí està el càlcul que revela el risc: cada procés de rerefons de PostgreSQL obre descriptors per als fitxers de taula i índex que toca. Amb 100 connexions possibles i fins a 1000 fitxers per procés, el límit de 1024 del procés principal és estret.

Avui no s'està assolint, però el marge és escàs i la fallada, quan arriba, es manifesta com a errors de connexió intermitents sota càrrega — difícils de diagnosticar.

2.848 descriptors a tot el sistema contra un límit pràcticament infinit: no hi ha res a ajustar, i això confirma el que se li va respondre al Luis a l'exercici anterior sobre fs.file-max.

Aquí hi ha una decisió de criteri: es podria pujar el valor per defecte global, però és preferible no fer-ho. Un límit per defecte alt amaga les fuites de descriptors: un servei que no tanca el que obre falla aviat i de forma visible amb un límit raonable, i consumeix memòria del nucli silenciosament durant mesos amb un d'alt. Millor límits explícits i dimensionats per servei.

Verificació final:

Zero errors EMFILE/ENFILE, que són els que apareixerien si s'esgotessin els descriptors. I la lliçó de mètode: el problema era a PostgreSQL, no a l'aplicació, encara que el símptoma anterior es manifestés a l'aplicació. Igual que a 07-02, la causa era a l'altre costat de la relació client-servidor. Convé afegir al manual d'operació la regla: en ajustar un límit d'un costat, comprovar el de l'altre.

Solució 3

Què mesuraria, i per què aquelles mètriques. La durada total de la còpia és la variable d'interès, però és massa gruixuda per atribuir-la al planificador. Cal mesurar a tres nivells:

Com aïllaria la variable. Aquest és el nucli de l'exercici, i hi ha quatre fonts de contaminació que cal neutralitzar:

I una decisió de disseny important: l'experiment es fa a srv-tramontana-proves, no en producció. És la VM que crearàs a la lliçó següent, i aquest és exactament el cas d'ús que la justifica: canviar el planificador d'E/S en calent al servidor real, amb drop_caches i sense ionice, és demanar una degradació del servei.

Per què el resultat podria no ser concloent. Cinc motius, i són els que fan que aquest sigui un bon exercici:

1. El planificador que importa és el del dispositiu físic, no el de la pila. /srv/tramontana/backups és dm-1 (LUKS) sobre lv-backups (LVM) sobre sda. Els dispositius dm-* no tenen planificador propi: passen les peticions cap avall. Es comprova:

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

   Un none fix, sense alternatives entre claudàtors, indica que aquell dispositiu no planifica. Així que l'experiment només té sentit sobre sda.

2. Som en una màquina virtual. El planificador de l'hoste opera sobre un disc que en realitat és un fitxer a l'amfitrió, que té el seu propi planificador i la seva pròpia memòria cau. Les decisions de l'hoste poden quedar completament anul·lades per l'amfitrió. Això és el que probablement farà que el resultat no sigui concloent, i és la raó per la qual virtual-guest és el perfil de tuned actiu.

3. El coll podria ser el xifratge, no l'E/S. Si perf stat dona CPUs utilized a prop d'1,00 i offcputime assenyala funcions d'AES, el procés està limitat per CPU i el planificador d'E/S és irrellevant per definició. Aquest control cal fer-lo abans de l'experiment: si el coll és el xifratge, l'experiment no escau.

4. La còpia és majoritàriament escriptura seqüencial, i allà les diferències entre planificadors són petites. On se separen de debò és en la barreja de lectura aleatòria i escriptura amb diversos processos competint.

5. restic deduplica i comprimeix, així que la relació entre dades llegides i blocs escrits no és fixa. Encara que les dades d'origen siguin idèntiques, la càrrega d'E/S pot variar entre execucions.

Conclusió del disseny. L'experiment s'ha de fer, però amb l'expectativa correcta: la hipòtesi més probable és que el planificador no influeixi de forma mesurable en aquesta màquina, i el pas 3 —mesurar si el coll és CPU o E/S— probablement ho demostrarà abans de començar. Això no és un fracàs: és refutar una hipòtesi per 30 minuts de feina, i evita afegir una regla d'udev que no fa res.

I si el pas 3 mostra que el coll és el xifratge, la línia d'investigació correcta és una altra: comprovar si la CPU exposa AES-NI a l'hoste (grep -m1 aes /proc/cpuinfo) i, si no, activar host-passthrough a la definició de la VM. Això pot multiplicar per cinc o deu la velocitat del xifratge, i és un canvi de virtualització, no de nucli. Just el terreny de la lliçó següent.

Saps ajustar el nucli, i —més important— saps quan no ajustar-lo. Tens el mapa dels paràmetres que de debò importen: la memòria virtual amb swappiness i els llindars de pàgines brutes, la pila de xarxa amb les seves dues cues de connexió i el control de congestió, els límits de fitxers amb el parany de limits.conf que no s'aplica als serveis de systemd, el planificador d'E/S amb la regla de none per a NVMe i el seu perquè, i les pàgines enormes transparents que tota base de dades demana en madvise. Has vist els mòduls, modprobe.d amb install ... /bin/true —tancant de passada una fila pendent de la llista de comprovació de 06-06—, DKMS, i una resposta honesta a compilar el nucli: gairebé mai en producció, perquè treu la màquina del sistema de paquets i amb ell de les actualitzacions de seguretat.

Però el que t'endus d'aquesta lliçó no és una llista de paràmetres. És el procediment: mesurar, formular una hipòtesi, canviar una cosa amb sysctl -w, mesurar un altre cop, i documentar amb la mesura i la data o revertir. Aplicant-lo, de tres hipòtesis raonables sobre la xarxa de srv-tramontana dues van quedar refutades —somaxconn no hi intervé perquè l'aplicació demana backlog=128, i swappiness no fa res sense activitat d'intercanvi— i només una, BBR, va resultar tenir efecte mesurable: de 77 a 185 Mbit/s. Aquella proporció és el normal, i la secció «NO TOQUEM, i consta per què» del teu 70-rendiment.conf és el que impedirà que el folklore torni a entrar d'aquí a sis mesos.

Fixa't on t'ha deixat l'últim exercici. Per provar el planificador d'E/S sense degradar el servei calia una màquina on buidar la memòria cau, treure l'ionice i aturar l'aplicació sense que ningú se n'assabentés. Per mesurar si el xifratge de LUKS va per programari calia canviar la configuració de CPU de la VM. I el desplegament 3.3.0 que no va arrencar i va provocar una reversió al Mòdul 4 no es va arribar a diagnosticar mai, perquè no hi havia on reproduir-lo. Tot apunta al mateix: falta un entorn de proves, i el curs fa quatre mòduls que el troba a faltar.

A la lliçó 07-04: Virtualització amb Linux el construeixes. Entendràs què és virtualitzar de debò —els tres models, el paper exacte de KVM com a mòdul que converteix Linux en hipervisor, i la seva relació amb QEMU i libvirt—, manejaràs màquines amb virsh i virt-install, aprovisionaràs sense intervenció amb cloud-init, triaràs entre raw i qcow2 sabent per què, faràs instantànies recordant que una instantània no és una còpia de seguretat, i connectaràs la xarxa per NAT o per pont segons convingui —inclosa l'explicació d'aquell virbr0 sense enllaç que costava 35 segons d'arrencada a 07-01—. Al final tindràs srv-tramontana-proves, clonat del servidor real: el lloc on provar els canvis de nucli d'aquesta lliçó, reproduir el desplegament que va fallar, i assajar la recuperació de l'arrencada de 07-01 sense arriscar res. I de passada veuràs la pila de virtualització des de dins, que és el que fa que la lliçó següent —contenidors— s'entengui per contrast i no per analogia.