A Kernel senza zecca riduce i risvegli inutili della CPU e quindi riduce attivamente i requisiti energetici del vostro server senza perdere la reattività sotto carico. Vi mostrerò passo dopo passo come ridurre al minimo il consumo di energia della Kernel configurare, leggere i valori misurati e pianificare i carichi di lavoro in modo da armonizzare notevolmente le prestazioni e i costi dell'elettricità.
Punti centrali
I punti seguenti illustrano le fasi e le correlazioni più importanti.
- Senza solletico Timer: interrupt controllati dalla domanda invece di ticchettii periodici
- Energia risparmiare: Mantenere più a lungo gli stati C profondi, ridurre i risvegli
- NO_HZ Opzioni: Usare CONFIG_NO_HZ_IDLE e CONFIG_NO_HZ_FULL
- scheduler Messa a punto: carico del bundle, impostazione dell'affinità di interrupt
- Monitoraggio Primo: misurazione prima/dopo per ottenere effetti evidenti
La modalità Tickless spiegata brevemente
Un classico di LinuxKernel risveglia ogni CPU a intervalli fissi, spesso da 100 a 1000 volte al secondo. Questo costa in modo misurabile Energia, anche se non c'è nessun task in attesa. La modalità Tickless sostituisce questa periodicità con interrupt temporizzati controllati dalla domanda. Di conseguenza, la CPU rimane in uno stato di sonno profondo più a lungo fino a quando non si verifica un evento. Secondo [1], è proprio questo comportamento ad aumentare l'efficienza, perché vengono eliminati i risvegli non necessari e si riduce il carico termico. Uso Tickless quando i sistemi hanno carichi fortemente fluttuanti e devono passare in modo netto dall'attività al riposo.
Perché Tickless aumenta l'efficienza energetica
Se una CPU rimane inattiva, i ticchettii rigidi utilizzati per prevenire le basse Stati C e risvegliare i core in continuazione. Questo ha generato più Calore di scarto e costringe le ventole a funzionare a velocità più elevate. Tickless elimina questa sveglia permanente e prolunga le fasi di idle. Ho osservato un consumo energetico inferiore in modalità idle e curve di temperatura più uniformi per host Web e API con carichi di lavoro fluttuanti. Nelle grandi server farm, i piccoli risparmi per nodo si sommano a importi in euro notevoli sulla bolletta dell'elettricità. La piattaforma rimane più silenziosa e i picchi di carico possono essere attenuati in modo più affidabile.
Modalità e opzioni del kernel in sintesi
Distinguo due approcci principali: Tickless Idle e Tickless Full. Tickless Idle mette in pausa il periodico finché non ci sono attività in sospeso, e riproduce il suo La forza soprattutto nelle fasi di inattività. Tickless Full (NO_HZ_FULL) riduce i ticchettii per i core selezionati anche durante il funzionamento, il che può ridurre le latenze e gli switch di contesto. Le distribuzioni moderne spesso attivano NO_HZ_IDLE per impostazione predefinita, mentre NO_HZ_FULL richiede una messa a punto specifica. Si noti che le modalità estese richiedono una regolazione fine dell'affinità degli interrupt e dell'isolamento per garantire che il Vantaggi non si esaurisce a causa di risvegli casuali.
| Modalità/Opzione | Effetto | Adatto per | Note |
|---|---|---|---|
| CONFIG_NO_HZ_IDLE | Ticchettii di sospensione in modalità idle | Carico generale del server con fasi di inattività | Spesso attivo per impostazione predefinita, basso I rischi |
| CONFIG_NO_HZ_FULL | Ridurre al minimo i ticchettii per nucleo durante il funzionamento | Bassa latenza, HPC, core selezionati | Isolamento del core e affinità IRQ puliti Piano |
| isolcpus, rcu_nocbs | Core a basso rumore, meno risvegli dell'RCU | Carichi di lavoro in tempo reale | Solo pochi nuclei isolano, gli altri trasportano carico di sistema |
| Kernel ≥ LTS corrente | Nuovi percorsi di risparmio energetico, correzioni | Tutti i sistemi produttivi | Correzioni e guadagni di efficienza secondo [1] utilizzare |
Passo dopo passo: Impostazione del kernel e dei parametri di avvio
Inizierò con un inventario delle capacità del kernel. È possibile riconoscere se il kernel supporta il tickless dai flag di configurazione:
grep NO_HZ /boot/configurazione-$(uname -r)
grep HIGH_RES_TIMERS /boot/config-$(uname -r)
grep -E 'CPU_IDLE|INTEL_IDLE' /boot/config-$(uname -r)
Per NO_HZ_IDLE, il kernel della distribuzione è solitamente sufficiente. Per NO_HZ_FULL, definisco specificamente le CPU di housekeeping che si occupano dei task di sistema, degli IRQ e dei callback RCU. In genere, lascio la CPU 0-1 come housekeeping e imposto i core rimanenti in modalità DyTick:
# Esempio di GRUB-CMDLINE (adattato all'hardware):
GRUB_CMDLINE_LINUX="nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15 irqaffinity=0-1 nmi_watchdog=0"
Importante: almeno un core deve rimanere in housekeeping, altrimenti c'è il rischio di stalli dell'RCU. Dopo aver aggiornato la configurazione di GRUB e riavviato, controllo le impostazioni attive:
cat /sys/devices/system/cpu/nohz_full # elenca le CPU NO_HZ_FULL
cat /sys/devices/system/cpu/isolated # elenca le CPU isolate
cat /proc/cmdline # verifica i parametri di boot
Ho anche attivato i timer ad alta risoluzione e i driver specifici per l'idle (ad esempio intel_idle). Entrambi migliorano la granularità dei timer e la profondità degli stati di sospensione. Se si usa irqbalance, configurare i core bloccati in modo che l'affinità non migri verso le CPU isolate:
# Esempio: IRQBALANCE_BANNED_CPUS in /etc/irqbalance/irqbalance.env
IRQBALANCE_BANNED_CPUS=0x0003 # CPU 0-1 consentite, altre bloccate (formato della maschera per sistema)
Quindi verifico che i tick siano effettivamente assenti osservando i successivi risvegli per CPU:
sudo cat /proc/timer_list | grep -A2 'next event' | sed -n '1,60p'
Nelle fasi di inattività, gli eventi successivi devono essere chiaramente nel futuro o completamente assenti se non ci sono timer.
Disciplina della misurazione: strumenti e figure chiave
Senza misurazioni, qualsiasi ottimizzazione rimane cieca. Registro i valori di base e li confronto dopo ogni modifica. Hanno dimostrato il loro valore:
- powertopWakeup-from-idle/s, top originator, residenza in stato C
- turbostatFrequenze, stati C del pacchetto e del nucleo, prestazioni RAPL
- stat perfInterruttori contestuali, interrupt del timer, cicli, istruzioni
- /proc/interruzioniDistribuzione IRQ per CPU
- pidstat/iostatCaratteristiche di processo e di I/O
# Acquisizione di 10 minuti di base in modalità idle
sudo turbostat --Summary --interval 5 --quiet --show PkgWatt,BUS,CPU,CPU,CPU,MHz
sudo powertop --time=600 --html=/tmp/powertop_baseline.html
Mappa di calore degli interrupt dell'#
watch -n2 "cat /proc/interrupts | sed -n "1,30p''
# Commutazioni contestuali ed eventi del timer
perf stat -a --delay 5000 --timeout 60000 -e cs,task-clock,cpu-clock,irq_vectors:local_timer
In ogni caso, documento Consumo di energia inattiva (PkgWatt), quote di stato C, wakeup/s e metriche di latenza (p95/p99) del mio carico di lavoro rilevante. Anche piccole differenze diventano evidenti nel corso delle settimane.
Virtualizzazione, container e tickless nello stack
L'hypervisor e i guest generano insieme molti Timer e risvegli, ad esempio tramite cron, logging e agenti. Riduco questa catena attivando Tickless nell'hypervisor e nei sistemi guest. In questo modo si eliminano i doppi risvegli e le CPU virtuali rimangono silenziose più a lungo. In ambienti Kubernetes o microservizi, il livello di rumore di fondo si riduce in modo misurabile. Sincronizzo anche i tempi dei pod e dei batch, in modo che si creino finestre di inattività più lunghe e il Risparmio salire.
Negli ambienti KVM, pianifico il pinning delle vCPU e l'affinità degli IRQ insieme: lego gli IRQ delle vNIC o dei vBlock più rumorosi alle CPU di mantenimento, mentre i carichi di lavoro più tranquilli ai core isolati. Sul lato guest, disattivo le fonti di timer superflue, riduco le frequenze di cron e uso timer systemd con una precisione generosa (AccuracySec) in modo che gli eventi siano raggruppati in modo più naturale. In questo modo le fasi di inattività diventano più lunghe e l'hypervisor ne trae un doppio vantaggio, perché ci sono meno uscite e ingressi nelle macchine virtuali.
Configurazione pratica: Profili di potenza, governor, interrupt
Di solito uso il governatore per le reazioni rapide schedutil perché intercetta dinamicamente i salti di carico. Lascio attivi gli stati C a meno che non siano prioritarie le latenze estremamente brevi. Lego gli IRQ rumorosi a core selezionati e mantengo gli altri core liberi in modo che possano dormire profondamente. Programmo i lavori batch, i backup e gli aggiornamenti in blocchi per raggruppare le fasi di quiete. Se volete saperne di più, potete trovare informazioni di base su Scalatura della frequenza della CPU, che coordino strettamente con Tickless per usare i suggerimenti con parsimonia.
Inoltre, regolo il bias di preferenza energetica (EPP/EPB) delle moderne CPU in modo che i boost si attivino solo quando necessario e le residenze inattive rimangano elevate. I servizi con latenza tollerante ricevono valori di slack del timer più grandi (systemd: TimerSlackNSec=), controllo i lavori periodici tramite timer systemd con AccuracySec e RandomisedDelaySec. Questo riduce i carichi sui bordi e crea finestre di inattività più lunghe e contigue.
# Esempio: Assegnare IRQ in modo specifico (attenzione: controllare il numero di IRQ)
echo 0-1 | sudo tee /proc/irq/XX/smp_affinity_list # lega l'IRQ all'housekeeping
# imposta il timer di systemd in modo cooperativo (estratto di un'unità .timer)
PrecisioneSec=5min
RandomisedDelaySec=30min
Persistente=vero
Usare NUMA e il load bundling in modo sensato
Negli host multi-core e NUMA, aumento il Efficienza, concentrando deliberatamente il carico su pochi core. Di conseguenza, i core liberi cadono sempre più a lungo negli stati C. Mi assicuro di mantenere gli accessi alla memoria NUMA-local per evitare inutili aumenti. Lo scheduler di Linux aiuta, ma il pinning manuale dei thread caldi è spesso il tocco finale. Con Tickless, questo pinning è più efficace perché i core isolati non sono risvegliati dai periodici e quindi il vero Riposo hanno.
In pratica, preferisco assegnare i thread pesanti dal punto di vista dell'I/O allo stesso nodo NUMA e isolare i servizi ad alta intensità di CPU ad alcuni core di questo nodo. I gruppi C (cpuset, cpu) aiutano a tracciare confini chiari. Controllo Transparent Huge Pages e AutoNUMA in base al carico di lavoro: possono aiutare, ma contrastano il jitter di latenza. È importante che almeno un nodo mantenga una capacità di housekeeping sufficiente, in modo che i task di sistema non si riversino sui core critici.
Bilanciamento e misurazione dei requisiti di latenza
Alcuni carichi di lavoro in tempo reale o di trading richiedono il più breve tempo possibile. Tempi di risposta. Pertanto, eseguo test con campioni vicini alla produzione e confronto i percentili di latenza prima e dopo le modifiche senza tick. NO_HZ_FULL può ridurre i cambiamenti di contesto e il rumore del timer, ma gli stati C profondi occasionalmente allungano i percorsi di risveglio. Con la telemetria per gli stati C, la frequenza, le latenze dei pacchetti e il jitter, prendo decisioni informate. Coloro che si occupano anche della manutenzione del kernel ne traggono diversi vantaggi: la messa a punto delle prestazioni e le correzioni di sicurezza si intersecano, come dimostra la pratica; il mio riferimento a Ottimizzazione del kernel, che integro costantemente nelle finestre di manutenzione.
Ho testato in particolare scenari di burst (fasi brevi e intense) e ho correlato i picchi di latenza con la frequenza e le tracce di stati C. In questo caso sono utili le misurazioni con un PPE fisso, oppure un breve test con stati C limitati per visualizzare la percentuale di latenza di risveglio. Se si utilizzano core NO_HZ_FULL, mi assicuro che le CPU di mantenimento non siano sottoalimentate, altrimenti c'è il rischio di avvisi RCU o di jitter sporadico.
Sicurezza: i kernel attuali pagano due volte
Tengo i sistemi corrente, perché i nuovi kernel non solo affinano i percorsi di risparmio energetico, ma colmano anche le lacune. I rapporti sulle vulnerabilità del kernel mostrano che gli aggressori sono stati occasionalmente in grado di estendere i diritti con poco sforzo. Con gli aggiornamenti, riduco questo rischio e allo stesso tempo garantisco i guadagni di efficienza dei meccanismi moderni [2]. Nel complesso, la sicurezza operativa aumenta e i tempi di inattività non pianificati non mettono a dura prova né i nervi né il budget. È proprio questa combinazione di sicurezza e Efficienza rende gli aggiornamenti regolari una decisione facile.
Effetto data center: PUE, ventole, alimentatori
Un minor numero di risvegli riduce la Carico è possibile misurare l'efficienza del raffreddamento e della distribuzione dell'energia. I picchi della CPU sono più uniformi, le ventole funzionano meno frequentemente al limite e gli alimentatori lavorano in modo più efficiente. Questo effetto domino ha un impatto diretto sul PUE di un sito. Se volete saperne di più, date un'occhiata all'argomento centro dati verde e utilizza Tickless come elemento costitutivo di un sistema olistico di gestione dell'energia. Pianifico sempre le misure insieme, perché l'hardware, il sistema operativo e il carico di lavoro contribuiscono insieme alla Risparmio con.
Pratica di WordPress, PHP e database
Su stack CMS con molti brevi Richieste di informazioni Traggo grande beneficio dai livelli di cache e dalla messa a punto pulita di PHP-FPM. Mantengo opcache al caldo, sigillo i plugin Chatty e minimizzo il rumore di cron impilando le finestre dei task. Ai database vengono assegnati chiari periodi di manutenzione, in modo che non spingano i picchi di I/O nel carico giornaliero. Insieme a Tickless, il rumore di fondo diminuisce e il server cade in idle più velocemente. In questo modo, la piattaforma combina le prestazioni per watt senza che gli utenti avvertano un'eccessiva pressione. Perdite vedere.
In particolare, riduco i trigger cron di WordPress, sposto il lavoro ricorrente su timer systemd con coalescenza e mantengo i lavoratori PHP FPM dimensionati in modo tale da servire brevi ondate di carico senza mantenere un'elevata base permanente di lavoratori aperti. I database traggono vantaggio da finestre di autovuoto chiare (strozzare/spostare quando necessario) e da "blocchi di manutenzione" coerenti. Preferisco raggruppare ogni attività regolare, ma non critica dal punto di vista del tempo, in un modo a grana grossa, piuttosto che spararla in pochi secondi.
BIOS/UEFI e percorsi hardware
Ho già impostato le basi nel BIOS/UEFI: attivare gli stati C profondi del pacchetto, utilizzare substrati ASPM/PCIe L1 e non disattivare le funzioni di risparmio energetico su tutta la linea. Limito la profondità degli stati C solo in fase di test, se lo richiedono obiettivi di latenza speciali. Le schede di rete e i controller NVMe traggono vantaggio dalle modalità di risparmio energetico; tuttavia, verifico se una gestione energetica aggressiva genera picchi di latenza. Vale la pena di effettuare un bilanciamento sensibile: una marcia in meno al massimo risparmio energetico può avere un grande effetto nell'intervallo di latenza di 99p.
Rete e storage: continuare a spingere i wakeup
Lo stack di rete spesso attiva molti IRQ. Aumento con attenzione i parametri di coalescenza per attenuare le tempeste di interrupt senza peggiorare inutilmente la latenza:
Esempio # (regolare i valori in base al carico di lavoro!)
sudo ethtool -C eth0 rx-usecs 16 rx-frames 16 tx-usecs 16 tx-frames 16
Scaliamo GRO/LRO e RSS in modo che corrispondano alla topologia della CPU, in modo che pochi core sopportino la maggior parte del rumore degli interrupt. Per quanto riguarda l'archiviazione, controllo che le proprietà del dispositivo (ad esempio NVMe-APST) siano già ottimizzate e che i picchi di carico non si estendano a picchi giornalieri a causa di lavori in background (scrub, rebuild). L'obiettivo è spingere i burst di I/O pianificabili in finestre definite.
Errori e risoluzione dei problemi
Le configurazioni Tickless raramente falliscono a causa della meccanica di base, più spesso a causa della messa a punto:
- L'RCU è in stalloSe ciò si verifica dopo NO_HZ_FULL, la causa è solitamente un numero insufficiente di CPU di housekeeping o un carico eccessivo di IRQ sui core isolati. Pianificare una maggiore capacità di housekeeping.
- Risvegli inaspettatiPowertop mostra i colpevoli. Le fonti più frequenti sono gli agenti di telemetria, gli intervalli di tempo brevi o i log di chat.
- Distribuzione irregolare degli IRQControllare /proc/interruzioni e regolare le affinità; configurare correttamente irqbalance.
- Jitter di latenzaLa profondità dello stato C, l'EPP e la coalescenza variano gradualmente e osservano p99; spesso sono sufficienti piccoli aggiustamenti.
Per ottenere risultati riproducibili, lavoro con finestre di modifica, punti di rollback chiari e parametri documentati con precisione. Ogni modifica viene sottoposta a un giro di misura e solo allora si passa alla fase successiva.
Passi concreti per l'avvio
Inizierò con una corrente Kernel e verifico se NO_HZ_IDLE è attivo. Quindi misuro i valori di base: consumo energetico in idle, temperatura, stati C, frequenza IRQ e latenza. Quindi attivo le opzioni tickless e ripeto le misurazioni. Se trovo dei risparmi, salvo la configurazione nei repository del codice e della documentazione. Se necessario, provo NO_HZ_FULL per alcuni core selezionati e li isolo con un'accurata allocazione degli IRQ in modo che il Effetto rimane visibile.
La mia procedura pragmatica:
- Raccogliere la linea di base (10-15 minuti di inattività + breve test di carico, salvare le metriche)
- Controllare NO_HZ_IDLE, convalidare il timer ad alta risoluzione e il driver di inattività
- Regolare l'affinità IRQ e l'irqbalance, IRQ ad alto volume in housekeeping
- Aumentare la coalescenza dei timer (timer systemd, TimerSlack, intervalli cron)
- Facoltativo: NO_HZ_FULL sui core selezionati + rcu_nocbs, per lasciare libere almeno 1-2 CPU di mantenimento.
- Regolate il pinning di NUMA e della CPU, i limiti di Cgroup e le finestre batch.
- Confronto prima/dopo, documentazione delle decisioni
Il mio breve riassunto
Tickless porta un contributo misurabile Energia- e vantaggi termici, soprattutto per carichi di lavoro flessibili con fasi di inattività più lunghe. Inizio con NO_HZ_IDLE e lo combino con profili di potenza ragionevoli. Poi lavoro sulle affinità IRQ, sul raggruppamento dei carichi e sulla disciplina delle misure. Per gli scenari particolarmente critici in termini di latenza, utilizzo NO_HZ_FULL in dosi e valuto il compromesso con test realistici [1]. L'unione di tecnologia, progettazione del carico di lavoro e monitoraggio consente di utilizzare la tecnologia e la tecnologia di monitoraggio. Potenzialità di questa funzione kernel in modo permanente.
