{"id":18553,"date":"2026-03-30T15:05:26","date_gmt":"2026-03-30T13:05:26","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/"},"modified":"2026-03-30T15:05:26","modified_gmt":"2026-03-30T13:05:26","slug":"scheduler-linux-cfs-hosting-alternativo-kernelperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/","title":{"rendered":"Linux Scheduler CFS: funzionalit\u00e0 e alternative nell'hosting di server"},"content":{"rendered":"<p>Lo scheduler CFS di Linux controlla il modo in cui i core del server assegnano il loro tempo ai processi e quindi influenza direttamente la latenza, il throughput e l'equit\u00e0 nell'hosting dei server. In questa guida vi spiego come funziona, le leve di regolazione e le alternative utili come ULE, BFS ed EEVDF per <strong>Ospitare<\/strong> con <strong>server web<\/strong>.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Equit\u00e0<\/strong> e <strong>vruntime<\/strong> determinare quale compito riceve la CPU.<\/li>\n  <li><strong>Gruppi C<\/strong> regolamentare le quote e <strong>cpu.shares<\/strong> per l'isolamento dei clienti.<\/li>\n  <li><strong>Messa a punto del kernel<\/strong> tramite sched_latency_ns e <strong>Granularit\u00e0<\/strong>.<\/li>\n  <li><strong>Alternative<\/strong> come BFS, ULE, EEVDF per le applicazioni speciali. <strong>Carichi di lavoro<\/strong>.<\/li>\n  <li><strong>Pratica<\/strong>Affinit\u00e0 del nucleo, pianificatore I\/O e <strong>Test<\/strong> combinare.<\/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\/03\/linux-server-cfs-9357.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come funziona la CFS nella vita quotidiana<\/h2>\n\n<p>Con il Completely Fair Scheduler, un runtime virtuale decide quale task deve essere eseguito successivamente, con il risultato di una <strong>equo<\/strong> e prevedibile <strong>Assegnazione<\/strong> viene creato. Ogni task riceve tempo di CPU proporzionale al valore nice, in modo che un valore nice basso riceva pi\u00f9 condivisioni. Negli ambienti di hosting, molte piccole richieste web, cronjob e backup dividono la CPU tra loro senza che un processo occupi tutto. I carichi di lavoro interattivi, come le richieste NGINX, beneficiano di fette di tempo frequenti e brevi, mentre le attivit\u00e0 batch ricevono blocchi pi\u00f9 lunghi. Ci\u00f2 significa che i tempi di risposta rimangono affidabili per gli utenti, anche se molti siti elaborano le richieste in parallelo.<\/p>\n\n<p>Uso i Cgroup per limitare i clienti e i servizi, perch\u00e9 cpu.shares e cpu.max assicurano la chiarezza <strong>Totale delle azioni<\/strong> e duro <strong>Limiti<\/strong>. Un valore predefinito di 1024 azioni per \u201cnormale\u201d e 512 per \u201cmeno importante\u201d distribuisce i core in modo comprensibile. Con cpu.max, ad esempio, ho impostato 50ms in un periodo di 100ms, che corrisponde effettivamente a 50% di CPU. Questa configurazione offre riserve prevedibili per ospitare carichi di lavoro variabili. Una spiegazione compatta del principio si trova su <a href=\"https:\/\/webhosting.de\/it\/cpu-scheduling-hosting-distribuzione-equa-server-hosting-risorse-ottimale\/\">distribuzione equa della CPU<\/a>.<\/p>\n\n<h2>La meccanica della CFS spiegata in modo chiaro<\/h2>\n\n<p>Nel suo nucleo, CFS gestisce tutti i task pronti per l'esecuzione in un albero rosso\/nero, ordinati in base a <strong>vruntime<\/strong> e con un efficiente <strong>Selezione<\/strong> del runtime virtuale pi\u00f9 piccolo. Questo task viene eseguito successivamente e aumenta il suo vruntime in proporzione al tempo di CPU consumato e ponderato tramite il valore nice. In questo modo si crea un equilibrio fluido senza code rigide, che offre risultati puliti, soprattutto con carichi di lavoro misti. Sui sistemi multi-core, lo scheduler sposta i task tra le code di esecuzione, ma presta attenzione alla localizzazione della cache tramite l'affinit\u00e0 dei core. In questo modo, CFS combina il bilanciamento del carico con il minor numero possibile di migrazioni costose.<\/p>\n\n<p>Per la regolazione fine, parametri come sched_latency_ns e sched_min_granularity_ns impostano il percorso per <strong>Latenza<\/strong> e <strong>Produttivit\u00e0<\/strong>. I valori di latenza pi\u00f9 piccoli favoriscono i lavori brevi e interattivi, mentre quelli pi\u00f9 grandi rafforzano i lavori batch. Nei test con strumenti come stress-ng e fio, verifico l'effetto sui tempi di risposta e sull'utilizzo della CPU. Con l'aumentare del numero di task, aumenta anche l'overhead amministrativo dell'albero, che pu\u00f2 manifestarsi con picchi di latenza. Tuttavia, le quote e i limiti impostati correttamente tengono sotto controllo questi effetti negli ambienti di hosting.<\/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\/03\/linux_scheduler_cfs_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Punti di forza di CFS nell'hosting di server<\/h2>\n\n<p>La forza maggiore risiede nella <strong>Equit\u00e0<\/strong>, in modo uniforme e comprensibile <strong>Risorse<\/strong> distribuito. Per gli ambienti condivisi, ci\u00f2 significa che nessun cliente ne sostituisce altri in modo permanente, perch\u00e9 le quote e le condivisioni definiscono chiaramente le ponderazioni. I servizi interattivi ricevono tempi di risposta rapidi, mentre i backup possono essere eseguiti senza fretta. La prioritizzazione tramite valori piacevoli completa questo quadro e mi lascia spazio per il coordinamento a seconda del ruolo di un servizio. Il bilanciamento del carico su tutti i core mi permette di fare un buon uso della potenza di calcolo disponibile senza dare troppo spazio ai momenti di Jeff dei singoli thread.<\/p>\n\n<p>In pratica, la forza di CFS diventa evidente quando si verificano i picchi del server web e arrivano molte richieste brevi, poich\u00e9 CFS assegna slot frequenti a questo tipo di attivit\u00e0. I gruppi C puliti aiutano a stabilire limiti massimi rigidi per cliente o contenitore. Le misurazioni delle medie e dei percentili mostrano tempi di risposta affidabili, che si rivelano utili nelle attivit\u00e0 quotidiane. Questo approccio \u00e8 particolarmente utile per gli stack di applicazioni con molti componenti. \u00c8 proprio in questi casi che il mix di equit\u00e0 prevedibile e sufficiente flessibilit\u00e0 ottiene un ottimo risultato.<\/p>\n\n<h2>Limiti e ostacoli tipici<\/h2>\n\n<p>Con un numero estremamente elevato di task simultanei, l'overhead delle operazioni ad albero aumenta, mentre non \u00e8 il caso di <strong>Suggerimenti<\/strong> il <strong>Latenza<\/strong> pu\u00f2 aumentare le prestazioni. Nelle configurazioni di hosting con molte richieste molto brevi, a volte si verificano frequenti cambi di contesto. Questo comportamento di \u201cthrashing\u201d riduce l'efficienza se i valori di granularit\u00e0 sono scelti in modo errato. Un numero minore di fette di tempo, ma pi\u00f9 lunghe, pu\u00f2 essere utile, a condizione che venga mantenuta l'interattivit\u00e0. CFS reagisce in modo sensibile a quote non corrette, per questo motivo controllo costantemente i limiti con test di carico.<\/p>\n\n<p>Anche i carichi di lavoro compatibili con l'affinit\u00e0 soffrono se le attivit\u00e0 passano troppo spesso da un core all'altro. Un concetto di affinit\u00e0 pulito mantiene le cache calde e riduce i costi di migrazione. Mi piace anche vincolare i lavori batch rumorosi ai propri core, in modo che le richieste web vengano eseguite tranquillamente sui loro core. Per i servizi critici dal punto di vista della latenza, vale la pena di impostare valori bassi e gradevoli e una latenza finemente regolata. Alla fine, ci\u00f2 che conta \u00e8 che le misurazioni confermino i parametri selezionati.<\/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\/03\/linux-scheduler-cfs-server-7012.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronto tra le alternative: ULE, BFS e EEVDF<\/h2>\n\n<p>Per i carichi di lavoro speciali, esamino le alternative al fine di <strong>Latenza<\/strong> oppure <strong>Scala<\/strong> assegnano le priorit\u00e0 in modo diverso. ULE utilizza code pi\u00f9 semplici e ottiene risultati con un minore sforzo amministrativo, BFS d\u00e0 priorit\u00e0 alla reattivit\u00e0 e brilla con pochi task, mentre EEVDF combina una distribuzione equa con le scadenze. EEVDF, in particolare, promette tempi di attesa pi\u00f9 brevi per i carichi interattivi, perch\u00e9 lo scheduler presta maggiore attenzione alla \u201cprima scadenza ammissibile\u201d. Per i campi di server molto grandi, ci\u00f2 che conta davvero alla fine \u00e8 quale mix di efficienza e pianificabilit\u00e0 vince davvero nel proprio stack. Un esame strutturato dei punti di forza, dei punti deboli e dei campi di applicazione aiuta nella selezione.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>scheduler<\/th>\n      <th>Complessit\u00e0<\/th>\n      <th>Punti di forza nell'hosting<\/th>\n      <th>Punti di debolezza<\/th>\n      <th>Adatto per<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>CFS<\/strong><\/td>\n      <td>Alto<\/td>\n      <td>Distribuzione equa, <strong>Gruppi C<\/strong><\/td>\n      <td>Picchi di latenza<\/td>\n      <td>Hosting condiviso, carichi misti<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ULE<\/strong><\/td>\n      <td>Basso<\/td>\n      <td>Spunti semplici, bassi <strong>Carico<\/strong><\/td>\n      <td>Meno isolamento<\/td>\n      <td>Macchine virtuali, modelli simili all'HPC<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>BFS<\/strong><\/td>\n      <td>Medio<\/td>\n      <td>Interattivit\u00e0, <strong>Velocit\u00e0<\/strong><\/td>\n      <td>Scalatura debole<\/td>\n      <td>Desktop, piccoli server<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>EEVDF<\/strong><\/td>\n      <td>Medio<\/td>\n      <td>Bassa latenza, <strong>scadenze<\/strong><\/td>\n      <td>Ancora poca pratica<\/td>\n      <td>Stack di hosting moderno<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Messa a punto del kernel: passi pratici per il CFS<\/h2>\n\n<p>Per CFS, spesso cambio sched_autogroup_enabled=0, in modo che nessun gruppo implicito distorca l'immagine e il <strong>Distribuzione del carico<\/strong> chiaro <strong>resti<\/strong>. Con sched_latency_ns mi piace partire da 20ms, che favorisce i servizi interattivi, e regolare sched_min_granularity_ns per domare i cambiamenti di contesto. I valori dipendono dal profilo: molte richieste web brevi necessitano di una messa a punto diversa rispetto alle finestre di backup. Esamino le modifiche in serie e misuro i percentili invece di guardare solo le medie. In questo modo non solo i valori medi appaiono gradevoli, ma anche le lunghe code si riducono.<\/p>\n\n<p>Se volete approfondire i parametri di sysctl, troverete una buona introduzione qui: <a href=\"https:\/\/webhosting.de\/it\/messa-a-punto-del-kernel-linux-parametro-sysctl-serverboost-opti\/\">messa a punto di sysctl<\/a>. Regolo anche la distribuzione degli IRQ, il regolatore della CPU e i profili energetici, in modo che la CPU non passi costantemente a stati economici. Uso i regolatori di prestazioni per gli stack basati sulla latenza, mentre i box batch puri vivono con un controllo bilanciato. Separo chiaramente le fasi di test e di produzione per evitare sorprese. Dopo ogni fase, controllo i log e le metriche prima di andare avanti.<\/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\/03\/linux_scheduler_cfs_tech_office_5278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Usare cgroup e quote in modo sensato<\/h2>\n\n<p>Con cpu.shares assegno il relativo <strong>Pesi<\/strong> mentre cpu.max \u00e8 difficile <strong>Confini<\/strong> insiemi. Un cliente con 512 azioni ottiene la met\u00e0 del tempo di calcolo di un cliente con 1024, se entrambi generano carico nello stesso momento. Uso cpu.max per limitare i picchi in modo pulito, ad esempio 50ms in 100ms. Per i lavori dedicati, vale cpuset.cpus, in modo che un servizio utilizzi core fissi e la cache rimanga calda. Tutto sommato, si ottiene una separazione resiliente tra clienti e servizi.<\/p>\n\n<p>Documento ogni modifica e la confronto con i livelli di servizio che voglio raggiungere. Senza valori misurati, le quote portano rapidamente a interpretazioni errate, per questo motivo accompagno sempre le regolazioni con test di carico. Per i container, suggerisco quote realistiche in grado di gestire i picchi ma senza rallentare l'host. Resta importante avere un budget di errore prevedibile, in modo da rilevare picchi di latenza evidenti. Se lo si fa con costanza, si eviteranno sorprese nei momenti di picco.<\/p>\n\n<h2>Pratica: server web e database sotto CFS<\/h2>\n\n<p>I server web orientati agli eventi riducono i cambi di contesto e si armonizzano con il CFS, con il risultato di una costante <strong>Tempi di risposta<\/strong> e migliore <strong>Scala<\/strong> generato. Nei test, ho visto che NGINX mantiene tassi di richiesta pi\u00f9 elevati con meno jitter sullo stesso hardware. I database reagiscono positivamente all'affinit\u00e0 dei core quando i lavori in background sono tenuti lontani dai core caldi. Semplici regole aiutano: Web sui core A-B, batch su C-D e DB su E-F. In questo modo, lo stack mantiene la pipeline pulita e le cache calde.<\/p>\n\n<p>Molti piccoli worker PHP FPM causano troppi switch con una granularit\u00e0 aggressiva. Aumento quindi il time slice minimo e verifico se i tempi di risposta rimangono stabili. Allo stesso tempo, limito i log di chat in modo che l'I\/O non diventi un freno. Il CFS fornisce la base, ma le prestazioni massime si ottengono con la messa a punto dell'intero stack. In questo modo, tutti gli ingranaggi si incastrano senza togliere il respiro all'host.<\/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\/03\/linux_scheduler_server_hosting_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I\/O di memoria e scheduling della CPU: l'interazione<\/h2>\n\n<p>Lo scheduler della CPU e lo scheduler dell'I\/O si influenzano a vicenda, ed \u00e8 per questo che una configurazione armonizzata pu\u00f2 fare una differenza notevole. <strong>Vantaggi<\/strong> all'indirizzo <strong>Latenza<\/strong> porta. Per NVMe di solito uso Noop o mq-deadline, mentre sugli HDD mq-deadline serve meglio le code lunghe. Se la CPU alloca il tempo in tempo ma il percorso di I\/O si blocca, l'effetto complessivo viene annullato. Pertanto, verifico lo scheduler I\/O in parallelo con i parametri CFS. Qui fornisco una panoramica di Noop, mq-deadline e BFQ: <a href=\"https:\/\/webhosting.de\/it\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">Pianificatore I\/O a confronto<\/a>.<\/p>\n\n<p>Per gli host di database, regolo la profondit\u00e0 della coda e il read-ahead in modo che gli slot pianificati dal CFS non si esauriscano a causa del blocco dell'I\/O. I server web con molti file di piccole dimensioni traggono vantaggio da una bassa latenza nello stack I\/O. Negli scenari di virtualizzazione, mi affido a scheduler coerenti su host e guest per evitare schemi imprevedibili. Questo \u00e8 il modo in cui lo scheduler della CPU interagisce con il sottosistema di archiviazione. Alla fine, ci\u00f2 che conta \u00e8 la catena coerente dalla richiesta alla risposta.<\/p>\n\n<h2>Bilanciamento SMP, affinit\u00e0 dei core e NUMA<\/h2>\n\n<p>Dirigo i thread su core fissi in modo che <strong>Cache<\/strong> costi di riscaldamento e migrazione <strong>piccolo<\/strong> rimanere. Per gli host NUMA, collego memoria e CPU perch\u00e9 gli accessi remoti alla memoria aumentano la latenza. Il CFS bilancia il carico tra le code di esecuzione, ma spesso le regole di affinit\u00e0 intenzionali permettono di ottenere di pi\u00f9. I servizi con accesso frequente alla cache beneficiano di gruppi di core stabili. I lavori batch possono vagare purch\u00e9 non interferiscano con i core caldi.<\/p>\n\n<p>In pratica, imposto le opzioni cpuset.cpus e numactl, quindi verifico i tempi di richiesta e i tassi di perdita della CPU. Meno migrazioni non necessarie ci sono, migliore \u00e8 il tempo di risposta. Valuto anche la distribuzione degli interrupt in modo che i picchi di IRQ non intasino un core. In questo modo, ottengo un clock regolare dei thread importanti. Questa tranquillit\u00e0 si riflette sulle prestazioni complessive dello stack.<\/p>\n\n<h2>Programmazione di gruppo: bella, ponderazione e gerarchie<\/h2>\n\n<p>Un ostacolo frequente nell'hosting \u00e8 il <strong>Interazione<\/strong> tra <strong>bello<\/strong>-Priorit\u00e0 e <strong>Pesi del gruppo C<\/strong>. CFS distribuisce prima in modo equo tra i gruppi, poi all'interno del gruppo tra i task. Ci\u00f2 significa che un processo con nice -5 pu\u00f2 comunque ottenere meno CPU di un altro con nice 0 se il suo gruppo (client\/container) ha un peso inferiore. Per ottenere risultati coerenti, ho quindi impostato prima il parametro <em>Pesi del gruppo<\/em> e usare nice solo per la messa a punto all'interno di un servizio.<\/p>\n\n<p>In pratica, lavoro con alcuni livelli chiari (ad esempio 512\/1024\/2048 azioni per \u201cbasso\/normale\/alto\u201d) e documento quali servizi sono in esecuzione in quale gruppo. In questo modo si mantiene il <strong>Equit\u00e0<\/strong> rintracciabili nella gerarchia. Chi lavora molto con processi di breve durata (ad esempio, lavori CGI\/CLI) trae vantaggio anche da <strong>basato su cgroup<\/strong> perch\u00e9 altrimenti i task volatili aggirerebbero involontariamente il corsetto di gruppo. Uso regolarmente le metriche di runtime per verificare se l'allocazione interna corrisponde ancora al profilo di carico.<\/p>\n\n<h2>Contenitori e orchestrazione: richieste, limiti e throttling<\/h2>\n\n<p>Negli ambienti con container, una \u201crichiesta\u201d di solito corrisponde a <strong>peso relativo<\/strong> (azioni\/peso), un \u201climite\u201d sulla <strong>Quota<\/strong> (cpu.max). L'interazione decide su <strong>Strozzatura<\/strong>Se la quota \u00e8 troppo stretta, la CPU del container viene rallentata nel periodo - visibile nei rimbalzi della latenza p95\/p99. Pertanto, mantengo le quote in modo tale che i normali burst rientrino nel periodo e che i servizi siano raramente sottoposti a un forte rallentamento. Dove \u00e8 disponibile, uso una quota <em>Burst<\/em>-(ad esempio, cpu.max.burst) per attenuare i picchi brevi senza distorsioni.<\/p>\n\n<p>\u00c8 importante non impostare richieste troppo basse: Se i pesi sono troppo bassi, i servizi interattivi rimarranno indietro rispetto al rumore del batch. Calibro le richieste in base al carico di base misurato e ai limiti di sicurezza, in modo che <strong>Bilanci di errore<\/strong> vengono mantenuti durante i momenti di picco. Per i nodi multi-tenant, pianifico anche i core buffer in modo che i picchi di carico dei singoli container non influiscano sui vicini.<\/p>\n\n<h2>Metodi di misurazione e risoluzione dei problemi nel contesto dello scheduler<\/h2>\n\n<p>Non valuto mai la sintonizzazione della CFS alla cieca, ma la misuro in modo mirato. Uso per la visione d'insieme:<\/p>\n<ul>\n  <li><strong>Lunghezza della coda<\/strong> per CPU (carico rispetto ai core attivi),<\/li>\n  <li><strong>Cambiamento di contesto<\/strong> al secondo e il numero di thread,<\/li>\n  <li><strong>Furto di CPU<\/strong> e <strong>SoftIRQ<\/strong>-Condivisione,<\/li>\n  <li><strong>Percentile<\/strong> dei tempi di risposta (p50\/p95\/p99),<\/li>\n  <li>Distribuzione di <strong>vruntime<\/strong> o le latenze di programmazione.<\/li>\n<\/ul>\n<p>Se si verificano picchi di latenza, cerco prima di tutto <strong>Strozzatura<\/strong> (quota esaurita), poi dopo <strong>Migrazioni<\/strong> (cache fredda) e infine dopo <strong>Blocchi di I\/O<\/strong> (profondit\u00e0 della coda, saturazione dello storage). Osservo gli schemi di risveglio: risvegli frequenti e brevi di molti lavoratori indicano una granularit\u00e0 troppo fine o un I\/O troppo chiacchierato. Un aumento della percentuale di ksoftirqd su un core indica code IRQ calde: in questo caso distribuisco gli IRQ e attivo RPS\/XPS in modo che il carico di rete sia distribuito pi\u00f9 ampiamente.<\/p>\n\n<h2>Classi in tempo reale, prelazione e controllo delle spunte<\/h2>\n\n<p>Oltre alla CFS, esistono le seguenti classi in tempo reale <strong>SCHED_FIFO\/RR<\/strong>. Essi sovrascrivono il CFS: un thread RT configurato in modo errato pu\u00f2 letteralmente togliere l'aria al sistema. Per questo motivo assegno RT-Prio solo in modo molto selettivo (ad esempio per l'audio\/telemetria) e definisco dei chiari cani da guardia. Per l'hosting, CFS con pesi puliti \u00e8 di solito sufficiente.<\/p>\n\n<p>A <strong>Prelazione<\/strong>La scelta del modello di prelazione (ad esempio \u201cvolontario\u201d o \u201cprelazione completa\/dinamica\u201d) modifica il rapporto latenza\/throughput. Per gli stack web preferisco pi\u00f9 preemption, per gli host batch puri meno. Ottimizzazioni dei tick (<em>nohz<\/em>-modes) pu\u00f2 ridurre il jitter, ma deve essere usato con cautela. Sui core isolati, di tanto in tanto combino <em>nohz_full<\/em> e Affinity, in modo che i thread caldi funzionino il pi\u00f9 indisturbati possibile: \u00e8 importante che i carichi di sistema e IRQ non migrino inavvertitamente su questi core.<\/p>\n\n<h2>Virtualizzazione: KVM, vCPU pinning e steal time<\/h2>\n\n<p>Nell'ambiente dell'ipervisore, lo scheduler dell'host determina quando <strong>vCPU<\/strong> pu\u00f2 essere eseguito. Creare overbooking <strong>Tempo di furto<\/strong> nei guest, che agisce come una \u201clatenza invisibile\u201d. Per i tenant critici per la latenza, collego le vCPU ai core fisici e mantengo moderato l'overcommit. Inoltre, separo i thread dell'emulatore (thread IO, vhost) dai core caldi dei guest in modo che non interferiscano tra loro.<\/p>\n\n<p>Evito il doppio throttling: se il guest sta gi\u00e0 utilizzando cpu.max, non imposto ulteriori quote rigide sull'host per lo stesso carico di lavoro. Il controllo della frequenza rimane compito dell'host; gli ospiti ne beneficiano indirettamente se il governor dell'host scala in modo pulito con il carico di lavoro effettivo. Per le latenze uniformi, ritengo che la stabilit\u00e0 al di l\u00e0 della pura frequenza massima sia pi\u00f9 importante del picco di GHz sulla carta.<\/p>\n\n<h2>AutoNUMA, localizzazione della memoria e THP<\/h2>\n\n<p>NUMA pu\u00f2 essere un guadagno di prestazioni o una trappola per le prestazioni. <strong>AutoNUMA<\/strong> spesso aiuta, ma pu\u00f2 generare un sovraccarico aggiuntivo con i thread in forte roaming. Negli stack di hosting con chiari confini di servizio, io applico CPU e <strong>Memoria<\/strong> (<em>cpuset.cpus<\/em> e <em>cpuset.mems<\/em>) insieme. Ci\u00f2 significa che i dati caldi rimangono locali e il CFS deve compensare un minor numero di migrazioni.<\/p>\n\n<p>Pagine grandi (<strong>THP<\/strong>) riducono la pressione TLB, ma non sono adatte a tutti i profili. Per i database, \u201cmadvise\u201d pu\u00f2 avere pi\u00f9 senso di un \u201csempre\u201d generico. I page fault bloccanti colpiscono duramente la latenza interattiva; per questo motivo pianifico i buffer (page cache, buffer condiviso) in modo che gli slot CFS siano utilizzati in modo produttivo e non attendano eventi di I\/O o MMU. Questo pu\u00f2 essere misurato attraverso i tassi di errore di pagina e le curve di miss della cache.<\/p>\n\n<h2>Percorso di rete: controllo IRQ, RPS\/XPS e polling di occupato<\/h2>\n\n<p>Molti carichi di lavoro web sono dominati dalle NIC. Distribuisco <strong>IRQ<\/strong>-della scheda di rete su pi\u00f9 core e mantenerli <em>affine<\/em> ai thread worker, in modo che i risvegli rimangano locali. <strong>RPS\/XPS<\/strong> aiuta a risolvere gli hotspot soft se le singole code RX\/TX stanno sopportando un carico eccessivo. Se ksoftirqd diventa visibilmente caldo, ci\u00f2 indica che le SoftIRQ sono sovraccariche - quindi equalizzo i flussi e aumento i parametri di budget, se necessario, senza perdere l'equit\u00e0.<\/p>\n\n<p>Il polling occupato opzionale pu\u00f2 avere senso in configurazioni molto speciali a bassa latenza, ma costa tempo alla CPU. Lo uso raramente e solo se posso dimostrare con misurazioni che p99 cala in modo significativo senza stressare l'host in generale. Normalmente, l'affinit\u00e0 IRQ pulita, i gruppi C e la granularit\u00e0 CFS offrono un miglior rapporto costi-benefici.<\/p>\n\n<h2>Prospettive: Da CFS a EEVDF e approcci userspace<\/h2>\n\n<p>EEVDF estende la distribuzione equa per includere le scadenze, il che \u00e8 sensibilmente <strong>pi\u00f9 breve<\/strong> e pi\u00f9 prevedibile <strong>Risposte<\/strong> promesse. Soprattutto con gli obiettivi interattivi di latenza, questo pu\u00f2 fare la differenza. Tengo d'occhio le versioni del kernel e provo EEVDF separatamente prima di cambiare. Allo stesso tempo, si sta affermando lo scheduling dello spazio utente tramite modelli eBPF, che possono consentire un controllo aggiuntivo a seconda del carico di lavoro. CFS rimane rilevante per le infrastrutture di hosting, ma EEVDF si affermer\u00e0 rapidamente.<\/p>\n\n<p>Rimane importante un chiaro percorso di migrazione: test, rollout su host selezionati, quindi espansione. Questo \u00e8 l'unico modo per tenere sotto controllo percentili e tassi di errore. Mantengo i benchmark vicini alla realt\u00e0, comprese le fasi di burst e i backend lenti. Solo allora intervengo negli ambienti live. In questo modo \u00e8 possibile ottenere progressi senza brutte sorprese.<\/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\/03\/linux-scheduler-hosting-4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Lo Scheduler CFS di Linux offre una distribuzione equa, solide integrazioni e una buona <strong>Controllo<\/strong> tramite <strong>Gruppi C<\/strong>. Con parametri sysctl adeguati, affinit\u00e0 pulita e quote realistiche, mantengo basse le latenze e alto il throughput. ULE, BFS o EEVDF offrono un'ulteriore leva per modelli speciali. Misuro, confronto e introduco le modifiche per gradi per limitare i rischi. In questo modo l'hosting rimane prevedibile e le prestazioni sono al loro posto.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux Scheduler CFS spiegato: come funziona, cpu scheduling server e alternative come EEVDF. Messa a punto del kernel per ottimizzare le prestazioni dell'hosting.<\/p>","protected":false},"author":1,"featured_media":18546,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18553","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":"562","_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 CFS","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":"18546","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18553","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=18553"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/18546"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=18553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=18553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=18553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}