Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Power Management Guide
Red Hat Enterprise Linux 6
Gestione consumo energetico su Red Hat Enterprise Linux 6
Edizione 1.0
Sommario
Questo documento affronta il metodo attraverso il quale è possibile gestire in modo efficiente il consumo energetico su sistemi Red Hat Enterprise Linux 6. Le seguenti sezioni riportano le diverse tecniche in grado di diminuire il consumo energetico (sia per il server che per i laptop), e come ogni tecnica è in grado di influenzare le prestazioni del sistema.
Capitolo 1. Panoramica
La gestione energetica è uno degli argomenti più importanti per il miglioramento di Red Hat Enterprise Linux 6. Limitare il consumo energetico dei computer è uno degli aspetti più importanti per il green IT (informatica ecologica), essa infatti si estende fino ad includere i materiali reciclabili, la produzione di sistemi eco-friendly, ed una pianificazione e design idonei di sistemi eco-friendly. In questo documento vengono fornite le informazioni e le linee guida per una gestione energetica dei sistemi che eseguono Red Hat Enterprise Linux 6.
1.1. Importanza della gestione energetica
La parte principale della gestione energetica è rappresentata dalla comprensione dei processi usati per ottimizzare efficacemente il consumo energetico di ogni componente del sistema. Ciò richiede lo studio di diversi compiti eseguiti del sistema, e la configurazione di ogni componente per assicurare che le rispettive prestazioni siano idonee al compito da svolgere.
I motivi principali per la gestione energetica sono:
- riduzione generale del consumo energetico per ridurre i costi
Una gestione energetica corretta risulterà in una:
- un livello termico più basso per i server e per i centri informatici
- costi secondari ridotti, incluso sistemi di raffreddamento, spazio, cavi, generatori e uninterruptible power supplies (UPS)
- estensione ciclo di vita della betteria dei laptop
- output più basso di biossido di carbonio
- soddisfare i requisiti legali o le regole governative relative all'IT ecologico, per esempio Energy Star
- soddisfare le linee guida aziendali per nuovi sistemi
La diminuzione del consumo energetico di un componente specifico (o dell'intero sistema) comporterà un abbassamento del livello termico e naturalmente anche delle prestazioni. Per questo motivo è consigliato studiare e testare la diminuzione delle prestazioni sostenibile dalle varie configurazioni, ed in modo particolare nei sistemi mission-critical.
Attraverso lo studio dei diversi compiti eseguiti del sistema e configurando ogni componente in modo da assicurare che le sue prestazioni siano sufficienti per il lavoro da svolgere, sarà possibile risparmiare energia, generare un livello termico più basso ed ottimizzare il ciclo di vita della batteria per i laptop. La maggior parte dei principi per l'analisi e la regolazione di un sistema, in relazione al consumo energetico, sono simili a quelli implementati nella regolazione delle prestazioni. In alcuni casi la gestione energetica e la regolazione delle prestazioni rappresentano approcci opposti per la configurazione del sistema, poichè i sistemi sono generalmente ottimizzati per una migliore prestazione o potenza. Questo manuale descrive i tool forniti da Red Hat e le tecniche sviluppate per assistervi in questo processo.
Red Hat Enterprise Linux 6 è già in possesso di numerose funzioni per la gestione energetica abilitate per impostazione predefinita. Esse sono state selezionate in modo da non interessare le prestazioni di un server tipico o desktop. Tuttavia, per un uso specifico dove sono richieste prestazioni massime, una latenza bassa o prestazioni elevate della CPU, sarà necessario ricontrollare le suddette impostazioni.
Per decidere se ottimizzare le proprie macchine usando le tecniche descritte in questo documento fatevi alcune domande:
- Domanda: Devo eseguire l'ottimizzazione?
- Domanda: Qual'è livello di ottimizzazione è necessario?
- Domanda: Il processo di ottimizzazione è in grado di diminuire le prestazioni ad un livello non accettabile?
- Domanda: Il tempo e le risorse necessarie per l'ottimizzazione di un sistema possono superare i benefici raggiungibili?
Domanda:
Devo eseguire l'ottimizzazione?
Risposta:
L'importanza di un processo di ottimizzazione del consumo energetico dipende dall'implementazione della vostra azienda di alcune linee guida da seguire o dalla rpesenza di alcune regole da soddisfare.
Domanda:
Qual'è livello di ottimizzazione è necessario?
Risposta:
Alcune delle tecniche da noi fornite non richiedono l'esecuzione completa dei processi di verifica e di analisi della macchina, poichè esse offrono un insieme di ottimizzazioni le quali migliorano l'uso di energia. Essi non saranno ovviamente ai livelli dei sistemi sui quali è stata eseguita una verifica ed analisi manuale, ma rappresentano un buon compromesso.
Domanda:
Il processo di ottimizzazione è in grado di diminuire le prestazioni ad un livello non accettabile?
Risposta:
La maggior parte delle tecniche descritte in questo documento interessano le prestazioni del sistema. Se desiderate inplementare una gestione energetica che và oltre alle impostazioni predefinite già presenti con Red Hat Enterprise Linux 6, è consigliato controllare le prestazioni del sistema dopo aver eseguito l'ottimizzazione e decidere se un abbassamento delle stesse è accettabile.
Domanda:
Il tempo e le risorse necessarie per l'ottimizzazione di un sistema possono superare i benefici raggiungibili?
Risposta:
Generalmente non vale la pena eseguire una ottimizzazione manuale di un singolo sistema dopo aver eseguito l'intero processo, poichè il tempo ed i costi necessari superano di gran lunga i benefici che si possono ottenere durante il ciclo di vita di una singola macchina. Allo stesso tempo se si utilizzano 10000 sistemi desktop i quali utilizzano la stessa impostazione e configurazione, allora è consigliato implementare una impostazione ottimizzata su tutte le macchine.
Le seguenti sezioni spiegano come prestazioni hardware ottimali siano in grado di interessare positivamente il sistema in termini di consumo energetico.
1.2. Principi di base sulla gestione energetica
Una gestione energetica efficace si basa sui seguenti principi:
Una CPU inattiva deve essere attivata solo quando necessario
Il kernel di Red Hat Enterprise Linux 5 utilizza un timer periodico per ogni CPU. Il suddetto timer impedisce la sospensione della CPU richiedendo la processazione di ogni evento del timer da parte della CPU stessa (gli eventi si susseguono dopo pochi millisecondi in base alle impostazioni), senza tenere in considerazione se uno o più processi è in esecuzione. La riduzione della frequenza in base alla quale si attiva una CPU ricopre un ruolo molto importante per una gestione energetica effettiva.
A causa di ciò il kernel di Linux in Red Hat Enterprise Linux 6 elimina il timer periodico: ne risulta che lo stato inattivo di una CPU è ora tickless. Ciò impedisce alla CPU di utilizzare alimentazione non necessaria durante uno stato inattivo. Tuttavia i benefici di questa funzione possono essere controbilanciati se il sistema presenta applicazioni in grado di creare eventi del timer non necessari. Eventi tipo controlli di modifiche del volume, movimenti del mouse ed altri eventi simili, sono esempi di tali eventi.
Red Hat Enterprise Linux 6 include i tool attraverso i quali è possibile identificare e verificare le applicazioni in base all'utilizzo della CPU. Consultare Capitolo 2, Analisi e verifica della gestione energetica per informazioni.
I dispositivi e l'hardware non utilizzati devono essere completamente disabilitati
Applicabile per dispositivi con parti in movimento (per esempio, dischi fissi). Altresì, alcune applicazioni possono lasciare un dispositivo non utilizzato ancora abilitato "open"; se si verifica tale condizione il kernel crederà che tale dispositivo è ancora in uso, impedendo così al dispositivo stesso di entrare in uno stato di risparmio energetico.
Un'attività bassa deve tradursi in un livello di potenza 'wattaggio' basso
In numerosi casi tuttavia ciò dipende dall'hardware e dalla corretta configurazione del BIOS. I componenti di sistemi vecchi spesso non presentano alcun supporto per le nuove funzioni supportate ora da Red Hat Enterprise Linux 6. Assicuratevi di utilizzare l'ultimissimo firmware ufficiale per i vostri sistemi e che nelle sezioni per la gestione energetica o per la configurazione del dispositivo del BIOS, le funzioni di gestione energetica risultino abilitate. Alcune funzioni includono:
- SpeedStep
- PowerNow!
- Cool'n'Quiet
- ACPI (C state)
- Smart
Se l'hardware presenta il supporto per queste funzioni e le stesse sono abilitate nel BIOS, Red Hat Enterprise Linux 6 le utilizzerà per impostazione predefinita.
Stati diversi della CPU ed effetti correlati
Le CPU moderne insieme all'Advanced Configuration and Power Interface (ACPI) presentano diversi stati. Essi sono i seguenti:
- Sleep (stati-C)
- Frequency (stati-P)
- Outout Heat (stati-T o "stati termici")
Una CPU in esecuzione con lo stato più basso di inattività consuma una quantità di watt minore, ma al tempo stesso richiederà una quantità di tempo superiore per attivarsi se necessario. In casi molto rari tale comportamento richiederà alla CPU di riattivarsi immediatamente dopo uno stato inattivo. Questa situazione risulterà in una CPU perennemente occupata con una conseguente perdita di risparmio energetico se è stato utilizzato un stato diverso.
Una macchina spenta utilizza una quantità di alimentazione più bassa
Uno dei modi migliori per risparmiare energia è quello di disalimentare i sistemi. Per esempio, la vostra azienda è in grado di sviluppare una cultura aziendale basata su un "IT ecologico" con direttive come lo spegnimento delle mecchine durante il pasto o dopo gli orari lavorativi. È possibile altresì consolidare diversi server fisici in un server più grande e virtualizzarli usando le tecnologie di virtualizzazione disponibili con Red Hat Enterprise Linux 6.
Capitolo 2. Analisi e verifica della gestione energetica
2.1. Panoramica sui processi di verifica ed analisi
La verifica, l'analisi e la regolazione manuale di un singolo sistema rappresenta generalmente una eccezione poichè il tempo ed i costi necessari per queste operazioni supera i benefici che si possono ottenere. Tuttavia, eseguendo solo una volta i suddetti compiti per un gran numero di sistemi simili dove sarà possibile riutilizzare le stesse impostazioni per tutti i sistemi può essere molto utile. Per esempio, considerate l'impiego di migliaia di sistemi desktop, o un cluster HPC dove le macchine sono quasi identiche. Un altro motivo per l'analisi e la verifica è quello di fornire una base di confronto utilizzabile per rilevare modifiche o regressi nei conportamenti del sistema. I risultati di queste analisi possono essere molto utili in casi in cui l'hardware, BIOS, o gli aggiornamenti software si verificano ad una cadenza regolare e l'utente non desidera alcun problema relativo al consumo energetico. Generalmente un processo di analisi e verifica completo è in grado di conferire un quadro completo su tutto ciò che si verifica in un particolare sistema.
La verifica e l'analisi di un sistema in relazione al consumo energetico è un processo molto complesso anche utilizzando i sistemi più moderni disponibili. Numerosi sistemi non sono in grado di fornire i mezzi necessari per misurare l'energia usata tramite il software. Nonostante tutto sono presenti alcune eccezioni: la console di gestione ILO dei sistemi server Hewlett Packard presenta un modulo di gestione dell'alimentazione accessibile attraverso il web. IBM fornisce una soluzione simile nei propri moduli di gestione BladeCenter. Su alcuni sistemi Dell l'IT Assistant offre capacità di monitoraggio dell'alimentazione. Altri rivenditori possono offrire capacità simili per le proprie piattaforme server ma come sarà possibile notare non è presente una soluzione unica supportata da tutti i rivenditori. Se il vostro sistema non presenta alcun meccanismo interno per misurare il consumo energetico, sarà possibile utilizzare altri metodi. È possibile installare un alimentatore capace di fornire informazioni sul consumo energetico tramite l'USB. Il Gigabyte Odin GT 550 W PC è un esempio, altresì è disponibile del software specifico per la lettura dei valori con Linux tramite http://mgmt.sth.sze.hu/~andras/dev/gopsu/. Come ultima opzione sono disponibili contatori esterni per i watt come ad esempio Watts up? PRO il quale presenta un connettore USB.
La misurazione diretta del consumo energetico è spesso necessaria per massimizzare il più possibile il risparmio energetico. Fortunatamente sono disponibili altri mezzi per controllare la presenza di modifiche o per controllare il comportamento del sistema. Questo capitolo descrive i tool necessari.
2.2. PowerTOP
L'introduzione del tickless kernel in Red Hat Enterprise Linux 6 (consultare Sezione 3.4, «Tickless Kernel») permette alla CPU di entrare più frequentemente in uno stato inattivo riducendone così il consumo energetico e migliorando la gestione. Il nuovo tool PowerTOP identifica i componenti spedifici delle applicazioni spazio utente e del kernel che più frequentemente attivano la CPU. PowerTOP è stato utilizzato durante la fase di sviluppo per eseguire le verifiche descritte in Sezione 3.11, «Ottimizzazione Spazio utente», che hanno permesso la modifica di numerose applicazioni in questa release, riducendo di almeno dieci volte l'attivazione non necessaria della CPU.
Installare PowerTOP con il comando:
yum install powertop
Eseguire PowerTOP con il comando:
powertop
Da notare che sarà necessario eseguire PowerTOP con privilegi root per permettere all'applicazione di eseguire qualsiasi compito utile.
PowerTOP durante la sua esecuzione raccoglie le statistiche del sistema riproducendo un elenco di tutti i componenti che attivano più frequentemente la CPU. Altresì PowerTOP è in grado di fornire i suggerimenti per la riduzione del consumo energetico del sistema. Questi suggerimenti possono essere visualizzati nella parte bassa della schermata e specificano un tasto da premere per accettare i suggerimenti del PowerTOP. Poichè PowerTOP esegue aggiornamenti periodici, sarà possibile visualizzare nuovi aggiornamenti. In Figura 2.1, «PowerTOP in funzione», notate il suggerimento per
aumentare il tempo per il VM dirty writeback, ed il tasto (W) da premere per accettare il suggerimento.
Durante l'esecuzione PowerTOP acquisisce le formazioni dal sistema e le rappresenta all'interno di un numero di elenchi di informazioni molto importanti. Nella parte alta è presente un elenco nel quale viene riportato il periodo entro il quale le CPU core sono rimaste negli stati C e P. Più a lungo una CPU rimane in uno stato più alto C o P e meglio è (
C4 più alto di C3), esso rappresenta la regolazione del sistema più idonea per quanto riguarda l'utilizzo della CPU. L'obiettivo principale è quello di avere uno stato C o P più alto per il 90%, o maggiore, durante un periodo di inattività del sistema.
La seconda sezione di informazioni è un sommario dei processi di attivazione 'wakeup' al secondo della macchina. Il numero di wakeup al secondo rende l'idea delle prestazioni dei servizi o dispositivi e driver in relazione al consumo energetico sul sistema. Maggiore è il numero di wakeup al secondo maggiore è l'energia consumata, quindi un numero minore sarebbe l'impostazione ideale.
Successivamente, PowerTOP fornisce una stima sull'uso energetico attuale del sistema se disponibile. PowerTOP indicherà questa figura sui laptop in modalità batteria.
Qualsiasi stima sull'uso energetico viene seguita da un elenco dettagliato dei componenti che inviano più frequentemente i wakeup alla CPU. Nella parte alta dell'elenco sono presenti i componenti nei confronti dei quali sarà necessario eseguire una verifica più dettagliata per ottimizzare il sistema e ridurre l'uso di energia. Se sono componenti del kernel, (indicati dal nome del componente elencato in
<>), allora i wakeup sono spesso associati con un driver specifico che li genera. La regolazione dei driver generalmente ha bisogno di modifiche al kernel che oltrepassano lo scopo di questo documento. Tuttavia i processi eseguiti nello spazio utente che inviano segnali di wakeup sono più facilmente gestibili. Come prima cosa identificare se il servizio o l'applicazione deve essere eseguita su questo sistema, In caso contrario disattivarla. Per disabilitare un servizio permanentemente eseguire:
chkconfig servicename off
Per maggiori informazioni sull'attività del componente eseguire:
ps -awux | grep componentnamestrace -p processid
Se i dettagli si ripetono molto probabilmente si è in presenza di un ciclo di temporizzazione interno (busy-loop). Per la sua correzione sarà necessaria la modifica del codice all'interno del componente, ma tale processo và oltre lo scopo di questa guida.
Per finire PowerTOP è in grado di fornire suggerimenti per la riduzione del consumo energetico del sistema. Questi suggerimenti possono essere visualizzati nella parte bassa della schermata e specificano un tasto da premere per accettare i suggerimenti di PowerTOP. Poichè PowerTOP esegue aggiornamenti periodici, sarà possibile visualizzare nuovi aggiornamenti. In Figura 2.1, «PowerTOP in funzione», notate il suggerimento per
aumentare il tempo per il VM dirty writeback, ed il tasto (W) da premere per accettare il suggerimento. Queste modifiche saranno implementate solo dopo il riavvio del sistema. Per implementare permanentemente le modifiche PowerTOP mostra il comando esatto eseguito per questo procedimento. Aggiungere il comando al file /etc/rc.local con l'editor di testo preferito in modo da implementare le modifiche ogni qualvolta si riavvia il computer.
Figura 2.1. PowerTOP in funzione
Il sito web Less Watts pubblica un elenco di applicazioni che PowerTOP ha identificato per mantenere le CPU attive. Consultare http://www.lesswatts.org/projects/powertop/known.php.
2.3. Diskdevstat e netdevstat
Diskdevstat e netdevstat sono tool di SystemTap usati per raccogliere informazioni dettagliate sull'attività del disco e della rete di tutte le applicazioni in esecuzione su di un sistema. Questi tool si ispirano a PowerTOP, il quale mostra il numero di CPU wakeup per ogni applicazione al secondo (consultare Sezione 2.2, «PowerTOP»). Le informazioni raccolte dai suddetti tool permetteranno all'utente di identificare le applicazioni che consumano inutilmente energia le quali presentano numerose piccole operazioni I/O e no operazioni più grandi ma meno frequenti. Altri tool di monitoraggio in grado di misurare la velocità di trasferimento non aiutano ad identificare questo tipo d'uso.
Installare questi tool con SystemTap usando il comando:
yum install systemtap tuned-utils kernel-debuginfo
Eseguire i tool con il comando:
diskdevstat
o il comando:
netdevstat
Entrambi i comandi possono comprendere fino a tre parametri:
diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
- update_interval
- Il periodo in secondi tra gli aggiornamenti del display. Per impostazione predefinita:
5 - total_duration
- Il periodo in secondi dell'intera esecuzione. Per impostazione predefinita:
86400(1 giorno) - display_histogram
- Indica se usare gli istogrammi per tutti i dati raccolti alla fine della esecuzione.
L'output somiglia al PowerTOP. Di seguito viene riportato un output d'esempio di una esecuzione più lunga di diskdevstat su di un sistema Fedora 10 sul quale viene eseguito KDE 4.2:
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 15494 0 sda1 0 0.000 0.000 0.000 758 0.000 0.012 0.000 0logwatch 15520 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15549 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15585 0 sda1 0 0.000 0.000 0.000 108 0.001 0.002 0.000 perl 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 15429 0 sda1 0 0.000 0.000 0.000 62 0.009 0.009 0.000 crond 15379 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15473 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15415 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15433 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15425 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15375 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15477 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15469 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15419 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15481 0 sda1 0 0.000 0.000 0.000 61 0.000 0.001 0.000 crond 15355 0 sda1 0 0.000 0.000 0.000 37 0.000 0.014 0.001 laptop_mode 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd 15575 0 sda1 0 0.000 0.000 0.000 16 0.000 0.000 0.000 cat 15581 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15582 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15579 0 sda1 0 0.000 0.000 0.000 12 0.000 0.001 0.000 perl 15580 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 12 0.000 0.170 0.014 sh 15584 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15548 0 sda1 0 0.000 0.000 0.000 12 0.001 0.014 0.001 perl 15577 0 sda1 0 0.000 0.000 0.000 12 0.001 0.003 0.000 perl 15519 0 sda1 0 0.000 0.000 0.000 12 0.001 0.005 0.000 perl 15578 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15583 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15547 0 sda1 0 0.000 0.000 0.000 11 0.000 0.002 0.000 perl 15576 0 sda1 0 0.000 0.000 0.000 11 0.001 0.001 0.000 perl 15518 0 sda1 0 0.000 0.000 0.000 11 0.000 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 10 0.053 0.053 0.005 lm_lid.sh
Le colonne sono:
- PID
- l'ID del processo dell'applicazione
- UID
- l'ID utente con il quale le applicazioni sono in esecuzione
- DEV
- il dispositivo sul quale si è verificato l'I/O
- WRITE_CNT
- il numero totale di operazioni di scrittura
- WRITE_MIN
- il tempo più breve usato da due operazioni consecutive di scrittura (in secondi)
- WRITE_MAX
- il tempo più lungo usato da due operazioni consecutive di scrittura (in secondi)
- WRITE_AVG
- il tempo medio usato da due operazioni consecutive di scrittura (in secondi)
- READ_CNT
- il numero totale di operazioni di lettura
- READ_MIN
- il tempo più breve usato da due operazioni consecutive di lettura (in secondi)
- READ_MAX
- il tempo più lungo usato da due operazioni consecutive di lettura (in secondi)
- READ_AVG
- il tempo medio usato da due operazioni consecutive di lettura (in secondi)
- COMMAND
- il nome del processo
In questo esempio sono in particolare risalto tre applicazioni:
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd
Queste applicazioni hanno un
WRITE_CNT maggiore di 0, ciò significa che è stato eseguito un processo di scrittura durante la misurazione. Tra questi plasma risulta essere la peggior applicazione: infatti ha eseguito il maggior numero di operazioni di scrittura, e di conseguenza il tempo medio tra operazioni di scrittura è risultato il più basso. Per questo motivo Plasma rappresenta il miglior candidato da investigare se si desidera identificare le applicazioni più inefficienti in termini di consumo energetico.
Utilizzare i comandi strace e ltrace per esaminare le applicazioni in modo più dettagliato controllando tutte le chiamate dei sistemi di un dato ID del processo. In questo esempio sarà possibile eseguire:
strace -p 2789
In questo esempio l'output di
strace presentava un percorso ripetitivo ogni 45 secondi il quale apre un file cache dell'icona KDE dell'utente per un processo di scrittura seguito dalla chiusura del file. Tale operazione comportava una scrittura del disco fisso poichè i metadati del file (in particolare il periodo della modifica) venivano modificati. La correzione finale impedisce l'esecuzione di chiamate non necessarie senza il verificarsi di aggiornamenti per le icone.
2.4. Battery Life Tool Kit
Red Hat Enterprise Linux 6 introduce il Battery Life Tool Kit (BLTK), una suite di prova in grado di simulare ed analizzare le prestazioni ed il ciclo di vita di una batteria. BLTK esegue tale operazione attraverso un insieme di compiti che simulano gruppi di utenti specifici riportandone i risultati. Sviluppato per testare le prestazioni di un notebook, BLTK è in grado di notificare anche le prestazioni di computer desktop quando avviato con
-a.
BLTK permette di generare carichi di lavoro riproducibili confrontabili all'uso reale di una macchina. Per esempio, il carico di lavoro
office scrive un testo, corregge il contenuto ed esegue le stesse operazioni per uno spreadsheet. L'esecuzione di BLTK insieme a PowerTOP o qualsiasi altro tool per la verifica e analisi, permetterà all'utente di eseguire una prova per verificare se le ottimizzazioni apportate hanno avuto alcun effetto sulla macchina durante la sua esecuzione. Poichè è possibile eseguire carichi di lavoro più di una volta per le varie impostazioni, sarà possibile confrontarne i risultati per le vaire impostazioni.
Installare BLTK con il comando:
yum install bltk
Eseguire BLTK con il comando:
bltk workload opzioni
Per esempio per eseguire il carico di lavoro
idle per 120 secondi:
bltk -I -T 120
I carichi di lavoro disponibili per impostazione predefinita sono:
-I,--idle- il sistema è sospeso, per un utilizzo di riferimento per il confronto con altri carichi di lavoro
-R,--reader- simula la lettura dei documenti (per impostazione predefinita, con Firefox)
-P,--player- simula la visione dei file multimedia da una unità CD o DVD (per impostazione predefinita con mplayer)
-O,--office- simula la modifica dei documenti con la suite OpenOffice.org
Altre opzioni permetteranno di specificare:
-a,--ac-ignore- Ignora se l'alimentazione AC è disponibile (necessario per un uso desktop)
-T numero_si_secondi,--time numero_si_secondi- il periodo (in secondi) entro il quale eseguire il test; usare questa opzione con il cairco di lavoro
idle -F filename,--file filename- specifica un file da usare da parte di un carico di lavoro particolare, per esempio, un file per
playerda riprodurre invece di accedere l'unità CD o DVD -W applicazione,--prog applicazione- specifica un'applicazione da usare da parte di un carico di lavoro particolare, per esempio, un browser diverso da Firefox per
reader
BLTK supporta un gran numero di opzioni altamente specializzate. Per informazioni consultare la pagina man
bltk.
BLTK archivia i risultati generati all'interno di una directory specificata nel file di configurazione
/etc/bltk.conf — per impostazione predefinita, ~/.bltk/workload.results.number/. Per esempio, la directory ~/.bltk/reader.results.002/ contiene i risultati del terzo test con reader (il primo test non è numerato). I suddetti risultati vengono distribuiti attraverso un certo numero di file di testo. Per condensare tali risultati in un formato facile da leggere eseguire:
bltk_report path_to_results_directory
I risultati appariranno in un file di testo chiamato
Report nella directory dei risultati. Per visualizzare i risultati in un emulatore del terminale usare l'opzione -o:
bltk_report -o path_to_results_directory2.5. Tuned e ktune
Tuned è un demone in grado di controllare l'utilizzo dei componenti del sistema e di regolare dinamicamente le impostazioni del sistema in base alle informazioni in possesso. La regolazione dinamica interessa il modo attraverso il quale i componenti del sistema sono utilizzati durante l'esecuzione di un dato sistema. Per esempio, il disco fisso viene usato maggiormento durante il processo d'avvio e di registrazione, ma usato raramente quando l'utente utilizza principalmente applicazioni del tipo email e OpenOffice. In modo simile i dispositivi di rete e la CPU sono usati in modo diverso in periodi diversi. Tuned controlla l'attività di questi componenti comportandosi in modo diverso in base al loro utilizzo.
Un esempio pratico, considerate una workstation tipica. La maggior parte delle volte l'interfaccia di rete ethernet sarà inattiva. Solo raramente pochissime email verranno inviate e ricevute o alcune pagine web caricate. Per questi carichi di lavoro l'interfaccia di rete non deve essere eseguita alla velocità massima come per impostazione predefinita. Tuned presenta un plugin di monitoraggio e regolazione per i dispositivi di rete in grado di rilevare un'attività bassa ed automaticamente diminuire la velocità dell'interfaccia, risultando così in un uso più basso di energia. Se l'attività dell'interfaccia aumenta drasticamente per un periodo di tempo maggiore, per esempio poichè una immagine DVD è stata scaricata o se una email con un allegato molto grande è stata aperta, tuned rileva tale variazione ed imposta la velocità dell'interfaccia ad un livello massimo in modo da offrire una prestazione migliore durante questo livello di attività. Questo principio viene anche usato per i plugin della CPU e dei dischi fissi.
Per impostazione predefinita i dispositivi di rete non sono configurati per comportarsi in questo modo poichè i cambiamenti di velocità possono richiedere diversi secondi prima di essere notati dall'utente. Simili considerazioni possono essere applicate per i plugin della CPU e del disco fisso. Quando un disco fisso è stato rallentato, esso avrà bisogno di svariati secondi prima di poter aumentare la propria velocità causando reazioni ritardate del sistema durante quel periodo. L'effetto della latenza è più piccola per il plugin della CPU, ma ancora misurabile, anche se non viene quasi avvertita dall'utente.
Insieme a tuned è presente anche ktune. Ktune è stato introdotto in Red Hat Enterprise Linux 5.3 come servizio e framework per l'ottimizzazione delle prestazioni di una macchina durante un uso specifico. Da allora ktune è stato migliorato a tal punto da essere implementato come parte fissa del nostro framework di regolazione generale. Esso viene usato principalmente nei diversi profili predefiniti descritti in Sezione 2.5.2, «Tuned-adm».
Installa il pacchetto tuned e gli script systemtap associati con il comando:
yum install tuned
L'installazione del pacchetto tuned imposta anche un file di configurazione d'esempio su
/etc/tuned.conf.
Avviare tuned usando:
service tuned start
Per avviare tuned ad ogni processo d'avvio usare:
chkconfig tuned on
Tuned a sua volta presenta delle opzioni aggiuntive quando lo si esegue manualmente. Le opzioni disponibili sono:
-d,--daemon- avvia tuned come demone invece di avviarlo in primo piano.
-c,--conffile- usa un file di configurazione con il percorso e file specificato, per esempio
--conffile=/etc/tuned2.conf. L'impostazione predefinita è/etc/tuned.conf. -D,--debug- utilizza il livello più alto di logging.
2.5.1. Il file tuned.conf
Il file
tuned.conf contiene le impostazioni per la configurazione di tuned. Per impostazione predefinita, esso è posizionato in /etc/tuned.conf, ma è possibile specificare un diverso nome ed una posizione usando tuned con l'opzione --conffile.
Il file di configurazione deve sempre contenere una sezione
[main] la quale definisce i parametri generali per tuned. il file presenta anche una sezione per ogni plugin.
La sezione
[main] contiene le seguenti opzioni:
interval- l'intervallo entro il quale tuned deve monitorare e regolare il sistema, in secondi. Il valore predefinito è
10. verbose- specifica se un output deve essere verboso. Il valore predefinito è
False. logging- specifica la priorità minima di messaggi da registrare. In ordine decrescente i valori permessi sono:
critical,error,warning,info, edebug. Il valore predefinito èinfo. logging_disable- specifica la priorità massima di messaggi da registrare, qualsiasi messaggio con questa priorità o con priorità più bassa non verrà registrato. In ordine decrescente i valori permessi sono:
critical,error,warning,info, edebug. Il valorenotsetdisabilita questa opzione.
Ogni plugin presenta la propria sezione specificata con il nome del plugin nelle parentesi quadre; per esempio:
[CPUTuning]. Ogni plugin può avere le proprie opzioni. ma le seguenti opzioni sono applicate a tutti i plugin:
enabled- specifica se un plugin è stato o meno abilitato. Il valore predefinito è
True. verbose- specifica se l'output deve essere verboso. Se non impostato per questo plugin il valore viene ereditato da
[main]. logging- specifica la priorità minima dei messaggi da registrare. Se non impostato per questo plugin il valore viene ereditato da
[main].
Di seguito viene riportato un file di configurazione:
[main] interval=10 pidfile=/var/run/tuned.pid logging=info logging_disable=notset # Disk monitoring section [DiskMonitor] enabled=True logging=debug # Disk tuning section [DiskTuning] enabled=True hdparm=False alpm=False logging=debug # Net monitoring section [NetMonitor] enabled=True logging=debug # Net tuning section [NetTuning] enabled=True logging=debug # CPU monitoring section [CPUMonitor] # Enabled or disable the plugin. Default is True. Any other value # disables it. enabled=True # CPU tuning section [CPUTuning] # Enabled or disable the plugin. Default is True. Any other value # disables it. enabled=True
2.5.2. Tuned-adm
Spesso la verifica e l'analisi dettagliate di un sistema può richidere molto tempo ed i watt risparmiati potrebbero non valerne la pena. In precedenza la sola alternativa era l'utilizzo delle impostazione predefinite. Per questo motivo Red Hat Enterprise Linux 6 include profili separati per usi specifici come alternativa per questi due tipi di approcci, insieme al tool tuned-adm che vi permette di smistarvi facilmente tra questi profili tramite la linea di comando. Red Hat Enterprise Linux 6 include un numero di profili predefiniti per un uso tipico in grado di essere selezionati ed attivati con il comando
tuned-adm. Sarà anche possibile creare, modificare e cancellare profili desiderati.
Per elencare tutti i profili disponibili ed identificare il profilo attivo corrente eseguire:
tuned-adm list
Per mostrare solo il profilo attivo corrente eseguire:
tuned-adm active
Per smistarsi su di un profilo disponibile eseguire:
tuned-adm profile profile_name
per esempio:
tuned-adm profile server-powersave
Per disabilitare:
tuned-adm off
Quando si esegue la prima installazione di tuned, il profilo
predefinito sarà attivo. Red Hat Enterprise Linux 6 include anche i seguenti profili predefiniti:
- default
- il profilo predefinito per il risparmio energetico. Presenta l'impatto più basso sul risparmio energetico dei profili disponibili, ed abilita solo la CPU ed i plugin del disco di tuned.
- desktop-powersave
- un profilo per il risparmio energetico per i sistemi desktop. Abilita ALPM power saving per gli adattatori host SATA (consultare Sezione 3.6, «Aggressive Link Power Management») e per i plugin del disco, ethernet e della CPU di tuned.
- server-powersave
- un profilo per il risparmio energetico per i sistemi server. Abilita ALPM powersaving per gli adattatori SATA, disabilita la verifica del CD-ROM tramite HAL (consultare la pagina man di hal-disable-polling) ed attiva i plugin del disco e della CPU di tuned.
- laptop-ac-powersave
- un profilo di medio impatto per il risparmio energetico per i laptop eseguiti tramite AC. Abilita l'ALPM powersaving per gli adattatori host SATA, WiFi power saving, ed i plugin del disco, ethernet e della CPU di tuned.
- laptop-battery-powersave
- un profilo ad elevato impatto per il risparmio energetico per laptop alimentati a batteria. Esso attiva tutti i meccanismi di risparmio energetico dei precedenti profili ed abilita lo scheduler per il risparmio energetico multi-core per sistemi con wakeup bassi, assicurando che il governatore ondemand sia attivo e che AC97 audio power-saving sia stato abilitato. Utilizzare questo profilo per risparmiare la quantità più elevata di energia su qualsiasi tipo di sistema, non solo laptop alimentati a batteria. Da considerare che con questo profilo sarà possibile notare un impatto sulle prestazioni, ed in particolare sulla latenza del disco e dell'I/O di rete.
- throughput-performance
- un profilo server per una regolazione tipica delle prestazioni throughput. Esso disabilita i meccanismi di risparmio energetico tuned e ktune, abilita le impostazioni sysctl le quali migliorano le prestazioni throughput dell'I/O di rete e del disco, smistandosi su deadline scheduler.
- latency-performance
- un profilo server per una regolazione tipica delle prestazioni della latenza. Esso disabilita i meccanismi di risparmio energetico tuned e ktune ed abilita le impostazioni sysctl le quali migliorano le prestazioni della latenza dell'I/O di rete.
Tutti i profili sono archiviati in sottodirectory separate in
/etc/tune-profiles. Quindi /etc/tune-profiles/desktop-powersave contiene tutti i file necessari e le impostazioni del profilo. Ogni directory contiene un massimo di quattro file:
tuned.conf- la configurazione per il servizio tuned da attivare per questo profilo.
sysctl.ktune- le impostazioni sysctl usate da ktune. Il formato è identico al file
/etc/sysconfig/sysctl(consultate le pagine man sysctl e sysctl.conf). ktune.sysconfig- il file di configurazione di ktune, generalmente
/etc/sysconfig/ktune. ktune.sh- uno script della shell stile-init usato dal servizio ktune il quale è in grado di eseguire comandi specifici durante l'avvio per la regolazione del sistema.
Il modo più semplice per iniziare un nuovo profilo è quello di copiarne uno già esistente. Il profilo
laptop-battery-powersave contiene un insieme molto ricco di regolazioni e quindi rappresenta un buon punto d'inizio. Copiare semplicemente tutta la directory nel nuovo nome della directory nel modo simile:
cp -a /etc/tune-profiles/laptop-battery-powersave/ /etc/tune-profiles/myprofile
Modificare qualsiasi file nel nuovo profilo in modo da soddisfare i requisiti personali. Per esempio, se si desidera rilevare le modifiche del CD, disabilitare l'impostazione per l'ottimizzazione in questione decommentando la linea relativa nello script ktune.sh:
# Disable HAL polling of CDROMS # for i in /dev/scd*; do hal-disable-polling --device $i; done > /dev/null 2>&1
2.6. DeviceKit-power e devkit-power
Con Red Hat Enterprise Linux 6 DeviceKit-power assume le funzioni di gestione dell'alimentazione facenti parte di HAL, insieme ed alcune funzioni di GNOME Power Manager nelle versioni precedenti di Red Hat Enterprise Linux (consultare anche Sezione 2.7, «GNOME Power Manager». DeviceKit-power fornisce un demone, una API ed un insieme di tool della linea di comando. Ogni fonte energetica sul sistema è rappresentata come un dispositivo, sia esso un dispositivo fisico o altro dispositivo. Per esempio, una batteria per portatili ed una sorgente di alimentazione AC sono entrambe rappresentate come dispositivi.
È possibile accedere i tool della linea di comando con il comando
devkit-power usando le seguenti opzioni:
--enumerate,-e- mostra il percorso dell'oggetto per ogni dispositivo di alimentazione sul sistema, per esempio:
/org/freedesktop/DeviceKit/power/devices/line_power_AC/org/freedesktop/UPower/DeviceKit/power/battery_BAT0 --dump,-d- mostra i parametri per tutti i dispositivi di alimentazione sul sistema.
--wakeups,-w- mostra i wakeup della CPU sul sistema.
--monitor,-m- controlla il sistema per eventuali modifiche dei dispositivi di alimentazione, per esempio il collegamento e scollegamento di una sorgente di alimentazione AC, o la riduzione del livello energetico di una batteria. Premere Ctrl+C per terminare il monitoraggio del sistema.
--monitor-detail- controlla il sistema per eventuali modifiche dei dispositivi di alimentazione, per esempio il collegamento e scollegamento di una sorgente di alimentazione AC, o la riduzione del livello energetico di una batteria. L'opzione
--monitor-detailpresenta informazioni più dettagliate rispetto a--monitor. Premere Ctrl+C per terminare il monitoraggio del sistema. --show-info object_path,-i object_path- mostra tutte le informazioni disponibili per un percorso particolare. Per esempio, per ottenere le informazioni su di una batteria del sistema rappresentata dal percorso
/org/freedesktop/UPower/DeviceKit/power/battery_BAT0, eseguire:devkit-power -i /org/freedesktop/UPower/DeviceKit/power/battery_BAT0
2.7. GNOME Power Manager
GNOME Power Manager è un demone installato come parte del desktop di GNOME . La maggior parte delle funzionalità di gestione energetica disponibili con GNOME Power Manager nelle versioni precedenti di Red Hat Enterprise Linux, sono divenute parte integrante di DeviceKit-power in Red Hat Enterprise Linux 6 (consultare Sezione 2.6, «DeviceKit-power e devkit-power». Tuttavia GNOME Power Manager rimane il front-end per questa funzionalità. Attraverso un applet nel tray del sistema, GNOME Power Manager notifica le modifiche presenti nello stato di alimentazione del sistema; per esempio una modifica della batteria o dell'alimentazione AC. Esso notifica altresì lo stato della batteria ed avverte quando la stessa presenta un livelle energetico basso.
GNOME Power Manager permette altresì di configurare alcune impostazioni di base per la gestione energetica. Per accedere alle suddette impostazioni fare clic su GNOME Power Manager nel tray del sistema e successivamente su
La schermata Power Management Preferences contiene tre tabelle:
- Alimentazione tramite AC
- Alimentazione tramite batteria
- Generale
Utilizzare Alimentazione tramite AC e Alimentazione tramite batteria per specificare l'arco di tempo oltre il quale il display viene spento su di un sistema inattivo, il tempo necessario oltre il quale un sistema inattivo viene messo in uno stato di 'sleep', e per arrestare i dischi fissi quando gli stessi non sono utilizzati. La tabella Alimentazione tramite batteria permette anche di impostare la luminosità del display e sceglierne il comportamento per un sistema con una batteria quasi scarica. Per esempio, per impostazione predefinita GNOME Power Manager è in grado di ibernare un sistema quando il livello energetico di una batteria raggiunge livelli molto bassi. Usare la tabella Generale per impostare i pulsanti di sospensione e di alimentazione (fisica) sul sistema, e specificare le circostanze nelle quali l'icona GNOME Power Manager deve apparire nel tray del sistema.
2.8. Altri mezzi per il processo di verifica
Red Hat Enterprise Linux 6 offre numerosi tool per la verifica e l'analisi del sistema. La maggior parte di essi può essere utilizzato come mezzi supplementari d'informazioni nel caso in cui si desidera verificare un risultato precedentemente ottenuto, o nel caso in cui sono necessarie informazioni più dettagliate su alcune sezioni. La maggior parte dei suddetti tool viene usato anche per la regolazione delle prestazioni. Essi includono:
- vmstat
- vmstat usato per ottenere informazioni dettagliate sui processi, memoria, paging, I/O del blocco, traps e attività della CPU. Usatelo per avere informazioni più approfondite sulle azioni generali del sistema e dei punti nei quali risulta occupato.
- iostat
- iostat è simile a vmstat ma solo per I/O su dispositivi a blocchi. Fornisce anche statistiche e output più verbosi.
- blktrace
- blktrace è un programma molto dettagliato per il tracciamento I/O del blocco. Suddivide le informazioni in blocchi singoli associati con le applicazioni. È molto utile se usato insieme a diskdevstat.
Capitolo 3. Infrastruttura principale e meccanismi
3.1. Stati inattivi della CPU
Le CPU con architettura x86 supportano diversi stati attraverso i quali sezioni della CPU vengono disattivate o eseguite con prestazioni più basse. Questi stati, conosciuti come stati-C, permettono ai sistemi di risparmiare energia disattivando parzialmente le CPU non utilizzate. Gli stati-C sono numerati da C0 in ordine crescente, con numeri più alti che rappresentano funzionalità CPU decrescenti ed un risparmio energetico maggiore. Anche se gli C-States sono più o meno simili su tutti i processori, il significato di uno stato-C particolare è specifico ad un processore o famiglia di processori, quindi C3 su di un processore non è uguale ad un C3 su di un altro processore. Stati-C 0–3 sono definiti nel modo seguente:
- C0
- stato operativo o di esecuzione. In questo stato la CPU è in esecuzione e non è inattiva.
- C1, Halt
- uno stato nel quale il processore non esegue alcuna istruzione ma non è generalmente in uno stato di alimentazione bassa. La CPU è in grado di continuare con la processazione senza alcun ritardo. Tutti i processori che offrono uno stato-C devono essere abilitati a questo stato. I processori Pentium 4 supportano uno stato C1 migliorato chiamato C1E il quale rappresenta uno stato per un consumo energetico più basso.
- C2, Stop-Clock
- uno stato nel quale il clock è stato sospeso per questo processore, mantenendo il suo stato completo per i registri e le cache, dopo aver riavviato il clock sarà possibile iniziare nuovamente la processazione. Questo è uno stato opzionale.
- C3, Sleep
- uno stato nel quale il processore entra in uno stato inattivo 'sleep' e non ha bisogno di mantener aggiornata la propria cache. La sua riattivazione da questo stato richiede un periodo più lungo rispetto allo stato C2 a causa di tale comportamento. Questo rappresenta uno stato opzionale.
CPU Intel recenti con una microarchitettura "Nehalem" presentano un nuovo stato-C, C6, il quale è in grado di ridurre la fornitura di voltaggio di una CPU fino a zero, ma generalmente riduce il consumo di energia tra l'80% ed il 90%. Il kernel in Red Hat Enterprise Linux 6 include alcuni miglioramenti per questo nuovo stato-C.
3.2. Come usare i regolatori CPUfreq
Uno dei modi più efficaci per ridurre il consumo energetico e gli output termici sul sistema è quello di utilizzare CPUfreq. CPUfreq — conosciuto come CPU speed scaling — permette di regolare la velocità di clock del processore durante la sua esecuzione. Tale funzione permette l'esecuzione del sistema ad una velocità ridotta risparmiando così energia. Le regole relative, per una velocità maggiore o minore, e le circostanze nelle quali modificare le frequenze sono definite dal regolatore CPUfreq.
Il regolatore definisce le caratteristiche di alimentazione della CPU del sistema, il quale a sua volta interessa le prestazioni della CPU. Ogni regolatore ha un suo comportamento, scopo, e idoneità in termini di carico di lavoro. Questa sezione descrive come selezionare e configurare un regolatore CPUfreq, le sue caratteristiche ed il tipo di carico.
3.2.1. Tipi di regolatori CPUfreq
Questa sezione elenca e descrive i diversi tipi di regolatori CPUfreq disponibili in Red Hat Enterprise Linux 6.
cpufreq_performance
Il regolatore Performance forza la CPU ad utilizzare la frequenza più elevata possibile dell'orologio. Questa frequenza verrà impostata staticamente e non sarà modificata. Per questo motivo questo regolatore non offre alcun beneficio relativo al risparmio energetico. Tale impostazione è idonea solo per carichi di lavoro molto elevati, ed anche in tal caso, solo quando la CPU è raramente (o mai) in uno stato inattivo (idle).
cpufreq_powersave
Al contrario il regolatore Powersave forza la CPU ad usare la frequenza più bassa possibile del clock. Questa frequenza verrà impostata staticamente e non verrà modificata. Per questo motivo questo regolatore offre un risparmio energetico massimo ma con la più bassa prestazione della CPU.
Il termine "powersave" può talvolta ingannare, poichè (in principio) una CPU lenta con carico massimo consuma più energia di una CPU veloce senza carico. Per questo motivo, anche se è consigliato impostare la CPU in modo da usare il regolatore Powersave durante periodi di attività minima, qualsiasi carico elevato inaspettato durante questo periodo potrà causare un consumo energetico più elevato.
Il regolatore Powersave è in termini semplici un "limitatore di velocità" per la CPU e non un "risparmiatore di energia". È utile in sistemi ed ambienti dove il surriscaldamento potrebbe rappresentare un problema.
cpufreq_ondemand
Il regolatore Ondemand è un regolatore dinamico che permette alla CPU di ottenere una frequenza massima quando il carico del sistema è elevato, ed una frequenza minima quando il sistema è inattivo (idle). Mentre tale regolatore permette al sistema di modificare il consumo energetico in base al carico, questo stato viene raggiunto a scapito della latenza tra i cambi di frequenza. Per questo motivo la latenza è in grado di controbilanciare qualsiasi beneficio relativo al risparmio energetico/prestazioni offerto dal regolatore Ondemand se il sistema si smista spesso tra carichi di lavoro elevati e inattivi.
Per numerosi sistemi il regolatore Ondemand è in grado di fornire il miglior compromesso tra emissione termica, consumo energetico, prestazioni e maneggevolezza. Quando il sistema è occupato solo in periodi specifici della giornata, il regolatore Ondemand si smisterà automaticamente tra frequenza massima e minima in base al carico senza alcun intervento.
cpufreq_userspace
Il regolatore Userspace permette ai programmi spazio utente (o qualsiasi processo in esecuzione come root) di impostare la frequenza. Questo regolatore viene normalmente usato insieme con il demone cpuspeed. Tra tutti i regolatori, Userspace è quello più personalizzabile; ed in base alla sua configurazione, è in grado di fornire il miglior rapporto prestazione e consumo per il sistema.
cpufreq_conservative
Come il regolatore Ondemand, il regolatore Conservative modifica la frequenza clock in base all'uso. Tuttavia il regolatore Ondemand esegue tale processo in modo più aggressivo (e cioè dal valore massimo al valore minimo e viceversa), mentre il regolatore Conservative esegue lo smistamento tra frequenze in modo più graduale.
Ciò significa che il regolatore Conservative sceglierà una frequenza più idonea al carico senza selezionarne una massima o minima. Anche se tale comportamento può fornire un risparmio significativo di energia, al tempo stesso potrà causare una maggiore latenza rispetto al regolatore Ondemand.
Nota
È possibile abilitare un regolatore usando
cron. Ciò permetterà all'utente di impostare automaticamente regolatori specifici durante determinati periodi del giorno. Per questo motivo sarà possibile specificare un regolatore a bassa-frequenza durante i periodi di inattività (per esempio dopo l'orario lavorativo), e selezionare un regolatore con una frequenza più elevata durante i periodi di carico intenso.
Per informazioni su come abilitare un regolatore specifico consultare Procedura 3.2, «Come abilitare un regolatore CPUfreq» in Sezione 3.2.2, «Impostazione di CPUfreq».
3.2.2. Impostazione di CPUfreq
Prima di selezionare e configurare un regolatore CPUfreq è necessario aggiungere i driver CPUfreq appropriati.
Procedura 3.1. Come aggiungere un driver CPUfreq
- Utilizzare il seguente comando per visualizzare i driver CPUfreq disponibili per il sistema;
ls /lib/modules/[kernel version]/kernel/arch/[architecture]/kernel/cpu/cpufreq/ - Usare
modprobeper aggiungere il driver CPUfreq appropriato.modprobe [CPUfreq driver]Durante l'utilizzo di questo comando assicurarsi di rimuovere il suffisso del filename.ko.Importante
Quando si seleziona un driver CPUfreq appropriato, scegliere sempreacpi-cpufreqal posto dip4-clockmod. Anche se l'utilizzo dip4-clockmodriduce la frequenza di clock di una CPU, esso non riduce il voltaggio.acpi-cpufreqal contrario riduce il voltaggio insieme alla frequenza della CPU, riducendo il consumo energetico e l'output termico per ogni unità specifica ridotta espressa in kilohertz delle prestazioni. - Una volta impostato il driver CPUfreq sarà possibile visualizzare il regolatore usato dal sistema con:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
È possibile altresì visualizzare quale regolatore è disponibile per una CPU specifica usando:
cat /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_available_governors
Alcuni regolatori CPUfreq potrebbero non essere disponibili all'uso. In questo caso usare
modprobe per aggiungere i moduli del kernel in grado di abilitare il regolatore CPUfreq specifico da usare. I moduli del kernel sono disponibili in /lib/modules/[kernel version]/kernel/drivers/cpufreq/.
Procedura 3.2. Come abilitare un regolatore CPUfreq
- Se un regolatore specifico non è stato elencato per la CPU usare
modprobeper abilitare il regolatore che desiderate usare. Per esempio, se il regolatoreondemandnon è disponibile per la CPU utilizzare il seguente comando:modprobe cpufreq_ondemand - Una volta riportato come disponibile sarà possibile abilitarlo usando:
echo [governor] > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
3.2.3. Regolazione Politica CPUfreq e velocità
Una volta scelto un regolatore CPUfreq appropriato sarà possibile regolare maggiormente la velocità di ogni CPU usando i parametri in
/sys/devices/system/cpu/[cpu ID]/cpufreq/. I suddetti parametri sono:
cpuinfo_min_freq— Mostra la frequenza operativa minima disponibile della CPU (in KHz).cpuinfo_max_freq— Mostra la frequenza operativa massima disponibile della CPU (in KHz).scaling_driver— Mostra il driver CPUfreq usato per impostare la frequenza su questa CPU.scaling_available_governors— Mostra i regolatori (governor) CPUfreq disponibili in questo kernel. Se desiderate un regolatore CPUfreq non elencato in questo file consultate Procedura 3.2, «Come abilitare un regolatore CPUfreq» in Sezione 3.2.2, «Impostazione di CPUfreq» per maggiori informazioni.scaling_governor— Mostra il regolatore CPUfreq in uso. Per usare un regolatore diverso eseguireecho [governor] > /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_governor(consultare Procedura 3.2, «Come abilitare un regolatore CPUfreq» in Sezione 3.2.2, «Impostazione di CPUfreq» per maggiori informazioni).cpuinfo_cur_freq— Mostra la velocità corrente della CPU (in KHz).scaling_available_frequencies— Elenca le frequenze disponibili per la CPU, in KHz.scaling_min_freqandscaling_max_freq— Imposta i limiti della politica della CPU, in KHz.affected_cpus— Elenca le CPU che necessitano di un software per la coordinazione della frequenza.scaling_setspeed— Usato per modificare la velocità di clock della CPU, in KHz. È possibile impostare solo una velocità all'interno dei limiti della politica della CPU (come perscaling_min_freqescaling_max_freq).
Per visualizzare il valore corrente di ogni parametro ottimizzabile, usare
cat [tunable]. Per esempio per visualizzare la velocità corrente di cpu0 (in KHz), usare:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq.
Per modificare il valore di ogni parametro ottimizzabile usare
echo [value] > /sys/devices/system/cpu/[cpu ID]/cpufreq/[tunable]. Per esempio, per impostare la velocità minima di clock di cpu0 su 360 KHz, usare:
echo 360000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
3.3. Sospensione e ripristino
Se un sistema è sospeso il kernel utilizza i driver per l'archiviazione degli stati, e in un secondo momento, scaricandoli. Quando il sistema viene ripristinato esso ricarica i driver, i quali a loro volta cercheranno di programmare i propri dispositivi. La capacità dei driver di eseguire questo compito determina il successo del ripristino del sistema.
I driver video sono particolarmente problematici poichè le specifiche Advanced Configuration and Power Interface (ACPI) non richiedono la riprogrammazione dell'hardware video da parte del firmware del sistema . Per questo motivo se i driver video non sono in grado di programmare l'hardware da uno stato non completamente inizializzato, essi possono impedire il ripristino del sistema.
Red Hat Enterprise Linux 6 include un miglior supporto per nuovi chipset grafici, i quali assicurano il funzionamento dei processi di sospensione e ripristino su di un numero più vasto di piattaforme. Il supporto per i chipset NVIDIA è stato migliorato; in particolare per la serie GeForce 8800.
3.4. Tickless Kernel
In precedenza il kernel di Linux interrompeva periodicamente ogni CPU su di un sistema ad una frequenza predeterminata — 100 Hz, 250 Hz, o 1000 Hz, in base alla piattaforma. Il kernel interrogava la CPU sui processi in esecuzione, ed utilizzava i risultati per il conteggio dei processi ed il bilanciamento del carico. Conosciuto come timer tick, il kernel eseguiva questa interruzione senza considerare lo stato dell'alimentazione della CPU. Per questo motivo anche una CPU inattiva era in grado di rispondere fino a 1000 richieste al secondo. Su sistemi che implementavano misure per il risparmio energetico per CPU inattive, il timer tick impediva alla CPU di rimanere inattiva per un periodo sufficientemente lungo per poter beneficiare di queste misure.
Il kernel in Red Hat Enterprise Linux 6 esegue il tickless: cioè, sostituisce le interruzioni periodiche vecchie del timer con interruzioni a richiesta. Per questo motivo le CPU inattive possono restare inattive fino a quando un nuovo compito viene messo in coda per la processazione, così facendo le CPU con stati di alimentazione più bassi possono restare in questi stati più a lungo.
3.5. Active-State Power Management
Active-State Power Management (ASPM) è in grado di risparmiare energia nel sottosistema Peripheral Component Interconnect Express (PCI Express o PCIe) impostando uno stato di alimentazione più basso per i link PCIe quando i dispositivi usati per il collegamento non sono utilizzati. ASPM controlla lo stato energetico delle due estremità del link, risparmiando energia sul link anche quando il dispositivo è completamente alimentato.
Quando ASPM è abilitato la latenza del dispositivo aumenta a causa del tempo richiesto per la transizione del link tra i diversi stati di alimentazione. ASPM presenta tre politiche per determinare lo stato dell'alimentazione:
- predefinito
- imposta gli stati di alimentazione del link di PCIe in base alle impostazioni predefinite specificate dal firmware sul sistema (per esempio, BIOS). Questo è lo stato predefinito per ASPM.
- powersave
- imposta ASPM in modo da risparmiare energia quando possibile senza tenere in considerazione le prestazioni.
- prestazioni
- disabilita ASPM per permettere ai link PCIe di operare con una prestazione massima.
Le politiche di ASPM sono impostate in
/sys/module/pcie_aspm/parameters/policy, ma possono anche essere specificate al momento dell'avvio con il parametro del kernel pcie_aspm, dove pcie_aspm=off e pcie_aspm=force disabilitano ed abilitano ASPM anche su dispositivi che non supportano ASPM.
Avvertimento
Se
pcie_aspm=force è stato impostato, l'hardware che non supporta ASPM può causare un arresto delle risposte da parte del sistema. Prima di impostare pcie_aspm=force assicurarsi che tutti gli hardware PCIe sul sistema supportano ASPM.
3.6. Aggressive Link Power Management
Aggressive Link Power Management (ALPM) è una tecnica per il risparmio energetico da parte del disco tramite l'impostazione di un link SATA il quale utilizza un livello energetico più basso durante il periodo di inattività (quando non vi è alcun I/O). ALPM imposta automaticamente il link SATA su di uno stato attivo in presenza di richieste I/O sul link.
Il risparmio energetico introdotto da ALPM è stato introdotto a scapito della latenza del disco. Per questo motivo utilizzare ALPM solo se si prevedeno lunghi periodi di sospensione I/O del sistema.
ALPM è solo disponibile su controller SATA che utilizzano Advanced Host Controller Interface (AHCI). Per maggiori informazioni su AHCI, consultare http://www.intel.com/technology/serialata/ahci.htm.
Quando disponibile, ALPM viene abilitato per impostazione predefinita. ALPM presenta tre modalità:
min_power
Questa modalità imposta il link sullo stato più basso di alimentazione (SLUMBER) quando non è presente alcun I/O sul disco. Tale modalità è utile se si prevedono periodi lunghi di inattività.
medium_power
Questa modalità imposta il link sul secondo stato di alimentazione più basso (PARTIAL) quando non vi è alcuna presenza di I/O sul disco. Questa modalità è stata ideata per permettere le transizioni negli stati (per esempio durante periodi intermittenti di I/O intensi e I/O inattivi) con il minimo impatto possibile sulle prestazioni.
La modalità
medium_power permette la transizione del link tra gli stati PARTIAL and fully-powered (cioè "ACTIVE") in base al carico. Da notare che non sarà possibile eseguire la transizione diretta di un link da uno stato PARTIAL a SLUMBER e viceversa; in questo caso entrambi gli stati non possono esseguire una transizione all'altro stato senza passare prima per lo stato ACTIVE.
max_performance
ALPM è disabilitato, il link non entra in uno stato low-power quando non vi è presenza di I/O sul disco.
Per controllare se gli adattatori host SATA supportano ALPM, verificare se esiste il file
/sys/class/scsi_host/host*/link_power_management_policy. Per modificare le impostazioni scrivere i valori descritti in questa sezione sui file o visualizzare i file per controllare le impostazioni correnti.
3.7. Ottimizzazione accesso unità Relatime
Con lo standard di POSIX i sistemi operativi devono mantenere i metadati del file system che registrano l'ultimo accesso al file. Questo timestamp viene chiamato
atime, e la sua gestione richiede una serie costante di operazioni di scrittura da archiviare. Queste operazioni mantengono i dispositivi di storage ed il link relativi occupati ed alimentati. Poichè poche applicazioni utilizzano i dati atime, l'attività di questo dispositivo di storage rappresenta una dispersione di alimentazione. In particolare, il processo di scrittura si verifica anche se il file non è stato letto dal dispositivo di storage ma dalla cache. Per un certo periodo di tempo il kernel di Linux ha supportato l'opzione noatime per mount senza scrivere i dati atime sui file sistem montati con questa opzione. Tuttavia la disabilitazione di questa funzione è problematica poichè alcune applicazioni si affidano ai dati atime e quindi possono fallire se non disponibili.
Il kernel usato in Red Hat Enterprise Linux 6 supporta un'altra opzione —
relatime. Relatime mantiene i dati atime ma esegue questa operazione non tutte le volte che si accede al file. Se questa opzione è abilitata i dati atime vengono scritti sul disco solo se il file è stato modificato dall'ultimo aggiornamento dei dati atime (mtime), o se lo si accede per un periodo di tempo più lungo (il default è un giorno).
Per impostazione predefinita tutti i file system sono montati con l'opzione
relatime abilitata. Per annullare questa funzione su tutto il sistema usare il parametro d'avvio default_relatime=0. Se relatime è abilitato su di un sistema per impostazione predefinita, sarà possibile annullarlo per qualsiasi file system usando l'opzione norelatime. Ed infine, per modificare il periodo di tempo predefinito prima del quale il sistema aggiorna i dati atime di un file, usare il parametro d'avvio relatime_interval= specificando il periodo in secondi. Il valore predefinito è 86400.
3.8. Limitazione dell'alimentazione
Red Hat Enterprise Linux 6 supporta le funzioni di limitazione dell'alimentazione presenti nei nuovi hardware, come ad esempio HP Dynamic Power Capping (DPC), e Intel Node Manager (NM). La limitazione dell'alimentazione permette agli amministratori di limitare l'energia consumata dai server, ed una pianificazione più efficiente dei data center a causa di una diminuzione dei rischi di sovraccarico. I gestori sono in grado di posizionare un numero maggiore di server all'interno dello stesso footprint fisico sapendo che, se il consumo energetico dei server è limitato, la richiesta energetica durante carichi di lavoro più elevati non supererà quella disponibile.
HP Dynamic Power Capping
Il Dynamic Power Capping è una funzione disponibile su server ProLiant e BladeSystem selezionati che permette agli amministratori di sistema di limitare il consumo energetico di un server o di un gruppo di server. Esso rappresenta un limite effettivo che il server non supererà mai sotto qualsiasi carico di lavoro. Questo limite non ha alcun effetto fino a quando il server non raggiunge il suo limite. A questo punto un processore di gestione modificherà la CPU P-states CPU ed il clock throttling limitando l'energia consumata.
Dynamic Power Capping modifica il comportamento della CPU indipendentemente dal sistema operativo, tuttavia il firmware integrated Lights-Out 2 (iLO2) di HP abilita l'accesso ai sistemi operativi al processore di gestione, e per questo motivo le applicazioni dello spazio utente sono in grado di interrogare il processore stesso. Il kernel usato in Red Hat Enterprise Linux 6 include un driver per il firmware HP iLO e iLO2 il quale permette ai programmi di interrogare il processore di gestione su
/dev/hpilo/dXccbN. Il kernel include anche una estensione dell'interfaccia hwmon sysfs per il supporto delle funzioni di limitazione dell'alimentazione, ed un driver hwmon per i contatori d'alimentazione ACPI 4.0 che utilizzano l'interfaccia sysfs. Insieme queste funzioni permettono al sistema operativo e ai tool dello spazio utente di leggere il valore configurato come limite, insieme all'uso energetico corrente del sistema.
Per maggiori informazioni su HP Dynamic Power Capping consultare HP Power Capping e HP Dynamic Power Capping per server ProLiant, disponibile su http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01549455/c01549455.pdf
Intel Node Manager
Intel Node Manager impone un limite energetico sui sistemi tramite processori con stati-P e stati-T per limitare le prestazioni della CPU e quindi il consumo energetico. Impostando una politica di gestione energetica gli amministratori sono in grado di configurare i sistemi in modo da consumare meno energia durante periodi di basso carico, per esempio durante la notte o i fine settimana.
Intel Node Manager regola le prestazioni della CPU usando un Operating System-directed configuration and Power Management (OSPM) attraverso l'Advanced Configuration and Power Interface standard. Quando Intel Node Manager notifica al driver OSPM le modifiche relative allo stato-T, il driver esegue le stesse modifiche allo stato-P del processore. In modo simile, quando Intel Node Manager notifica al driver OSPM le modifiche relative allo stato-P, il driver esegue le stesse modifiche allo stato-T. Le suddette modifiche vengono eseguite automaticamente e non richiedono alcun intervento da parte del sistema operativo. Gli amministratori eseguono la configurazione ed il monitoraggio di Intel Node Manager usando il software Intel Data Center Manager (DCM).
Per maggiori informazioni su Intel Node Manager, consultare il Node Manager — Un approccio dinamico per la Gestione energetica nel Data Center, disponibile su http://communities.intel.com/docs/DOC-4766
3.9. Gestione energetica dei grafici migliorata
Red Hat Enterprise Linux 6 risparmia energia sui dispositivi display e grafici eliminando numerose fonti di consumo non essenziali.
LVDS reclocking
Il Low-voltage differential signalling (LVDS) è un sistema in grado di trasmettere un segnale elettronico attraverso un filo di rame. Il sistema viene usato principalmente per la trasmissione di informazioni pixel su schermate liquid crystal display (LCD) in computer notebook. Tutti i display hanno una frequenza d'aggiornamento — la frequenza alla quale vengono ricevuti nuovi dati da un controllore di grafici e ridisegnare l'immagine sulla schermata. Generalmente la schermata riceve nuovi dati sessanta volte al secondo (una frequenza di 60 Hz). Quando il controllore della schermata e dei grafici sono collegati tramite LVDS, il sistema LVDS utilizza alimentazione ad ogni ciclo di aggiornamento. In uno stato inattivo la frequenza d'aggiornamento di numerosi schermate LCD può essere ridotta a 30 Hz senza notare alcun effetto (diversamente dai monitor cathode ray tube (CRT), dove una diminuzione nella frequenza d'aggiornamento produce un tremolio caratteristico). Il driver per gli adattatori grafici Intel creati all'interno del kernel usato in Red Hat Enterprise Linux 6 esegue il downclock automaticamente risparmiando 0.5 W quando la schermata è inattiva.
Come abilitare un aggiornamento automatico della memoria
Synchronous dynamic random access memory (SDRAM) — usato per la memoria video negli adattatori grafici — viene ricaricato migliaia di volte al secondo permettendo alle celle individuali della memoria di conservare i dati archiviati nel loro interno. A parte la propria funzione principale di gestione dei dati, il controller della memoria è generalmente responsabile dell'inizializzazione dei cicli di aggiornamento. Tuttavia SDRAM presenta anche una modalità di auto aggiornamento con bassa alimentazione. In questa modalità la memoria utilizza un timer interno per generare i propri cicli di aggiornamento, permettendo al sistema di arrestare il controller della memoria senza mettere in pericolo i dati. Il kernel usato in Red Hat Enterprise Linux 6 è in grado di attivare l'auto aggiornamento della memoria negli adattatori grafici di Intel con uno stato inattivo, risparmiando così circa 0.8 W.
Riduzione del clock della GPU
Le graphical processing units (GPUs) tipiche contengono clock interni che governano varie parti del proprio circuito interno. Il kernel usato in Red Hat Enterprise Linux 6 è in grado di ridurre la frequenza di alcuni dei clock interni nelle GPU ATI ed Intel. Riducendo i cicli eseguiti dai componenti della GPU in un dato periodo, si avrà un risparmio di energia che altrimenti sarebbe stata consumata con cicli non necessari. Il kernel riduce automaticamente la velocità dei clock quando la GPU è inattiva, aumentandola invece quando l'attività della GPU aumenta. Riducendo i cicli clock della GPU è possibile risparmiare fino a 5 W.
GPU powerdown
I driver grafici ATI e Intel in Red Hat Enterprise Linux 6 sono in grado di rilevare quando nessun monitor è collegato ad un adattatore ed arrestare completamente la GPU. Questa funzione è molto importante per server ai quali non viene regolarmente collegato loro alcun monitor.
3.10. RFKill
Numerosi computer contengono radiotrasmettirori, incluso i dispositivi 3G, Wi-Fi e Bluetooth. Questi dispositivi consumano energia la quale viene persa quando i dispositivi non sono utilizzati.
RFKill è un sottosistema nel kernel di Linux il quale fornisce una interfaccia attraverso la quale i radiotrasmettitori in un computer possono essere interrogati, attivati e disattivati. Quando disattivati, è posisbile posizionare i trasmettitori in uno stato in cui il software è in grado di riattivarli (un soft block) o dove non sarà possibile riattivarli (un hard block).
RFKill core fornisce l'application programming interface (API) per il sottosistema. I driver del kernel creati per supportare RFkill utilizzano la suddetta API per la registrazione con il kernel, ed includere i metodi per l'abilitazione e la disabilitazione del dispositivo. In aggiunta, il RFKill core fornisce le notifiche che le applicazioni utente sono in grado di interpretare per l'interrogazione degli stati dei trasmettitori.
L'interfaccia RFKill si trova in
/dev/rfkill, dove è presente lo stato corrente di tutti i radiotrasmettitori sul sistema. Ogni dispositivo ha il proprio stato RFKill corrente registrato in sysfs. In aggiunta, RFKill emette uevents per ogni modifica dello stato in un dispositivo abilitato a RFKill.
Rfkill è un tool della linea di comando con il quale è possibile interrogare e modificare i dispositivi abiliati al RFKill sul sistema. Per ottenere il tool installare il pacchetto rfkill.
Usare il comando
rfkill list per ottenere un elenco di dispositivi ognuno dei quali presenta un numero indice ad esso associato, iniziando con 0. Utilizzare il suddetto numero per indicare a rfkill di bloccare o sbloccare un dispositivo, per esempio:
rfkill block 0
blocca il primo dispositivo abilitato al RFKil presente sul sistema.
Utilizzare anche rfkill per bloccare certe categorie di dispositivi o tutti i dispositivi abilitati al RFKill. Per esempio:
rfkill block wifi
blocca tutti i dispositivi Wi-Fi presenti sul sistema. Per bloccare tutti i dispositivi abilitati al RFKill eseguire:
rfkill block all
Per sbloccare i dispositivi eseguire
rfkill unblock invece di rfkill block. Per ottenere un elenco completo di categorie di dispositivi che rfkill è in grado di bloccare, eseguire rfkill help
3.11. Ottimizzazione Spazio utente
La riduzione della quantità di lavoro di un hardware del sistema è fondamentale per un risparmio energetico. Per questo motivo anche se le modifiche descritte in Capitolo 3, Infrastruttura principale e meccanismi permettono al sistema di operare in diversi stati di consumo energetico ridotto, le applicazioni nello spazio utente che richiedono lavori non necessari dall'hardware impediscono all'hardware stesso di entrare in questi stati. Durante lo sviluppo di Red Hat Enterprise Linux 6 sono state eseguite alcune verifiche nelle seguenti aree per ridurre le richieste non necessarie nei confronti dell'hardware:
Riduzione processi di attivazione
Red Hat Enterprise Linux 6 usa un tickless kernel (consultare Sezione 3.4, «Tickless Kernel»), il quale permette alle CPU di restare più a lungo in uno stato inattivo. Tuttavia il timer tick non è il solo motivo di wakeup eccessivi della CPU, anche le chiamate della funzione delle applicazioni possono impedire alla CPU di entrare o restare in uno stato inattivo. Le suddette chiamate sono state ridotte in oltre 50 applicazioni.
I/O ridotto di rete e di storage
L'Input o output (I/O) per i dispositivi di storage e le interfacce di rete forza un consumo energetico da parte dei dispositivi. Nei dispositivi di rete e di storage che presentano stati di alimentazione ridotta quando inattivi (per esempio ALPM o ASPM), questo traffico può impedire al dispositivo di entrare o restare in uno stato inattivo, impedendo l'arresto del disco fisso se non utilizzato. Richieste eccessive e non necessarie allo storage sono state minimizzate in numerose applicazioni. In particolare quelle richieste che impedivano al disco fisso di arrestarsi.
Verifica di Initscript
I servizi che si avviano automaticamente sono causa di perdita di risorse del sistema. Al contrario i suddetti servizi dovrebbero essere impostati per default su "off" o "on demand" quando possibile. Per esempio il servizio BlueZ il quale abilita il supporto per Bluetooth, in precedenza veniva eseguito automaticamente all'avvio del sistema senza considerare se l'hardware Bluetooth era o meno presente. L'initscript BlueZ ora controlla la presenza dell'hardware Bluetooth sul sistema prima di avviare il servizio.
Capitolo 4. Impiego
Questo capitolo descrive due tipi di impieghi attraverso i quali sono illustrati i metodi di configurazione ed analisi descritti in altre sezioni di questa guida. Nel primo esempio sono presti i server tipici mentre nel secondo è presente un laptop tipico.
4.1. Esempio — Server
Un server standard tipico presenta tutte le funzioni hardware necessarie supportate in Red Hat Enterprise Linux 6. La prima cosa da considerare è il tipo di carico di lavoro per il quale verrà usato il server. In base a queste informazioni sarà possibile decidere i componenti da ottimizzare per il risparmio energetico.
Senza considerare il tipo di server, generalmente non sono necessarie le prestazioni grafiche. Per questo motivo il risparmio energetico GPU può essere lasciato abilitato.
Webserver
Un webserver ha bisogno di una rete ed un I/O del disco. In base alla velocità del collegamento esterno 100 Mbit/s dovrebbe essere sufficiente. Se la macchina serve maggiormente pagine statiche, le prestazioni della CPU potrebbero non essere molto importanti. La scelta per il risparmio energetico può quindi includere:
- nessun plugin di rete o disco per tuned.
- ALPM abilitato.
- regolatore
ondemandabilitato. - scheda di rete limitata a 100 Mbit/s.
Server di elaborazione
Un server di elaborazione ha bisogno di CPU. Le impostazioni per il risparmio energetico potrebbero includere:
- in base ai compiti ed al luogo dove verranno archiviati i dati, plugin di rete o disco per tuned; o per sistemi batch-mode, tuned completamente attivo.
- in base all'utilizzo, anche il regolatore
performance.
Mailserver
Un server di posta ha bisogno di I/O del disco e CPU. Le impostazioni per il risparmio energetico includono:
- Regolatore
ondemandattivato, poichè le ultime percentuali di prestazioni della CPU non sono importanti. - nessun plugin di rete o disco per tuned.
- la velocità di rete non dovrebbe essere limitata poichè la posta è spesso interna e quindi può trarre benefici da un link 1 Gbit/s o 10 Gbit/s.
Fileserver
I requisiti per il fileserver sono simili a quelli del server di posta, ma in base al protocollo usato potrebbe essere necessaria una prestazione più elevata della CPU. Generalmente i server basati su Samba richiedono più CPU di NFS, e NFS generalmente ne richiede più di iSCSI. Anche in questo caso l'utente dovrà essere in grado di usare il regolatore ondemand.
Directory server
Una directory server generalmente ha requisiti più bassi per l'I/O del disco, in particolare se possiede una RAM sufficiente. La latenza della rete è più importante dell'I/O. È possibile effettuare una regolazione della latenza di rete con una velocità ridotta del link, ma a tale scopo è consigliato eseguire una prova per la rete in questione.
4.2. Esempio — Laptop
I laptop rappresentano i sistemi più comuni sui quali è possibile avere una sostanziale differenza in termini di gestione e risparmio energetico. Poichè i portatili utilizzano una quantità di energia minore grazie al loro design rispetto alle workstation o server, il potenziale per un risparmio assoluto è minore rispetto ad altre macchine. Quando si utilizza la batteria qualsiasi tipo di risparmio può contribuire ad un maggior numero di minuti di vita della batteria di un laptop. Anche se questa sezione si concentra sull'utiizzo di laptop in modalità batteria, sarà possibile utilizzare alcune o tutte le regolazioni se si usa l'alimentazione AC.
Il risparmio su singoli componenti generalmente apporta una differenza relativa più elevata sui laptop che alle workstation. Per esempio, una interfaccia di rete di 1 Gbit/s in esecuzine a 100 Mbits/s risparmia circa 3–4 watts. Per un server tipico con un consumo energetico totale di circa 400 watts, tale risparmio rappresenta un valore dell'1 %. Su di un laptop con un consumo energetico totale di circa 40 watts, il risparmio energetico rappresenta il 10 % del totale.
Ottimizzazioni specifiche per un risparmio energetico su di un laptop tipico includono:
- Configurazione del BIOS del sistema per disabilitare tutto l'hardware non utilizzato. Per esempio, porte parallele o seriali, lettori schede, webcam, WiFi, e Bluetooth solo per fare alcuni nomi.
- Oscurare il display in ambienti più scuri dove non è necessario una illuminazione completa per leggere la schermata. Utilizzare + → sul desktop di GNOME, +++ → su desktop KDE; oppure sulla linea di comando gnome-power-manager o xbacklight o i tasti funzione sul laptop.
- Usare il profilo
laptop-battery-powersavedi tuned-adm per abilitare l'intero set di meccanismi per il risparmio energetico. In questo caso saranno interessate le prestazioni e la latenza dell'interfaccia di rete e del disco fisso.
In aggiunta (o alternativamente) sarà possibile eseguire piccole modifiche a varie impostazioni del sistema:
- usare il regolatore
ondemand(abilitato per default in Red Hat Enterprise Linux 6) - abilitare la modalità laptop (parte del profilo
laptop-battery-powersave):echo 5 > /proc/sys/vm/laptop_mode - aumentare il tempo di svuotamento sul disco (parte del profilo
laptop-battery-powersave):echo 1500 > /proc/sys/vm/dirty_writeback_centisecs - disabilitare il watchdog nmi (parte del profilo
laptop-battery-powersave):echo 0 > /proc/sys/kernel/nmi_watchdog - abilitare AC97 audio power-saving (abilitato per impostazione predefinita in Red Hat Enterprise Linux 6):
echo Y > /sys/module/snd_ac97_codec/parameters/power_save - abilitare il multi-core power-saving (parte del profilo
laptop-battery-powersave):echo 1 > /sys/devices/system/cpu/sched_mc_power_savings - abilitare l'auto-sospensione USB:
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; doneDa notare che l'auto-sospensione non funziona correttamente con tutti i dispositivi USB. - abilitare le impostazioni di alimentazione minima per ALPM (parte del profilo
laptop-battery-powersave):echo min_power > /sys/class/scsi_host/host*/link_power_management_policy - monatare il filesystem utilizzando relatime (default in Red Hat Enterprise Linux 6):
mount -o remount,relatime mountpoint - attivare la modalità migliore per il risparmio energetico (parte del profilo
laptop-battery-powersave):hdparm -B 1 -S 200 /dev/sd* - disabilitare il CD-ROM polling (parte del profilo
laptop-battery-powersave):hal-disable-polling --device /dev/scd* - ridurre la luminosità della schermata a
50o livello più basso, per esempio:xbacklight -set 50 - attivare DPMS per schermo inattivo:
xset +dpms; xset dpms 0 0 300 - ridurre i livelli di alimentazione Wi-Fi (parte del profilo
laptop-battery-powersave):for i in /sys/bus/pci/devices/*/power_level ; do echo 5 > $i ; done - disattivare Wi-Fi:
echo 1 > /sys/bus/pci/devices/*/rf_kill - limitare la rete cablata a 100 Mbit/s (parte del profilo
laptop-battery-powersave):ethtool -s eth0 advertise 0x0F
Appendice A. Suggerimenti per gli sviluppatori
Ogni buon manuale di progammazione affronta i problemi relativi all'assegnazione della memoria e alle prestazioni di determinate funzioni. Durante lo sviluppo del software tenere in considerazione le problematiche in grado di aumentare il consumo energetico sui sistemi sui quali viene eseguito il software. Anche se tali considerazioni non interessano tutto il codice, sarà possibile ottimizzare il codice stesso migliorando le aree che spesso possono limitare le prestazioni.
Alcune tecniche spesso problematiche includono:
- utilizzo dei thread.
- i wake-up della CPU non necessari e l'uso non efficiente dei processi di attivazione. Se necessario eseguire un processo di attivazione (race to idle), eseguire l'intero processo ed il più velocemente possibile.
- utilizzo non necessario di
[f]sync(). - interrogazioni attive non necessarie o brevi timeout regolari. (Reazione agli eventi).
- utilizzo non efficiente dei processi di attivazione 'wake-up'.
- accesso inefficiente del disco. Utilizzo di buffer molto grandi per evitare un accesso del disco frequente. Scrivere un blocco molto grande per volta.
- utilizzo inefficiente dei timer. Se possibile raggruppare i timer attraverso le applicazioni (oppure attraverso i sistemi).
- I/O eccessivo, consumo energetico, o utilizzo della memoria (incluso perdite di memoria)
- esecuzione di computazione non necessaria.
Le seguenti sezioni esaminano alcune delle suddette aree in maggior dettaglio.
A.1. Utilizzo dei thread
È comune pensare che l'utilizzo dei thread migliora le prestazioni e la velocità delle applicazioni, ma tali miglioramenti non si verificano in tutti i casi.
Python
Python utilizza il Global Lock Interpreter[1], per questo motivo il threading sarà utile solo per operazioni I/O significative. Unladen-swallow [2] è una implementazione più veloce di Python attraverso la quale sarà possibile ottimizzare il vostro codice.
Perl
I thread di Perl sono stati originariamente creati per applicazioni in esecuzione senza il forking (come ad esempio i sistemi operativi Windows a 32-bit). Nei thread di Perl i dati vengono copiati per ogni thread (Copy On Write). Per impostazione predefinita i dati non vengono condivisi poichè gli utenti dovrebbero essere in grado di definire il livello di dati da condividere. Per tale processo il modulo threads::shared deve essere incluso. Tuttavia il modulo non copierà solo i dati (Copy On Write), ma creerà anche delle variabili utilizzando una quantità maggiore di tempo rendendolo più lento. [3]
C
I thread C condividono la stessa memoria, ogni thread ha un proprio stack ed il kernel non deve creare nuovi descrittori per il file ed assegnare nuovo spazio di memoria. C può utilizzare il supporto di un numero maggiore di CPU per più thread. Per questo motivo e per massimizzare le prestazioni, usare un linguaggio low-level come ad esempio C o C++. Se si utilizzo un linguaggio di programmazione considerate la scrittura di un C binding. Utilizzare un profiler per identificare le sezioni con una prestazione scadente del codice. [4]
A.2. Processi di attivazione
Numerose applicazioni eseguono la scansione dei file di configurazione per la presenza di modifiche. In numerosi casi la scansione viene eseguita ad intervalli fissi, per esempio, ad ogni minuto. Ciò può presentare un problema poichè verrà forzata l'attivazione del disco dopo un suo arresto (spindown). La migliore soluzione è quella di trovare un intervallo idoneo, un buon meccanismo di controllo o di verificare la presenza di modifiche con inotify e reagire agli eventi. Inotify è in grado di verificare un numero elevato di modifiche presenti sul file o sulla directory.
Per esempio:
int fd;
fd = inotify_init();
int wd;
/* checking modification of a file - writing into */
wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY);
if (wd < 0) {
inotify_cant_be_used();
switching_back_to_previous_checking();
}
...
fd_set rdfs;
struct timeval tv;
int retval;
FD_ZERO(&rdfs);
FD_SET(0, &rdfs);
tv.tv_sec = 5;
value = select(1, &rdfs, NULL, NULL, &tv);
if (value == -1)
perror(select);
else {
do_some_stuff();
}
...
Il vantaggio offerto da questo approccio è rappresentato da una vasta gamma di controlli possibili.
La limitazione principale è che solo un numero limitato di watch è disponibile su di un sistema. È possibile ottenere tale numero tramite
/proc/sys/fs/inotify/max_user_watches ed anche se sarà possibile modificarlo, tale operazione non è consigliata. Altresì, nel caso in cui inotify fallisce, il codice deve cambiare il metodo di controllo, ciò significa che saranno presenti numerosi eventi #if #define nel codice sorgente.
Per maggiori informazioni su inotify consultare la pagina man di inotify.
A.3. Fsync
Fsync è conosciuto come operazione I/O molto esigente, ma ciò non è assolutamente vero. Per esempio, consultate l'articolo scritto da Theodore Ts'o Don't fear the fsync! [5] insieme alla discussione relativa.
Firefox chiamava la libreria sqlite ogni qualvolta l'utente selezionava un link per andare su di una nuova pagina. Sqlite chiamava
fsync e a causa delle impostazioni del file system (principalmente ext3 con modalità data-ordered), era presente un latenza lunga quando non accadeva nulla. Tale periodo poteva essere molto lungo (fino a 30 secondi) se un altro processo copiava contemporaneamente un file molto grande.
Tuttavia in altri casi dove
fsync non era usato si potevano verificare alcuni problemi smistandosi sul file system ext4. Ext3 era stato impostato in modalità data-ordered, la quale ripuliva la memoria ogni pochi secondi salvandola sul disco, Con ext4 e laptop_mode, l'intervallo tra i processi di archiviazione era più lungo con una potenziale perdita dei dati se il sistema veniva improvvisamente arrestato. Ora ext4 è stato aggiornato, ma anche in questo caso sarà necessario considerare con attenzione il design delle applicazioni ed usare fsync in modo appropriato.
Il seguente esempio di lettura e scrittura in un file di configurazione mostra com'è possibile eseguire un backup di un file o perdere i dati:
/* open and read configuration file e.g. ~/.kde/myconfig */
fd = open("./kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
close(fd);
Un approccio migliore potrebbe essere:
open("/.kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
fd = open("/.kde/myconfig.suffix", O_WRONLY|O_TRUNC|O_CREAT);
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
fsync; /* paranoia - optional */
...
close(fd);
rename("/.kde/myconfig", "/.kde/myconfig~"); /* paranoia - optional */
rename("/.kde/myconfig.suffix", "/.kde/myconfig");Appendice B. Cronologia di revisione
| Diario delle Revisioni | |||
|---|---|---|---|
| Revisione 1.0-10.400 | 2013-10-31 | ||
| |||
| Revisione 1.0-10 | 2012-07-18 | ||
| |||
| Revisione 1.0-2 | Fri Oct 22 2010 | ||
| |||
| Revisione 1.0-1 | Thu Oct 7 2010 | ||
| |||
| Revisione 1.0-0 | Thu Oct 7 2010 | ||
| |||
Nota Legale
Copyright © 2010 Red Hat Inc..
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
