{"id":21507,"date":"2026-09-18T08:32:17","date_gmt":"2026-09-18T06:32:17","guid":{"rendered":"https:\/\/webhosting.de\/tickless-mode-linux-kernel-rhythmus\/"},"modified":"2026-09-18T08:32:17","modified_gmt":"2026-09-18T06:32:17","slug":"modalita-tickless-kernel-linux-ritmo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/tickless-mode-linux-kernel-rhythmus\/","title":{"rendered":"Spiegazione della modalit\u00e0 \"tickless\" dello scheduler del kernel: vantaggi, rischi e ottimizzazione"},"content":{"rendered":"<p>Spiego il <strong>modalit\u00e0 tickless<\/strong> del kernel Linux in modo comprensibile e illustrer\u00f2 in quali casi influisce positivamente sulle prestazioni, sulla latenza e sul consumo energetico. A tal fine, indicher\u00f2 le opportunit\u00e0 evidenti, i possibili rischi e le operazioni concrete di ottimizzazione che utilizzo nella pratica.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Riassumo i pi\u00f9 importanti <strong>Temi principali<\/strong> riassunti in modo sintetico, cos\u00ec saprai subito a cosa prestare attenzione. Lo scheduler di Linux e il tick dinamico interagiscono direttamente tra loro e determinano il comportamento del tuo <strong>CPU<\/strong>. A seconda del carico di lavoro, decido se \u00e8 sufficiente il \u201cTickless Idle\u201d o se \u00e8 meglio utilizzare il \u201cFull Tickless\u201d con core isolati. Per ottenere risultati riproducibili, pianifico accuratamente le CPU di housekeeping, l\u2019affinit\u00e0 IRQ e i callback RCU. Alla fine, ci\u00f2 che conta sono i valori misurati relativi a latenza, consumo energetico e throughput nel tuo <strong>Impostazione<\/strong> mostrare davvero.<\/p>\n<ul>\n  <li><strong>Funzionamento al minimo senza ticchettio<\/strong>: meno ticchettii al minimo<\/li>\n  <li><strong>NO_HZ_FULL<\/strong>: nuclei tranquilli e isolati<\/li>\n  <li><strong>Affinit\u00e0 IRQ<\/strong>: Raggruppare le fonti di disturbo<\/li>\n  <li><strong>Pinning della CPU<\/strong>: Assegnare in modo definitivo i thread<\/li>\n  <li><strong>Valori misurati<\/strong>: latenza, energia, jitter<\/li>\n<\/ul>\n<p>L'elenco riporta le leve di regolazione che controllo e combino per prime. In questo modo riesco a individuare rapidamente dove si trova il maggiore <strong>Leva<\/strong> e quanto modifico il kernel.<\/p>\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\/09\/kernel-tickless-6359.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Qual \u00e8 l'effetto pratico del tick del kernel<\/h2>\n\n<p>Un tick periodico attiva nel kernel la misurazione del tempo, la gestione dei timer e nuove <strong>Pianificazione<\/strong>-Decisioni. \u00c8 semplice, ma riattiva i kernel anche quando non c\u2019\u00e8 alcun lavoro significativo da svolgere. Con Tickless, il kernel pianifica il prossimo risveglio in base alle esigenze ed evita inutili <strong>Interruzioni<\/strong>. In questo modo le CPU rimangono pi\u00f9 a lungo in stati C profondi e generano meno jitter per le attivit\u00e0 in cui la latenza \u00e8 fondamentale. Utilizzo questo meccanismo per creare finestre di esecuzione tranquille per i thread sensibili.<\/p>\n\n<h2>Varianti: panoramica su Tickless Idle e NO_HZ_FULL<\/h2>\n\n<p><strong>Funzionamento al minimo senza ticchettio<\/strong> (CONFIG_NO_HZ_IDLE) disattiva il tick periodico non appena una CPU \u00e8 inattiva. Ci\u00f2 riduce il consumo energetico e il calore, poich\u00e9 il processore viene risvegliato meno spesso dallo stato di sospensione profonda. <strong>NO_HZ_FULL<\/strong> prosegue e riduce i tick anche sui core attivi, se su di essi \u00e8 in esecuzione un solo task. A tal fine, isolo rigorosamente questi core e trasferisco il lavoro di sistema su CPU dedicate alla gestione interna. Chi implementa un isolamento accurato ottiene core molto silenziosi e quindi una maggiore prevedibilit\u00e0 sotto carico.<\/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\/09\/tickless_mode_vorteile_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tabella comparativa e scenari di applicazione<\/h2>\n\n<p>La seguente panoramica mi aiuta a trovare il modello giusto <strong>Modalit\u00e0<\/strong> scegliere in base all\u2019obiettivo e preparare correttamente l\u2019ambiente necessario. Prendo in considerazione innanzitutto le caratteristiche del carico di lavoro, poi gli obiettivi energetici e infine la tolleranza al jitter. Per esperienza, un chiaro isolamento della CPU si rivela particolarmente vantaggioso nel trading, nell\u2019HPC e in contesti con latenza molto bassa <strong>Rete<\/strong>-stack. Nel centro dati con carico di lavoro variabile, invece, la modalit\u00e0 \u201cTickless Idle\u201d spesso garantisce il risparmio pi\u00f9 rapido. Riservo la modalit\u00e0 \u201cFull Tickless\u201d agli host sottoposti a controlli rigorosi, sui quali isolo in modo affidabile le operazioni di sistema.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Modalit\u00e0<\/th>\n      <th>Quando \u00e8 attivo<\/th>\n      <th>Vantaggio<\/th>\n      <th>Il rischio<\/th>\n      <th>Adatto per<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tick periodico<\/td>\n      <td>Sempre, frequenza cardiaca fissa<\/td>\n      <td>Semplice <strong>Amministrazione<\/strong><\/td>\n      <td>Pi\u00f9 jitter e wake-up<\/td>\n      <td>Server generici<\/td>\n    <\/tr>\n    <tr>\n      <td>Funzionamento al minimo senza tick (NO_HZ_IDLE)<\/td>\n      <td>Solo al minimo<\/td>\n      <td>Meno energia, pi\u00f9 fresco <strong>CPU<\/strong><\/td>\n      <td>Vantaggio limitato in termini di latenza<\/td>\n      <td>Host VM, Web, Misto<\/td>\n    <\/tr>\n    <tr>\n      <td>Full Tickless (NO_HZ_FULL)<\/td>\n      <td>Anche in caso di carico a singola attivit\u00e0<\/td>\n      <td>Zone molto tranquille, poco <strong>Jitter<\/strong><\/td>\n      <td>\u00c8 necessario un isolamento accurato<\/td>\n      <td>HPC, trading, quasi in tempo reale<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Quando la modalit\u00e0 \"tickless\" d\u00e0 il meglio di s\u00e9<\/h2>\n\n<p>Attivo la modalit\u00e0 \"Full Tickless\" sui core isolati quando un'applicazione \u00e8 estremamente <strong>Bassa latenza<\/strong> deve reagire. Tra questi figurano l\u2019order matching, l\u2019elaborazione di pacchetti con coda singola o la localizzazione NUMA ristretta nei codici scientifici. Quando si perseguono obiettivi energetici su host misti, spesso il Tickless Idle \u00e8 sufficiente per ottenere miglioramenti misurabili <strong>Risparmio<\/strong>. Chi osserva molte fasi di sleep ne trae grandi vantaggi, poich\u00e9 gli stati C vengono abbandonati meno frequentemente a causa dei tick. Ti invito a leggere la mia guida su <a href=\"https:\/\/webhosting.de\/it\/server-kernel-tickless-efficienza-energetica-ottimizzata-verde\/\">Efficienza energetica con Tickless<\/a>, soprattutto se vuoi ridurre i costi dell'elettricit\u00e0.<\/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\/09\/tickless-mode-scheduler-explained-4785.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vantaggi ed effetti collaterali nella vita quotidiana<\/h2>\n\n<p>Un numero inferiore di tick periodici significa meno <strong>Cambiamento di contesto<\/strong> e tempi di esecuzione spesso pi\u00f9 uniformi. Nelle configurazioni di isolamento, il rumore del sistema operativo diminuisce, consentendo al codice sensibile di reagire in modo pi\u00f9 coerente. Secondo la Linux Foundation e la documentazione del kernel, NO_HZ_IDLE offre notevoli miglioramenti in modalit\u00e0 idle, mentre NO_HZ_FULL riduce ulteriormente gli impulsi di disturbo. La documentazione HPC conferma l\u2019efficacia di questa combinazione con il pinning e il raggruppamento degli IRQ sui kernel di housekeeping. Chi imposta correttamente le misurazioni, riconosce chiaramente questi effetti nei profili di latenza e di consumo energetico dei <strong>Ospiti<\/strong>.<\/p>\n\n<h2>Rischi derivanti da una messa a punto errata<\/h2>\n\n<p>Prevedo dei problemi se gli IRQ o i callback RCU finissero comunque su kernel isolati e il <strong>Riposo<\/strong> distruggere. A quel punto il vantaggio viene meno, perch\u00e9 il carico di disturbo si manifesta in modo non coordinato e genera jitter. Anche i servizi in background non pianificati, i timer o i watchdog su CPU isolate hanno un effetto di disturbo simile. Anche i carichi di lavoro misti con molte attivit\u00e0 brevi distribuiscono l\u2019instabilit\u00e0 su una scala cos\u00ec ampia che il \u00abFull Tickless\u00bb offre pochi vantaggi. Per questo motivo prevedo chiaramente dei core dedicati alla gestione interna e testo ogni fase con scenari realistici <strong>Profili<\/strong>.<\/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\/09\/ticless_mode_tech_buer_1593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Le principali opzioni del kernel spiegate in modo chiaro<\/h2>\n\n<p>Con <strong>CONFIG_NO_HZ_IDLE<\/strong> Disattivo il tick in modalit\u00e0 inattiva e ottengo rapidi guadagni senza grandi modifiche. <strong>CONFIG_NO_HZ_FULL<\/strong> Lo attivo solo quando isolo rigorosamente i core e definisco CPU dedicate alla gestione interna. Il parametro di avvio `nohz_full` specifica quali core funzionano in modalit\u00e0 tickless; `isolcpus` li disaccoppia dalla schedulazione generale. rcu_nocbs sposta i callback RCU lontano da questi core, mentre irqaffinity imposta l\u2019affinit\u00e0 degli interrupt. Solo nell\u2019insieme questa configurazione risulta stabile e quindi davvero <strong>utile<\/strong>.<\/p>\n\n<h2>Pianificazione dei nuclei di pulizie<\/h2>\n\n<p>Ne prenoto uno o due <strong>nuclei<\/strong> Ogni nodo NUMA funge da zona di gestione interna per IRQ, thread del kernel e RCU. Questi core si fanno carico delle inevitabili attivit\u00e0 di sistema, lasciando liberi i core isolati. A tal fine, assegno intenzionalmente i servizi e le code IRQ alle CPU di gestione interna e li blocco sui core silenziosi. Chiunque voglia <a href=\"https:\/\/webhosting.de\/it\/server-cpu-scheduler-class-scheduling\/\">Classi di scheduler della CPU<\/a> comprende, gestisce le priorit\u00e0 e garantisce l'equit\u00e0 in modo affidabile. In questo modo i percorsi di latenza rimangono brevi e i core inattivi garantiscono prestazioni prevedibili <strong>Tempi di risposta<\/strong>.<\/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\/09\/entwicklerdesk_kernel_7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guida pratica: Passo dopo passo<\/h2>\n\n<p>Inizio ogni progetto con un chiaro <strong>Linea di base<\/strong>-Run: latenza, consumo energetico, throughput, jitter. Successivamente verifico se NO_HZ_IDLE \u00e8 attivo e se il kernel supporta NO_HZ_FULL. Successivamente, assegno l\u2019affinit\u00e0 IRQ, imposto rcu_nocbs e pianifico le CPU di housekeeping. Solo allora isolo alcuni core a titolo di prova con nohz_full e confronto i risultati. Per l\u2019analisi approfondita mi \u00e8 d\u2019aiuto questa guida su <a href=\"https:\/\/webhosting.de\/it\/misurare-la-latenza-dello-scheduler-di-linux-e-ottimizzare-le-prestazioni\/\">Misurare la latenza<\/a>, in modo da poter valutare accuratamente ogni modifica.<\/p>\n\n<h2>Metodi di misurazione e KPI<\/h2>\n\n<p>Misuro l'end-to-end-<strong>Latenza<\/strong> utilizzando istogrammi e quantificando i valori anomali, invece di limitarmi a considerare solo i valori medi. Valuto congiuntamente PPS e Tail-Latency, in modo che i core inattivi non riducano la velocit\u00e0 di trasmissione. Misuro il consumo energetico tramite RAPL, IPMI o un contatore collegato e calcolo il risparmio in <strong>Euro<\/strong> al mese. Esempio: se un host risparmia 12 W in funzionamento 24 ore su 24, 7 giorni su 7, a una tariffa di 0,30 \u20ac\/kWh il risparmio \u00e8 di circa 3,15 \u20ac al mese per macchina. Con 200 host, il risparmio complessivo raggiunge la notevole cifra di 630 \u20ac al mese.<\/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\/09\/kernel-scheduler-tickless-8475.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uno sguardo pi\u00f9 approfondito: come il kernel disattiva realmente i tick<\/h2>\n<p>Dietro Tickless c'\u00e8 il passaggio dal tick periodico a un <strong>Evento con orologio one-shot<\/strong>: Il kernel programma il prossimo \u201eevento\u201c esattamente in corrispondenza della prima scadenza di un timer o di una decisione dello scheduler. I timer ad alta risoluzione (hrtimer) consentono una granularit\u00e0 fine. Su un <strong>NO_HZ_FULL<\/strong>- Nella CPU, il tick periodico dello scheduler viene omesso fintanto che \u00e8 in esecuzione un solo task e non sono previste attivit\u00e0 del kernel. Non appena due o pi\u00f9 task sono eseguibili, il kernel riavvia il tick per garantire l\u2019equit\u00e0 e il corretto timeslicing. \u00c8 proprio questa dinamica a rendere il sistema pi\u00f9 silenzioso, senza compromettere la correttezza della schedulazione.<\/p>\n\n<h2>HZ, timer ad alta risoluzione e conto tempo<\/h2>\n<p>La costante del kernel <strong>HZ<\/strong> (in genere 250 o 1000) determina la frequenza del tick classico. Con la modalit\u00e0 \"tickless\", HZ perde importanza pratica per i nuclei in cui il tempo di esecuzione \u00e8 critico, ma rimane rilevante per la logica basata su jiffies. \u00c8 importante anche la <strong>Contabilizzazione temporale<\/strong> (VTIME\/Context Tracking): Affinch\u00e9 il tempo utente e il tempo di sistema vengano registrati correttamente, il kernel tiene traccia con precisione di quando un\u2019attivit\u00e0 si trova nel kernel o nello spazio utente, senza un tick permanente. Chi lavora spesso con il profiling dovrebbe tenerlo presente per interpretare correttamente le misurazioni.<\/p>\n\n<h2>Meccanismi di risparmio energetico e \u201ctickless\u201d<\/h2>\n<p>Tickless esercita il suo effetto di risparmio energetico solo quando la piattaforma \u00e8 in stato di sospensione profonda <strong>Stati C<\/strong> in modo affidabile. Verifico quindi le impostazioni del firmware e del kernel relative a intel_pstate\/amd-pstate, alle modalit\u00e0 Turbo e <strong>cpufreq<\/strong>-Governor. Un governor di prestazioni aggressivo pu\u00f2 ridurre le latenze, ma compromettere gli obiettivi energetici. Al contrario, un governor Powersave troppo lento pu\u00f2 ridurre la produttivit\u00e0. Il mio approccio: prima stabilizzare la configurazione tickless, poi testare sistematicamente la messa a punto degli stati P e C, in entrambi i casi con profili di carico di lavoro identici.<\/p>\n\n<h2>Virtualizzazione e container<\/h2>\n<p>Sugli host dell'hypervisor, porta <strong>Funzionamento al minimo senza ticchettio<\/strong> risparmi spesso immediatamente percepibili, poich\u00e9 le vCPU inattive vengono riattivate meno frequentemente. Per <strong>NO_HZ_FULL<\/strong> Isolo i core fisici e assegno le vCPU delle VM critiche esattamente a quei core. Importante: lo \u201csteal time\u201d e gli IRQ dell\u2019host non devono interferire con questi core. Nelle macchine guest, la modalit\u00e0 \u00abFull Tickless\u00bb ha senso solo se l\u2019host fornisce il tempo di CPU in modo deterministico. Negli ambienti container, replico la logica di isolamento con <strong>cgroups CPUset<\/strong> e impedisci che i System Pod o i Sidecar occupino i core silenziosi.<\/p>\n\n<h2>Ottimizzare i percorsi di rete e di archiviazione<\/h2>\n<p>Per ottenere latenze estremamente basse, raggruppo <strong>Code RX\/TX<\/strong> e i relativi IRQ sulle CPU di gestione interna. Sui core meno sollecitati preferisco utilizzare il polling nello spazio utente o thread di completamento dedicati, anzich\u00e9 consentire l\u2019uso degli IRQ. Con NVMe \u00e8 possibile <strong>Affinit\u00e0 della coda IO<\/strong> aiuta in modo simile. Il NAPI-Busy-Polling pu\u00f2 essere utilizzato in modo mirato quando il jitter del polling \u00e8 pi\u00f9 prevedibile rispetto al jitter degli interrupt. L'obiettivo \u00e8 che i core isolati non vengano mai risvegliati in modo imprevisto da eventi esterni.<\/p>\n\n<h2>Esempio: parametri di avvio e pinning<\/h2>\n<p>Ecco come delineo una configurazione minima (ad esempio 16 core, core 0-1 dedicati alle attivit\u00e0 di gestione interna; 2-7 e 10-15 come candidati per il carico di lavoro; 8-9 per i servizi di sistema):<\/p>\n<pre><code>GRUB_CMDLINE_LINUX=\"nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1\"<\/code><\/pre>\n<p>Dopo il boot, eseguo Affinity e CPUsets in modo coerente:<\/p>\n<pre><code>Raggruppare gli IRQ #\nfor i in $(grep -E 'eth0|nvme' \/proc\/interrupts | awk -F: '{print $1}'); do\n  echo 3 &gt; \/proc\/irq\/$i\/smp_affinity_list   # CPU 0-1\ndone\n\n# Fissare un servizio critico in termini di latenza\ntaskset -c 2-3 \/usr\/bin\/il_mio_servizio\n\n# cgroup-cpuset per i servizi di sistema (esempio)\nmkdir -p \/sys\/fs\/cgroup\/cpuset\/housekeeping\necho 0-1,8-9 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.cpus\necho 0 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.mems\necho $$ &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cgroup.procs<\/code><\/pre>\n<p>Nelle unit\u00e0 systemd utilizzo inoltre <strong>CPUAffinity=<\/strong> oppure <strong>AllowedCPUs=<\/strong>, affinch\u00e9 i servizi utilizzino sempre i kernel corretti.<\/p>\n\n<h2>Diagnosi: verificare se i nuclei sono davvero silenziosi<\/h2>\n<p>Controllo lo stato di riposo dei miei core con pochi semplici passaggi:\n\u2013 \/proc\/interrupts: il contatore aumenta sulle CPU isolate? Se s\u00ec, correggere l\u2019affinit\u00e0 IRQ.\n\u2013 \/proc\/timer_list: identificare timer inattesi sui core NO_HZ_FULL.\n\u2013 ftrace\/perf: rendere visibili wakeup, softirq ed eventi di schedulazione.\n\u2013 turbostat: verificare i tempi di permanenza negli stati C.\nSe sui core inattivi si verificano ancora softirq (NET_RX, TIMER), quasi sempre si tratta di un problema di distribuzione o di driver.<\/p>\n\n<h2>Interazione con PREEMPT_RT e i thread RT<\/h2>\n<p><strong>PREEMPT_RT<\/strong> riduce le latenze integrando la preemption a livello profondo nel kernel. In combinazione con NO_HZ_FULL, ci\u00f2 pu\u00f2 fornire ottimi risultati quando gli IRQ vengono eseguiti come thread e rimangono rigorosamente su CPU dedicate alle attivit\u00e0 di housekeeping. Importante: non distribuire eccessivamente i thread RT, ma fissarli in modo rigoroso e controllarne i percorsi di memoria (NUMA, page fault). Mantengo sempre i thread RT su core isolati \u201eda soli\u201c, in modo che nessun tick venga restituito a causa della creazione di un secondo task eseguibile.<\/p>\n\n<h2>Quando il sistema \u201cFull Tickless\u201d non conviene<\/h2>\n<p>Non utilizzo NO_HZ_FULL quando:\n\u2013 Vengono generati continuamente molti task di breve durata (ad es. picchi di Fork\/Exec).\n\u2013 Il carico di lavoro \u00e8 fortemente sincronizzato e impone continui cambi di core.\n\u2013 La piattaforma non raggiunge stati C puliti o il TSC \u00e8 instabile.\nIn questi casi, un funzionamento pulito <strong>Assegnazione fissa degli IRQ e della CPU<\/strong> spesso superiore al costo di un isolamento completo.<\/p>\n\n<h2>Aspetti dettagliati della produzione: monitoraggio e funzionamento<\/h2>\n<p>Negli ambienti di produzione metto in guardia dai cambiamenti \u201einsidiosi\u201c: un aggiornamento del kernel, un nuovo agente o una mappatura IRQ modificata possono compromettere la stabilit\u00e0 dei kernel. Pertanto, metto in atto:\n\u2013 Uno script \u201eGuardrail\u201c che, dopo il riavvio, verifica l\u2019affinit\u00e0, i CPUset e le impostazioni RCU.\n\u2013 Metriche relative a wakeup\/s, permanenza negli stati C e latenza p99,9.\n\u2013 Periodiche <strong>Test di regressione<\/strong> con carichi di lavoro identici.\nSolo cos\u00ec \u00e8 possibile preservare in modo affidabile il vantaggio del funzionamento tickless.<\/p>\n\n<h2>Eliminare in modo mirato le fonti di jitter<\/h2>\n<p>Oltre agli IRQ, spesso causano <strong>Timer nello spazio utente<\/strong> (sleep\/usleep\/timerfd) per modelli instabili. Lavoro con <em>timer slack<\/em> (prctl o \/proc) e raggruppo le scadenze, in modo che il kernel pianifichi un numero minore di risvegli singoli. Anche i GC in background nei runtime gestiti (JVM, Go) li pianifico in base al tempo o li isolo su core dedicati alla gestione interna. L'obiettivo \u00e8 sempre quello di consentire sui core NO_HZ_FULL solo i risvegli assolutamente necessari.<\/p>\n\n<h2>Interpretazione dei KPI: mettere in luce i compromessi<\/h2>\n<p>Non valuto solo i valori medi, ma anche i <strong>Distribuzione<\/strong>: p50, p95, p99,9 e massimo. Un andamento tipico: la latenza di coda diminuisce notevolmente, la velocit\u00e0 di trasmissione media rimane invariata o aumenta leggermente e la permanenza in C-State si riduce. Se invece riscontro un jitter migliorato, ma una velocit\u00e0 di trasmissione sensibilmente inferiore, adeguo la politica di frequenza della CPU o aumento con cautela il numero di core inattivi, in modo che le code non si intasino.<\/p>\n\n<h2>Lista di controllo prima di attivare NO_HZ_FULL<\/h2>\n<p>\n\u2013 Funzionalit\u00e0 del kernel: CONFIG_NO_HZ_FULL, timer ad alta risoluzione attivo<br\/>\n\u2013 Ruoli chiari delle CPU: CPU di gestione interna definite per ciascun nodo NUMA<br\/>\n\u2013 Offload IRQ e RCU: irqaffinity e rcu_nocbs impostati in modo coerente<br\/>\n\u2013 Posizionamento dei servizi: documentazione e test relativi al \"pinning\" di systemd\/cgroups<br\/>\n\u2013 Configurazione di misurazione: carichi di lavoro riproducibili, KPI significativi, confronto <em>prima\/dopo<\/em><br\/>\n\u2013 Piano di rollback: voce di avvio disponibile senza NO_HZ_FULL\n<\/p>\n\n<h2>Ostacoli comuni e soluzioni<\/h2>\n\n<p>Vedo spesso che i servizi di sistema vengono eseguiti su core isolati e che il <strong>Isolamento<\/strong> ridurne l'efficacia. A tal fine sono utili systemd-Affinity, i CPUset dei cgroup e una documentazione chiara dei servizi. Anche i posizionamenti errati in ambito NUMA causano accessi remoti superflui e picchi di latenza. Associo rigorosamente la memoria e i thread al rispettivo nodo, in modo che i percorsi siano brevi e coerenti <strong>soggiorno<\/strong>. Una distribuzione poco chiara degli IRQ \u00e8 il terzo problema classico, per questo raggruppo le code molto trafficate sulle CPU dedicate alle attivit\u00e0 di manutenzione.<\/p>\n\n<h2>Breve bilancio per la pratica<\/h2>\n\n<p>Il sito <strong>senza ticchettio<\/strong> Il kernel riduce i tick fastidiosi, risparmia energia e crea finestre temporali affidabili per i carichi di lavoro sensibili. Con \u201cTickless Idle\u201d ottengo rapidamente miglioramenti in termini di efficienza, mentre \u201cFull Tickless\u201d garantisce una maggiore tranquillit\u00e0 sui core isolati. L'effetto maggiore lo noto quando raggruppo in modo ordinato IRQ, RCU e attivit\u00e0 in background sulle CPU dedicate alla gestione interna. Senza misurazioni non si va da nessuna parte: latenza, jitter, consumo energetico e throughput mi indicano se l\u2019ottimizzazione sta dando i suoi frutti. In questo modo utilizzo la modalit\u00e0 tickless in modo mirato e ottengo il massimo dal <strong>scheduler<\/strong> fuori.<\/p>","protected":false},"excerpt":{"rendered":"<p>Il kernel tickless spiegato in modo semplice: vantaggi, rischi e ottimizzazione del kernel per server, HPC e sistemi a bassa latenza.<\/p>","protected":false},"author":1,"featured_media":21500,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21507","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":"60","_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":"tickless mode","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":"21500","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21507","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=21507"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21507\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21500"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}