Prestazioni del kernel Linux: effetti sulle prestazioni dell'hosting

Mostro come Prestazioni del kernel Linux influenza direttamente i tempi di caricamento, il throughput e la latenza negli ambienti di hosting, ad esempio con fino a 38 % in più di velocità WAN e 30 % in più di velocità LAN nelle attuali versioni 6.x rispetto alla 5.15. Traduco le innovazioni del kernel come HW GRO, BIG TCP e i moderni scheduler in misure chiare in modo da poter migliorare sensibilmente le prestazioni dei server. accelerare e più affidabile sotto carico.

Punti centrali

A scopo orientativo, riassumo le affermazioni più importanti e segnalo le leve che esamino per prime.

• Kernel 6.xRete significativamente più veloce grazie a BIG TCP, GRO e migliori offload.
• Schedulatore della CPULa temporizzazione più fine dei thread riduce le latenze per PHP, Python e i database.
• RisorseNUMA, lo scheduler I/O e le code di socket impediscono i colli di bottiglia.
• SintonizzazioneSysctl, affinità IRQ e caching offrono vantaggi misurabili.
• Test:, vittorie e P95/P99 assicurano un reale progresso.

La mia prima scommessa è su Rete, perché è qui che si ottengono i maggiori guadagni. Organizzo quindi l'allocazione della CPU e della memoria in modo che i thread attendano il meno possibile e il kernel attenda meno. Cambiamento di contesto viene creato. Per l'archiviazione, seleziono lo scheduler appropriato e controllo le profondità delle code e le opzioni del file system. Registro il successo con test di carico, che ripeto non appena modifico il kernel o la configurazione. In questo modo evito le regressioni e rimango coerente con ogni modifica. Mirato.

Perché le versioni del kernel determinano le prestazioni dell'hosting

Il kernel controlla Hardware, e l'intero routing I/O, quindi la versione determina direttamente la velocità e la reattività. I core 5.x più vecchi rimangono collaudati, ma spesso utilizzano meno le schede di rete, le CPU e gli stack NVMe moderni. Con la 6.8 e la 6.11 sono arrivate ottimizzazioni come Receiver HW GRO e BIG TCP, che migliorano sensibilmente il throughput a singolo flusso. ascensore. I test hanno mostrato guadagni fino a 38 % nella WAN e 30 % nella LAN, a seconda dell'MTU e del NIC. Per i siti web dinamici con PHP, Python e Node, questo riduce il tempo per richiesta e minimizza la congestione della coda del server web.

Ne traggo particolare vantaggio quando le applicazioni inviano molte piccole risposte o la terminazione TLS è molto utilizzata. CPU costi. Il nuovo scheduler distribuisce più finemente i carichi di lavoro tra i core e migliora l'interattività per i compiti brevi. Allo stesso tempo, i percorsi di rete ottimizzati riducono l'overhead per pacchetto. Il risultato è una maggiore stabilità delle latenze P95 e P99, che vengono rispettate dai motori di ricerca. Il rispetto degli obiettivi SLA fa risparmiare nervi e denaro Denaro, perché è necessario un minor overprovisioning.

Configurazione del kernel: preemption, tick e isolamento

Oltre alla versione, il Profilo di costruzione. Io uso PREEMPT_DYNAMIC sui sistemi 6.x per ottenere un buon equilibrio tra throughput e latenza. Per i compiti veramente critici in termini di latenza (per esempio, proxy TLS o gateway API) si può usare PREMESSA maggiore reattività, mentre PREMESSA_NONE accelera i lavori batch di grandi dimensioni. Controllo anche NO_HZ_FULL e isolare singoli core (isolcpus, rcu_nocbs) sui quali vengono eseguiti solo lavoratori selezionati. In questo modo, riduco l'interferenza dei ticchettii dello scheduler e dei callback della RCU. Combino questo isolamento con Affinità IRQ, in modo che gli interrupt della NIC e i lavoratori associati rimangano vicini alla CPU.

Sui sistemi con un elevato carico di interrupt, aumento moderatamente il valore del budget NAPI e osservo se ksoftirqd core occupati. Se il thread occupa permanentemente troppo tempo, distribuisco le code tramite RPS/XPS e regolo l'IRQ coalescing. L'obiettivo è tenere sotto controllo i softirq in modo che i thread delle applicazioni non competano per il tempo della CPU.

Confronto delle prestazioni: vecchie e nuove versioni del kernel

Riassumo le differenze più importanti in un documento compatto Tabella e integrano le raccomandazioni per le applicazioni. Le informazioni si basano su misurazioni con 1500B e 9K MTU, che mappano flussi di grandi dimensioni e collegamenti a centri dati. Questo mi aiuta a scegliere la versione giusta per ogni profilo di host. Prendo anche nota del fatto che il driver NIC supporta pienamente funzioni quali GRO, TSO e RFS. Senza questo supporto, i miglioramenti del kernel a volte si esauriscono nell'overhead del driver, con conseguente perdita di tempo prezioso. Cicli mangia.

Versione del kernel	Miglioramento della WAN	Miglioramento della LAN	Caratteristiche speciali	Adatto per
5.15	Linea di base	Linea di base	Driver comprovati	Hosting legacy
6.8	+38 %	+30 %	HW GRO, BIG TCP	Traffico intenso
6.11	+33-60 %	+5-160 %	Ottimizzazioni del ricevitore	Intensità di rete

Chiunque utilizzi BIG TCP controlla il numero massimo di SKB_FRAGS e l'MTU in modo che la scheda elabori in modo efficiente i segmenti di grandi dimensioni. Sugli host AMD, il single-stream è aumentato da 40 a 53 Gbps in alcuni casi, e anche di più su Intel, a seconda delle dimensioni del pacchetto. Evito di volare alla cieca e faccio i test con NIC configurate in modo identico, MTU identico e la stessa configurazione TLS. Solo allora valuto i guadagni reali per carico di lavoro. In questo modo scelgo la versione che meglio si adatta al mio profilo di host nella pratica. serve.

Scheduling della CPU e NUMA: effetto reale sotto carico

L'allocazione della CPU determina il funzionamento regolare o meno dei thread. corsa o in costante attesa. I moderni core 6.x danno maggiore priorità ai compiti brevi e riducono i picchi di latenza per i server web e i proxy. Il bilanciamento NUMA è importante sugli host con più socket della CPU, altrimenti gli accessi alla memoria finiscono troppo spesso su altri nodi. I pin IRQ e i worker importanti vengono assegnati ai core adatti, in modo da mantenere la localizzazione della cache. Per un'introduzione più approfondita, si rimanda alla guida compatta Articolo su NUMA, che mi facilita la mappatura di CPU, RAM e carico di lavoro.

Sotto alta Carico Vale la pena di utilizzare cgroups v2 per individuare i vicini rumorosi e garantire tempi di CPU equi. Inoltre, se necessario, controllo le impostazioni di irqbalance e imposto manualmente le affinità. I database traggono vantaggio quando lo scheduler non permette alle transazioni lunghe di competere con le richieste web brevi. Tengo d'occhio il numero di context switch e li riduco attraverso il thread pooling e un numero inferiore di worker. Queste misure stabilizzano le latenze di P95 senza dover installare hardware. rabbocco.

Gestione dell'alimentazione: Turbo, C-States e Governor

Prestazioni e Modalità di risparmio energetico influenzano fortemente la latenza. Di solito seleziono il governatore „performance“ sui percorsi di latenza o imposto un "performance" aggressivo per intel_pstate/amd-pstate. preferenza_di_prestazione_energetica. Sebbene gli stati C bassi limitino il consumo, causano un jitter al risveglio. Limito gli stati C per i lavoratori front-end, mentre i lavori batch possono risparmiare di più. È importante misurare questa scelta: valori migliori di P95 spesso giustificano un consumo energetico leggermente superiore.

Uso il Turbo Boost in modo selettivo, ma tengo d'occhio i limiti di temperatura e potenza. Quando il throttling entra in vigore, la velocità di clock diminuisce proprio durante i picchi di carico. Taglio i limiti di raffreddamento e di potenza in modo che l'host abbia il suo tempo di boost quando è utile alla mia applicazione.

Stack di rete: BIG TCP, GRO e controllo della congestione

La rete offre la massima leva per la realizzazione di più veloce Pagine. BIG TCP aumenta le dimensioni dei segmenti, GRO raggruppa i pacchetti e riduce l'overhead degli interrupt. RFS/XPS distribuisce i flussi in modo sensato tra i core per aumentare le visite alla cache. Negli scenari di traffico ad ampio raggio, prendo una decisione consapevole sul controllo della congestione, in genere CUBIC o BBR. Se volete capire le differenze, potete trovare i dettagli in questa panoramica di Controllo della congestione TCP, che riassume bene gli effetti della latenza.

Inizio con la coerenza sysctl-valori: net.core.rmem_max, net.core.wmem_max, net.core.netdev_max_backlog e tcp_rmem/tcp_wmem. Eseguo quindi un test con MTU identico e lo stesso set di cifratura TLS per confrontare Apple con Apple. Sulle schede multiporta, controllo l'RSS e il numero di code per assicurarmi che tutti i core funzionino. Se gli offload come TSO/GSO causano cadute, li disattivo specificamente per ogni interfaccia. Solo quando vedo curve di misura pulite, estendo la configurazione ad altre interfacce. Ospiti da.

Coalescenza IRQ, Softirq e dettagli del driver

Con una moderata Coalizione IRQ Attenuo la latenza e riduco le tempeste di interruzioni. Inizio in modo conservativo e aumento gradualmente le soglie dei microsecondi e dei pacchetti finché le cadute non diminuiscono ma il P95 non ne risente. Con pacchetti molto piccoli (ad esempio gRPC/HTTP/2), un'eccessiva coalescenza rallenta le cose, quindi do la priorità al tempo di risposta. Monitoro softirq-tempi, cadute di pacchetti e netdev-backlog. Se ksoftirqd mangia costantemente CPU, l'equilibrio tra code RSS, RPS/XPS e coalescenza spesso non è corretto. Uso quindi XPS per distribuire i flussi in modo più preciso ai core che trasportano anche i lavoratori associati.

Controllo le caratteristiche dei driver, come TSO/GSO/GRO e checksum offload per ogni NIC. Alcune schede offrono enormi vantaggi con HW-GRO, altre beneficiano maggiormente di percorsi software. Importante: mantengo il MTU coerente lungo l'intero percorso. Un MTU grande sul server è poco utile se gli switch o i peer lo accorciano.

Percorsi di archiviazione e I/O: dallo scheduler al file system

Molte pagine perdono velocità con I/O, non nella rete. NVMe ha bisogno di uno scheduler I/O adeguato, altrimenti l'host rinuncia al throughput e aumenta i picchi di latenza. Per le configurazioni HDD/ibride, BFQ spesso offre una migliore interattività, mentre mq-deadline fornisce tempi più coerenti con NVMe. Ho testato la profondità delle code, il readahead e le opzioni del file system, come le impostazioni di noatime o barrier. Se siete alla ricerca di informazioni di base, date un'occhiata a questa guida compatta al sistema Schedulatore I/O, che categorizza gli effetti in modo pratico.

Sposto i backup e i cron job in modalità silenziosa. Fasce orarie, in modo che il carico di produzione non si scontri. Se possibile, isolo anche i registri dei database sui miei dispositivi. Per ext4 e XFS, verifico le opzioni di montaggio e controllo le modalità di journal. Uso iostat, blkstat e perf per riconoscere rapidamente i punti caldi. Il risultato sono tempi di risposta più brevi perché il kernel blocca meno e l'applicazione funziona in modo continuo. opere.

controllo io_uring, zero-copy e writeback

Uso core moderni io_uring per i carichi di lavoro di I/O asincrono. I server web, i proxy e le pipeline di dati ne traggono vantaggio perché le chiamate di sistema sono raggruppate e gli scambi di contesto sono ridotti. Quando invio file di grandi dimensioni, utilizzo percorsi a copia zero (sendfile/splice o SO_ZEROCOPY) non appena interagiscono con la strategia TLS e gli offload. Misuro se il carico della CPU diminuisce e se le latenze rimangono stabili con un'elevata concurrency.

Controllo il writeback e la cache delle pagine tramite i parametri vm.dirty_*. Una coda di dirty troppo grande rende le fasi di burst veloci e ritarda i flussaggi; valori troppo piccoli, invece, generano sincronizzazioni frequenti e rallentano le cose. Ho aperto una finestra che corrisponde alla mia configurazione SSD/RAID e ho controllato le latenze di P95 durante le fasi di scrittura intensa.

Messa a punto del server: parametri specifici del kernel

Dopo l'aggiornamento, ho regolato alcuni, ma efficaci, aspetti. Interruttori. Nella rete, inizio con net.core.somaxconn, tcp_fastopen, tcp_timestamps e net.ipv4.ip_local_port_range. Per molte connessioni, un net.core.somaxconn più alto e una coda di arretrati adeguata nel server web aiutano. In memoria, una moderata vm.swappiness riduce gli svuotamenti inappropriati, mentre le hugepages necessitano di test chiari per ogni applicazione. Con gli strumenti htop, psrecord, perf e eBPF, vedo i colli di bottiglia prima dei clienti. memorizzare.

Per la misurazione utilizzo sysbench per CPU, memoria e I/O e confronto la 5.15 con la 6.x con identici Configurazione. Apache Bench e Siege forniscono controlli rapidi: ab -n 100 -c 10, siege -c50 -b. È importante che le condizioni siano riproducibili, ad esempio lo stesso handshake TLS, gli stessi payload, lo stesso stato della cache. Aumento gradualmente la durata e la frequenza dei test fino a trovare i punti di rottura. Poi metto al sicuro i risultati documentando tutte le modifiche e creando percorsi di rollback. tenersi pronti.

TLS, crypto offload e kTLS

Gran parte del tempo della CPU viene impiegato per TLS. Verifico se le mie CPU supportano la crittografia AES-NI/ARMv8 e se i provider OpenSSL la utilizzano. Con un'elevata concurrency, la ripresa della sessione e la pinzatura OCSP portano un notevole sollievo. kTLS riduce l'overhead di copia nel percorso del kernel; verifico se il mio server web/proxy ne beneficia e se la copia zero funziona in modo affidabile con TLS. Importante: mantenere i set di cifratura coerenti in modo che i benchmark siano comparabili.

Osservabilità: eBPF/Perf-Minimo per l'uso quotidiano

Lavoro con un piccolo sistema ripetibile Set di misuraperf stat/record per la profilazione della CPU, tcp- e biolatenza-Strumenti eBPF per la distribuzione di rete/storage, nonché heatmap per la lunghezza delle code di esecuzione. Questo mi permette di scoprire rapidamente se a dominare sono gli errori soft, le syscall, i lock o gli accessi alla memoria. Quando elimino i colli di bottiglia, ripeto lo stesso set per riconoscere gli effetti collaterali. Solo quando le curve della CPU, del NET e dell'IO appaiono pulite, ridimensiono la configurazione.

Valutare correttamente i test di carico

Non controllo solo i valori medi, ma soprattutto P95 e P99. Queste cifre chiave mostrano la frequenza dei tempi di attesa degli utenti. Un tasso di errore crescente indica l'esaurimento dei thread o dei socket. Per quanto riguarda la media del carico, si noti che essa indica le code e non le percentuali di CPU pura. Anche le attese di Aio o del database fanno salire il valore. In alto.

Un test realistico utilizza la stessa strategia di caching della produzione. Inizio a freddo, misuro a caldo e poi registro le fasi più lunghe. L'RPS da solo non mi basta; lo collego alla latenza e agli stati delle risorse. Solo l'immagine complessiva mostra quanto il kernel e i parametri di regolazione lavorino insieme. In questo modo, mi assicuro che i miglioramenti non vengano riconosciuti solo nei benchmark sintetici. brillare.

Virtualizzazione: rubare tempo e spese generali

Rallenta su host condivisi Rubare Il tempo spegne tranquillamente le prestazioni. Monitoro il valore per vCPU e solo allora pianifico la concurrency dei miei servizi. Se il tempo di furto è elevato, passo a istanze dedicate o aumento la priorità del guest. Nell'hypervisor, distribuisco le vCPU in modo coerente ai nodi NUMA e fisso gli IRQ delle NIC importanti. Non riduco ciecamente i container, ma ottimizzo i limiti in modo che il kernel possa prendere decisioni CFS in modo pulito. incontrarsi può.

Le NIC virtuali come virtio-net traggono vantaggio dalle più moderne Autisti e code sufficienti. Verifico anche se vhost-net è attivo e se l'MTU è sempre corretto. Per quanto riguarda lo storage, controllo le opzioni di paravirt e la profondità delle code. In caso di densità elevata, aumento la frequenza di monitoraggio in modo da notare più rapidamente i picchi. Tutto ciò impedisce che le buone funzionalità del kernel vadano perse nell'overhead della virtualizzazione. sabbia.

Carichi di lavoro dei container: Utilizzare correttamente Cgroup v2

Per i microservizi mi affido a cgroup v2-Controlli: cpu.max/cpu.weight controllano l'equità, memory.high protegge l'host dalle tempeste di evacuazioni e io.max limita le scritture che interferiscono. Con cpuset.cpus e cpuset.mems mantengo i percorsi di latenza vicini a NUMA. Documento i limiti per ogni classe di servizio (web, DB, cache) e mantengo lo spazio libero in modo che non si verifichino effetti a cascata se un servizio ha bisogno di più per un breve periodo.

Scelta della distro: cadenza e supporto del kernel

La distribuzione determina la velocità con cui Kernel-Gli aggiornamenti sono disponibili e quanto tempo impiegano le correzioni ad arrivare. Debian e Rocky/Alma forniscono pacchetti a lunga manutenzione, ideali per configurazioni tranquille con cambiamenti prevedibili. Ubuntu HWE offre kernel più giovani, che rendono i driver e le funzionalità utilizzabili prima. Gentoo consente una regolazione fine del set di istruzioni, che può offrire vantaggi per host speciali. Decido in base al profilo del carico di lavoro, alle finestre di aggiornamento e ai requisiti del mio computer. Clienti.

Un aggiornamento prudente inizia su host di staging con hardware identico. Controllo le fonti dei pacchetti, l'avvio sicuro e i moduli DKMS come ZFS o i driver NIC speciali. Poi correggo le versioni del kernel con il pinning per evitare salti inattesi. Pianifico le finestre di manutenzione e cancello i rollback per i sistemi produttivi. In questo modo combino le nuove funzionalità con l'alta Pianificabilità.

Aspetti di sicurezza e manutenzione senza perdita di velocità

Le patch di sicurezza potrebbero non Prestazioni non hanno un impatto duraturo. Utilizzo il live patching dove disponibile e verifico l'influenza di mitigazioni come spectre_v2 o retpoline. Alcuni host guadagnano notevolmente quando disattivo selettivamente funzioni che non apportano alcun valore aggiunto in un contesto specifico. Tuttavia, la sicurezza rimane un obbligo, ed è per questo che prendo decisioni consapevoli e documento le eccezioni. Ogni profilo di host deve avere una linea chiara tra rischio e sicurezza. Velocità.

Completo gli aggiornamenti regolari del kernel con test di regressione. Salvo i profili di prestazione prima e dopo l'aggiornamento e confronto i punti caldi. In caso di anomalie, faccio un rollback o uso versioni minori alternative della stessa serie. Mantengo il logging snello in modo che non diventi un collo di bottiglia sotto carico. In questo modo, la disponibilità, la sicurezza e le prestazioni rimangono pulite. Equilibrio.

Breve sintesi e piano d'azione

Sollevare il kernel 6.x corrente Rete e la pianificazione; i miei primi passi sono BIG TCP, GRO, RFS/XPS e valori sysctl puliti. Poi assicuro la vicinanza della CPU usando l'affinità IRQ e la mappatura NUMA e seleziono lo scheduler I/O appropriato per lo storage. Con l'aiuto di ab, Siege e sysbench, verifico il profitto confrontando RPS con P95/P99. Se la curva è pulita, eseguo il roll-out della configurazione e della versione del kernel in modo controllato. In questo modo riduco la latenza, aumento il throughput e mantengo i tempi di risposta al di sotto di tre. Secondi.

La mia tabella di marcia pratica è: 1) Aggiornare a 6.8+ o 6.11 con i driver adatti. 2) Regolare lo stack di rete e selezionare il controllo della congestione appropriato. 3) Organizzare CPU/NUMA e IRQ, quindi testare le code di archiviazione e le opzioni del file system. 4) Ripetere i test di carico con parametri identici, modifiche alla versione e al documento. Chi procede in questo modo utilizza Linux Le innovazioni del kernel sono costanti e permettono di ottenere risultati sorprendenti dall'hardware esistente.