{"id":20778,"date":"2026-08-18T18:23:16","date_gmt":"2026-08-18T16:23:16","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-latenz-messen-und-optimieren-performance\/"},"modified":"2026-08-18T18:23:16","modified_gmt":"2026-08-18T16:23:16","slug":"misurare-la-latenza-dello-scheduler-di-linux-e-ottimizzare-le-prestazioni","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-scheduler-latenz-messen-und-optimieren-performance\/","title":{"rendered":"Misurare e ottimizzare la latenza dello scheduler di Linux per migliorare le prestazioni del kernel"},"content":{"rendered":"<p>Misuro la latenza del <strong>Scheduler di Linux<\/strong> in modo mirato, analizzo i valori anomali e ottimizzo i parametri fino a quando i carichi di lavoro interattivi e in tempo reale non rispondono in modo affidabile. In questo modo riduco sistematicamente la latenza dello scheduler e aumento la <strong>Prestazioni del kernel<\/strong> senza volare alla cieca.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Metodi di misurazione<\/strong>: perf sched, eBPF runqlat, schedstat e cyclictest offrono una visione completa.<\/li>\n  <li><strong>Il caso peggiore<\/strong>: I valori anomali influenzano l'esperienza dell'utente e le scadenze in tempo reale.<\/li>\n  <li><strong>Parametri CFS<\/strong>: sched_latency_ns e le finestre temporali determinano i tempi di risposta.<\/li>\n  <li><strong>Politiche<\/strong>: SCHED_FIFO\/RR\/DEADLINE danno priorit\u00e0 ai thread critici.<\/li>\n  <li><strong>Isolamento<\/strong>: Il pinning della CPU e l'ottimizzazione degli IRQ stabilizzano le latenze.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-performance-2349.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa significa \"latenza dello scheduler\" nel kernel<\/h2>\n\n<p>Definisco la latenza dello scheduler come il tempo che intercorre tra il <strong>Svegliare<\/strong> di un\u2019attivit\u00e0 e il momento in cui il suo codice viene eseguito dopo il cambio di contesto. Un interrupt interrompe una fase di attesa I\/O, l\u2019handler contrassegna il thread come eseguibile, lo scheduler effettua la selezione e avvia il cambio. Per i sistemi interattivi ogni microsecondo conta, ma nella vita quotidiana \u00e8 soprattutto la <strong>Il caso peggiore<\/strong>-La latenza influisce sulla percezione. Anche poche centinaia di millisecondi compromettono l'esperienza d'uso, pur se il valore medio sembra buono. Proprio per questo motivo prendo in esame l'intera catena all'interno del kernel, concentrandomi per\u00f2 sulla sezione compresa tra il wakeup e l'ingresso in CPU.<\/p>\n\n<h2>Perch\u00e9 la latenza nel caso peggiore \u00e8 importante<\/h2>\n\n<p>Non valuto solo i valori medi, perch\u00e9 una media bassa pu\u00f2 nascondere valori elevati <strong>Suggerimenti<\/strong> pu\u00f2 mascherare. L'audio produce rumori quando picchi sporadici svuotano i buffer, e il trading perde il tempismo quando le scadenze vengono superate. Per desktop, server e tempo reale vale quanto segue: pochi valori anomali determinano il <strong>Reattivit\u00e0<\/strong> pi\u00f9 efficace di migliaia di campioni di buona qualit\u00e0. Per questo motivo punto a distribuzioni ristrette e valori di jitter controllati. Solo quando i valori massimi diminuiscono si ottiene un andamento fluido e prevedibile.<\/p>\n\n<h2>Misurazione della latenza dello scheduler: strumenti e procedura<\/h2>\n\n<p>Inizio con <strong>perf<\/strong> e registro gli eventi dello scheduler in base al carico di lavoro: \u201eperf sched record\u201c raccoglie i dati, \u201eperf sched latency\u201c li ordina per task, \u201eperf sched timehist\u201c mostra gli eventi con i timestamp. In questo modo posso visualizzare il tempo di attesa dallo \u201esched-out\u201c allo \u201esched-in\u201c, il ritardo tra il risveglio e l\u2019effettiva esecuzione, nonch\u00e9 il tempo di esecuzione effettivo. Per un\u2019analisi dettagliata della CPU, combino questi comandi con questa guida: <a href=\"https:\/\/webhosting.de\/it\/strumento-linux-perf-analisi-dei-colli-di-bottiglia-della-cpu-ottimizzazione-carico-del-server-profilazione\/\">perf per i colli di bottiglia della CPU<\/a>. Questa prospettiva mette in luce i colli di bottiglia e consente di stabilire se la causa sia da ricercarsi in contenzioni, priorit\u00e0 o overhead.<\/p>\n\n<p>Con eBPF misuro i tempi di esecuzione e di attesa direttamente nel <strong>Runqueue<\/strong>. Il consueto \u201erunqlat\u201c genera istogrammi con incrementi di nanosecondi, consentendomi di individuare zone tipiche e picchi rari. Tali distribuzioni reagiscono in modo evidente all\u2019isolamento della CPU o ai cambiamenti di policy, fornendo cos\u00ec prove concrete per le operazioni di ottimizzazione. Ripeto le misurazioni prima e dopo le modifiche, finch\u00e9 i picchi non scompaiono. Solo allora considero il risultato soddisfacente.<\/p>\n\n<p>Per le singole attivit\u00e0, consulto \u201e\/proc\/\/schedstat\u201c e confronto le percentuali di tempo di esecuzione della CPU, <strong>Runqueue<\/strong>-Tempi di attesa e fasi di sospensione. I dati, rilevati a intervalli regolari, forniscono valori indicativi quali percentuale di utilizzo della CPU, percentuale di latenza e percentuale di sospensione. In questo modo riesco a capire rapidamente se il processo sta lottando per ottenere tempo di CPU o se \u00e8 bloccato a causa di un collo di bottiglia nell\u2019I\/O. Questa chiarezza impedisce ottimizzazioni errate che agiscono sulla leva sbagliata. Come test aggiuntivo utilizzo cyclictest con priorit\u00e0 elevata per documentare il jitter e i valori massimi.<\/p>\n\n<h2>Lettura e interpretazione dei valori misurati<\/h2>\n\n<p>Valuto innanzitutto i dati rilevati dal punto di vista qualitativo: dove si concentrano i tempi di attesa e quali thread ricorrono ripetutamente con <strong>Picchi<\/strong> . Successivamente verifico se sono dovuti a limiti della CPU, conflitti di policy o picchi di interrupt. Mantengo il tempo di campionamento abbastanza lungo da rilevare eventi rari, ma abbastanza breve da poter analizzare i cambiamenti in modo isolato. I valori nell\u2019ordine dei microsecondi vanno bene nell\u2019uso quotidiano, ma i carichi di lavoro in tempo reale richiedono talvolta intervalli ancora pi\u00f9 ristretti. Ci\u00f2 che conta \u00e8 che la latenza massima diminuisca in modo affidabile e che il jitter si riduca.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxscheduler_9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Parametri dello scheduler di Linux che influenzano la latenza<\/h2>\n\n<p>Per prima cosa regolo la latenza target \u201esched_latency_ns\u201c, che definisce l\u2019intervallo di tempo entro il quale tutte le attivit\u00e0 pronte per l\u2019esecuzione <strong>CPU<\/strong>-Tempo. In molti processi, l'intervallo di tempo per ogni task si riduce, mentre in alcuni casi aumenta; ci\u00f2 garantisce l'equit\u00e0, ma pu\u00f2 influire sui tempi di risposta. Per le applicazioni interattive, lo riduco moderatamente per favorire tempi di risposta brevi, ma tengo d\u2019occhio l\u2019overhead. Il CFS distribuisce i tempi in modo equo, ma i carichi di lavoro con thread critici traggono vantaggio da priorit\u00e0 ben definite. Riassumo qui le nozioni di base sulla pianificazione equa nel contesto dell\u2019hosting: <a href=\"https:\/\/webhosting.de\/it\/cfs-scheduler-scheduling-equo-hosting\/\">Comprendere lo scheduler CFS<\/a>.<\/p>\n\n<p>Oltre alla latenza e ai quanti, influiscono anche la granularit\u00e0 del wakeup e la logica di migrazione su <strong>Suggerimenti<\/strong>. Le migrazioni troppo aggressive compromettono la localit\u00e0 della cache e, indirettamente, aumentano i tempi di attesa. Riduco gli spostamenti superflui, fisso gli hot thread e mantengo i dati vicini ai loro core. Negli ambienti NUMA questo vale doppio, poich\u00e9 le distanze di memoria aumentano le latenze. L\u2019obiettivo rimane un campo di scheduling stabile e prevedibile.<\/p>\n\n<h2>Utilizzare con intelligenza le politiche, le priorit\u00e0 e le scadenze<\/h2>\n\n<p>Assegno ai thread critici <strong>SCHED_FIFO<\/strong> oppure la priorit\u00e0 SCHED_RR, quando la latenza ha la precedenza sulla velocit\u00e0 di trasmissione. Con SCHED_DEADLINE posso garantire con precisione le risorse in base a periodi, durata di esecuzione e scadenza, assicurando il rispetto di scadenze rigide. Utilizzo queste politiche con parsimonia, affinch\u00e9 il sistema non rimanga a corto di risorse. Calibro le priorit\u00e0 finch\u00e9 non passano solo i percorsi davvero essenziali. Una guida pratica alle priorit\u00e0 \u00e8 disponibile qui: <a href=\"https:\/\/webhosting.de\/it\/schedulazione-dei-processi-server-priorita-ottimizzazione-serverboost\/\">Priorit\u00e0 procedurali<\/a>.<\/p>\n\n<p>Controllo regolarmente se si verificano conflitti tra le policy, ad esempio quando i processi in background richiedono una maggiore <strong>Prio<\/strong> come thread di interazione. Anche i parametri relativi alle scadenze richiedono un dimensionamento accurato, altrimenti si creano nuovi ingorghi. Le prove con carichi di lavoro reali garantiscono la correttezza della scelta. Documento ogni modifica e ne verifico i risultati, affinch\u00e9 gli effetti rimangano tracciabili. In questo modo evito effetti collaterali durante il funzionamento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/LinuxSchedulerOptimierung4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Isolamento della CPU, pinning e NUMA: stabilizzare le latenze<\/h2>\n\n<p>Separo i thread critici dal carico generale isolando le CPU dedicate ed escludendo i servizi di sistema, dove \u00e8 richiesta una bassa <strong>Latenza<\/strong> \u00e8 necessario. Il CPU-pinning mantiene gli hot path su core fissi e protegge la localit\u00e0 della cache. Nelle configurazioni NUMA, associo i thread ai banchi di memoria locali per evitare accessi superflui tra i nodi. Queste misure riducono sensibilmente gli effetti di jitter. Il miglioramento \u00e8 immediatamente evidente negli istogrammi eBPF pi\u00f9 stretti.<\/p>\n\n<p>La distribuzione degli IRQ ne fa parte: devio gli interrupt fastidiosi dai core a bassa latenza, alleggerendo cos\u00ec il carico <strong>Caldo<\/strong>-Thread. MSI-X e le affinit\u00e0 aiutano a regolare con precisione la distribuzione. Ove possibile, utilizzo gli IRQ multithread in modo che gli ISR completino il lavoro pi\u00f9 rapidamente. Tutto ci\u00f2 crea margine per l'esecuzione in cui il tempo \u00e8 un fattore critico. Le misurazioni effettuate con perf e cyclictest confermano questo effetto.<\/p>\n\n<h2>Ottimizzazione di interrupt, driver e preemption<\/h2>\n\n<p>Sposto le parti che richiedono un'elevata potenza di calcolo dall'ISR a code di lavoro a valle, in modo che lo scheduler sia pi\u00f9 veloce <strong>commutare<\/strong> posso. Suddivido i segmenti critici pi\u00f9 lunghi nel kernel in modo da creare punti di preemptione pi\u00f9 frequenti. Disattivo le funzionalit\u00e0 superflue del kernel e i driver pesanti se aumentano le latenze. Per il tempo reale rigoroso utilizzo PREEMPT_RT, mentre per un carico di lavoro server esteso spesso \u00e8 sufficiente PREEMPT con una buona configurazione. \u00c8 importante misurare accuratamente ogni ottimizzazione, invece di affidarsi a supposizioni.<\/p>\n\n<p>Sto verificando se le risoluzioni del timer e le opzioni di tick siano adeguate al carico di lavoro, poich\u00e9 i tick approssimativi <strong>Jitter<\/strong> possono migliorare le prestazioni. A ci\u00f2 si aggiunge la gestione dell\u2019energia: gli stati C profondi allungano i tempi di riattivazione e possono causare picchi di latenza. Con impostazioni del governor ottimizzate riesco a trovare un compromesso valido. Alla fine ci\u00f2 che conta \u00e8 la coerenza dei valori misurati, non il nome di un\u2019opzione. Un percorso stabile \u00e8 preferibile a una singola impostazione aggressiva.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_scheduler_performance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Passaggi pratici per la messa a punto con valori di esempio<\/h2>\n\n<p>Comincio con una misurazione di base e modifico solo un <strong>Parametri<\/strong> per ogni ciclo, per rilevare la causalit\u00e0. Successivamente, vari\u00f2 il valore di `sched_latency_ns` a piccoli incrementi, osservo i valori massimi e il jitter e documento gli effetti. Se necessario, blocco i thread critici e sposto gli IRQ, effettuo nuove misurazioni e registro i picchi. Laddove le policy lo consentono, passo in modo mirato a FIFO\/RR o DEADLINE. La tabella seguente mette a confronto le opzioni pi\u00f9 comuni con i relativi effetti e effetti collaterali:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Opzione\/Meccanica<\/th>\n      <th>Effetto previsto sulla latenza<\/th>\n      <th>Possibili effetti collaterali<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sched_latency_ns<\/strong> abbassare<\/td>\n      <td>Tempi di attesa pi\u00f9 brevi per l'accesso alla CPU<\/td>\n      <td>Maggiore sovraccarico di pianificazione<\/td>\n      <td>Piccoli passi, misurare l'impatto<\/td>\n    <\/tr>\n    <tr>\n      <td>Regolare la granularit\u00e0 del wakeup<\/td>\n      <td>Ripresa pi\u00f9 rapida dopo il riattivazione<\/td>\n      <td>Preemptioni pi\u00f9 frequenti<\/td>\n      <td>Regolare solo moderatamente<\/td>\n    <\/tr>\n    <tr>\n      <td>Pinning\/isolamento della CPU<\/td>\n      <td>Pi\u00f9 stabile <strong>Picchi<\/strong> e meno jitter<\/td>\n      <td>Minore flessibilit\u00e0<\/td>\n      <td>Considerare le affinit\u00e0 IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td>SCHED_FIFO\/RR<\/td>\n      <td>Design preferito<\/td>\n      <td>Esclusione di altre attivit\u00e0<\/td>\n      <td>Solo per i percorsi critici<\/td>\n    <\/tr>\n    <tr>\n      <td>PREEMPT_RT<\/td>\n      <td>Bassa latenza nel caso peggiore<\/td>\n      <td>Maggiori cambiamenti di contesto<\/td>\n      <td>Sono necessari driver compatibili con RT<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Convalido le modifiche utilizzando perf timehist e gli istogrammi eBPF fino a quando la <strong>Distribuzione<\/strong> e il valore massimo rimane prudente. Se gli effetti sono contrastanti, faccio un passo indietro e provo una combinazione alternativa. Ogni ambiente reagisce in modo leggermente diverso, quindi \u00e8 fondamentale sperimentare con cura. Con benchmark coerenti dimostro oggettivamente i benefici. In questo modo si crea un processo di messa a punto ripetibile.<\/p>\n\n<h2>Contesto dell'hosting e dei server: ridurre efficacemente la latenza<\/h2>\n\n<p>Nel settore dell'hosting, una regolazione accurata dello scheduler riduce i tempi di risposta per i siti web e <strong>DB<\/strong>-Richieste. Molti processi simultanei traggono vantaggio dalla riduzione dei tempi di attesa nella Runqueue e dall\u2019eliminazione dei picchi. Gli stack di container e microservizi acquisiscono maggiore uniformit\u00e0 non appena ai servizi critici vengono assegnate priorit\u00e0 e vicinanza alla CPU. Chi sceglie un fornitore deve prestare attenzione a kernel aggiornati, una preclusione ragionevole e un controllo flessibile di IRQ e CPU. Una minore latenza si riflette direttamente sul fatturato e sull\u2019esperienza utente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-performance-optimierung-4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funzionalit\u00e0 moderne del kernel che influenzano la latenza<\/h2>\n\n<p>I kernel pi\u00f9 recenti introducono meccanismi che influenzano direttamente i tempi di risposta. Nelle versioni pi\u00f9 recenti, il CFS \u00e8 stato dotato di euristiche perfezionate per i wakeup e le espulsioni, che privilegiano i carichi interattivi. Attributi come un <strong>Preferenza di veglia-latenza<\/strong> per ogni thread, contribuisce a far passare pi\u00f9 rapidamente i percorsi importanti senza abusare delle politiche RT. Inoltre, controlla <strong>uclamp<\/strong> (limitazione dell'utilizzo) l'utilizzo minimo e massimo della CPU, impostato dal pianificatore, per ogni task o cgroup. In questo modo impongo un limite minimo di potenza di calcolo per i thread sensibili alla latenza, il che influenza il regolatore di frequenza e l'assegnazione ai core attivi.<\/p>\n\n<p>Per i sistemi con pochi tick utilizzo <strong>NOHZ_FULL<\/strong> in combinazione con CPU dedicate alle attivit\u00e0 di housekeeping. Ci\u00f2 sposta le operazioni periodiche del kernel lontano dai core a bassa latenza. Inoltre, alleggerisco il carico di questi core tramite <code>rcu_nocbs<\/code>, in modo che i callback non li facciano perdere il ritmo. Entrambe le misure riducono le preemptioni nei momenti meno opportuni e stabilizzano i valori nel caso peggiore.<\/p>\n\n<p>Con <strong>PSI<\/strong> (Informazioni sullo stall da pressione) misuro la pressione di sistema su CPU, memoria e I\/O. Gli indicatori in <code>\/proc\/pressure\/*<\/code> mostrano se i thread sono bloccati a causa della mancanza di risorse. Se il valore CPU-PSI aumenta parallelamente ai tempi di attesa della coda di esecuzione, ci\u00f2 costituisce un chiaro indizio di un vero e proprio sovraccarico o di un controllo delle quote troppo restrittivo.<\/p>\n\n<h2>Cgroups, container ed equit\u00e0: isolamento senza overhead<\/h2>\n\n<p>Negli ambienti container, i cgroup sono lo strumento fondamentale per garantire una latenza prevedibile. Io utilizzo <strong>cpu.weight<\/strong>, per garantire una certa equit\u00e0, e utilizza <strong>cpu.max<\/strong>, per limitare drasticamente i servizi in background che causano disturbi. Ai servizi critici non viene assegnata una quota di CPU ristretta, in modo che non <em>limitare<\/em> e vengono suddivisi in intervalli di tempo. Per garantire la vicinanza alla CPU, separo i cpuset: un gruppo di core per l'interazione, un gruppo per l'elaborazione in batch. Questo isolamento \u00e8 pi\u00f9 efficace del semplice nice-leveling.<\/p>\n\n<p>Sulle piattaforme con orchestrazione, evito che pi\u00f9 pod sensibili alla latenza condividano lo stesso core fisico. Riservo i core <em>esclusivo<\/em> e associo gli IRQ corrispondenti in modo coerente. Misuro le variazioni nella gerarchia dei cgroup tramite eBPF utilizzando filtri cgroup, in modo da poter visualizzare i tempi di attesa nella runqueue per ciascun servizio. In questo modo riesco a capire se la causa effettiva dei picchi \u00e8 la distribuzione del carico o le quote.<\/p>\n\n<h2>Virtualizzazione e SMT: rilevare e attenuare il rumore dell'host<\/h2>\n\n<p>Nelle macchine virtuali faccio attenzione a <strong>Rubare tempo<\/strong>: Indica quando l'hypervisor sottrae tempo di CPU al sistema ospite. Se perf rileva percorsi ottimali, ma l'app \u00e8 a scatti, spesso il colpevole \u00e8 lo \"steal time\". Per risolvere il problema basta <em>Assegnazione fissa delle vCPU<\/em> su pCPU dedicate, tassi di overcommitment ridotti e separazione dei thread I\/O su core dedicati. Per una latenza costante, prevedo pCPU = vCPU; in caso contrario, lo scenario peggiore \u00e8 difficilmente calcolabile.<\/p>\n\n<p>Con <strong>SMT<\/strong> (Hyper-Threading) condivido le risorse del core con un core gemello. Per questo motivo, indirizzo i percorsi di latenza verso i core i cui gemelli sono liberi, oppure utilizzo le opzioni di core scheduling che limitano le interferenze tra i core. In caso di obiettivi molto ambiziosi, disattivo l\u2019SMT in modo selettivo per i core critici. Il vantaggio deriva da una minore competizione a livello di porte, cache e unit\u00e0 di esecuzione.<\/p>\n\n<h2>Percorsi di memoria, I\/O e di rete: fonti nascoste di latenza<\/h2>\n\n<p>La latenza dello scheduler spesso sembra un problema legato alla CPU, ma in realt\u00e0 \u00e8 <strong>Reclaim<\/strong> oppure <strong>Compattazione<\/strong>. Il reclaim diretto interrompe i thread e genera picchi prolungati. Mantengo i pool di pagine libere a un livello sufficientemente alto e scelgo un valore moderato <code>vm.swappiness<\/code>, in modo che gli accessi alla memoria non vengano compromessi da intensi swap. Calibro le Transparent Huge Pages in modo prudente: se il kernel comprime le pagine di grandi dimensioni in un momento inopportuno, si verificano delle interruzioni; con <em>madvise<\/em> Posiziono i THP dove garantiscono un buon rendimento senza interferire con l'interazione.<\/p>\n\n<p>Anche gli intervalli di writeback e di commit del journal influenzano le interazioni. Limiti di dati non salvati troppo elevati spostano il carico di lavoro in fasi sfavorevoli; limiti troppo bassi costringono a frequenti picchi di flushing. Io dimensiono in byte anzich\u00e9 in percentuale e distribuisco le operazioni di scrittura in modo che le fasi di attivit\u00e0 della CPU non coincidano con i picchi di I\/O.<\/p>\n\n<p>Nel percorso di rete visualizzo <strong>SoftIRQ<\/strong>, budget NAPI e raggruppamento dei pacchetti. Un GRO troppo aggressivo riduce l\u2019overhead per pacchetto, ma pu\u00f2 aumentare la latenza interattiva. RPS\/RFS distribuiscono bene il carico, ma devono essere compatibili con le affinit\u00e0 IRQ e CPU. L\u2019obiettivo \u00e8 che i pacchetti vengano elaborati proprio dove \u00e8 in esecuzione il thread dell\u2019applicazione, senza dover prima passare attraverso diversi core.<\/p>\n\n<h2>Trovare il giusto equilibrio tra limitazione della velocit\u00e0 di trasmissione (RT-Throttling), scadenze e meccanismi di protezione<\/h2>\n\n<p>Il sito <strong>Limitazione della velocit\u00e0 di trasmissione RT<\/strong> protegge il sistema dal \u201chunger\u201d, ma limita efficacemente il carico RT a una parte del tempo di CPU. Per ottenere tempi di risposta deterministici, aumento <code>kernel.sched_rt_runtime_us<\/code> oppure disattivo il limite in ambienti accuratamente isolati. A quel punto verifico costantemente se i thread non RT ricevono ancora un numero sufficiente di finestre. Altrettanto importanti sono le variabili globali <strong>Scadenza<\/strong>-Contingenti: se sono impostati in modo troppo restrittivo, le attivit\u00e0 DEADLINE non rientrano nelle finestre previste nonostante i parametri siano corretti. Verifico il rapporto tra <em>runtime<\/em> a <em>periodo<\/em> e il totale di tutte le prenotazioni DEADLINE per ciascuna CPU.<\/p>\n\n<h2>Progettazione degli strumenti di misura, protezione contro la regressione e funzionamento<\/h2>\n\n<p>Distinguo rigorosamente le fasi di misurazione: riscaldamento, riferimento, variazione, verifica. Le cache fredde falsano i risultati; misuro le fasi stabilizzate e le metto in correlazione con i dati Perf ed eBPF. I confronti A\/B vengono eseguiti con carichi di lavoro identici, durata identica e affinit\u00e0 fisse. Scelgo finestre di campionamento sufficientemente ampie da far emergere statisticamente i picchi rari, ma abbastanza piccole da consentire una valutazione isolata delle singole fasi di ottimizzazione.<\/p>\n\n<p>Per il funzionamento continuo, definisco una <strong>SLO<\/strong> per latenza e jitter: circa il quantile 99,9% al di sotto di X microsecondi con un carico Y. La telemetria proveniente da PSI, le statistiche perf e gli istogrammi eBPF fungono da sistema di monitoraggio; se le metriche superano le soglie, passo automaticamente a profili conservativi. Ogni modifica viene registrata in un changelog con versione del kernel, parametri, metodi di misurazione, dati grezzi e interpretazione. In questo modo l\u2019ottimizzazione rimane riproducibile e il rollback \u00e8 possibile in qualsiasi momento.<\/p>\n\n<ul>\n  <li>Creazione della linea di base: perf, eBPF, schedstat, cyclictest<\/li>\n  <li>Identificare il collo di bottiglia: CPU, IRQ, I\/O, memoria, policy<\/li>\n  <li>Una modifica per ogni ciclo: parametri, pinning, policy, isolamento<\/li>\n  <li>Misurazione prima\/dopo: valore medio, quantile 99% e 99,9%, massimo<\/li>\n  <li>Verifica della stabilit\u00e0: sessioni prolungate, carichi di lavoro reali, picchi di carico<\/li>\n  <li>Documentazione e conservazione: profili, valori limite, piano di intervento in caso di ricaduta<\/li>\n<\/ul>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Misuro la latenza dello scheduler con <strong>perf<\/strong>, eBPF, schedstat e cyclictest, prima di modificare qualsiasi impostazione. Successivamente, riduco con cautela la latenza target, calibro le policy e isolo i thread critici tramite pinning e affinit\u00e0 IRQ. Definisco driver, ripartizione degli ISR e preemption in modo tale da ridurre i picchi nel caso peggiore e ridurre al minimo il jitter. Convalido ogni modifica con misurazioni ripetute, finch\u00e9 le curve non risultano convincenti. In questo modo aumento la <strong>Kernel<\/strong>- Offre prestazioni sostenibili e garantisce risultati affidabili per desktop, server e carichi di lavoro in tempo reale.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guida pratica su come misurare e ottimizzare la latenza dello scheduler di Linux per migliorare le prestazioni del kernel. Focus: latenza dello scheduler in Linux per una gestione precisa della CPU e tempi di risposta stabili del server.<\/p>","protected":false},"author":1,"featured_media":20771,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20778","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"173","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux Scheduler","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20771","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20778","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20778"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20778\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20771"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}