Magari non sono del tutto normale, ma avevo già provato la Xandros per qualche ora sull’Eee 701 di un amico, quindi prima ancora di acquistare l’Eee avevo già decise che ci avrei installato Debian. Avevo quindi bisogno di sapere le prestazioni del sistema originale, in modo da valutare se con una Debian ottimizzata “a mano” le prestazioni sarebbero state migliori o peggiori.

Cronometro alla mano (quello incluso nel cellulare…) ho iniziato a misurare un po’ di tempi. Non saranno precisi al millesimo di secondo, ma mi servono soprattutto per avere un’idea di massima. Vediamoli.

Boot e shutdown

Ho cronometrato 4-5 volte il tempo di boot, e i sisultati sono stati più o meno simili: circa 27 secondi dalla pressione del tasto di accensione all’apparizione del desktop completo di applet e icone della tab “Internet”. La spia dell’SSD lampeggia ancora un paio di volte in seguito, ma non ho capito ancora perché. Probabilmente precarica qualche libreria in RAM.

Lo shutdown impiega tra i 5 e i 6 secondi, dalla pressione sul tasto “OK” del requester, fino al completo spegnimento dell’ultimo LED sul frontale.

Qui devo fare una piccola critica alla Xandros, anche se credo sia dovuta all’indirizzo “utontesco” di questa versione. Per spegnere l’Eee bisogna premere il tasto di accensione (o l’apposita iconcina rossa in basso a destra), appare un requester che chiede se attivare il task manager, andare in standby, riavviare o chiudere la sessione. Premendo “chiudi sessione” appare un ulteriore requester che chiede conferma. Tre click per spegnere… Avrei preferito che il secondo requester di conferma non ci fosse stato.

Pochi minuti fa ho aggiornato il BIOS alla nuova versione 0601, e ho ripetuto i test. Nessun cambiamento significativo. Poi ho visto un’opzione nel BIOS di nome “Boot Booster”, disattivata di default. Ho fatto un giro sui forum di eeeuser.com per vedere a cosa servisse, ed ho scoperto che attivandola il BIOS si tiene una cache dei dispositivi rilevati al boot, quasi azzerando il tempo del rilevamento effettuato dal BIOS dopo la prima accensione.

Questa opzione sembra dia problemi con Windows XP, probabilmente perché questo S.O. si appoggia molto al BIOS per rilevare le periferiche, mentre non ho trovato segnalazioni per quanto riguarda Linux. Quindi l’ho attivata!

Al primo boot, naturalmente, nessuna differenza rispetto a prima, ma al secondo la schermata del BIOS è stata praticamente invisibile (occhio a premere F2 velocemente, se vi serve entrarci!) ed è apparsa subito quella di boot di Xandros. Il tempo di boot è sceso a 20 secondi a batteria e a 15 secondi con alimentazione collegata, immagino che Linux sia configurato per andare in modalità risparmio energetico più spinto quando si utilizza la batteria.

Non ho rilevato problemi di nessun tipo: le schede SD e le memory card USB vengono rilevate, ed anche l’indicatore della batteria funziona correttamente. Probabilmente perché la prima cosa che fa Linux dopo il boot è ignorare il BIOS e rifare tutto da solo.

Applicazioni

Un po’ di tempi per il caricamento delle applicazioni, rilevati con alimentatore scollegato, per simulare le condizioni di mobilità.

Firefox si carica in 4 secondi. Openoffice Writer in 9 secondi. Acrobat in 4 secondi. Thunderbird in circa 6 secondi. SMPlayer in 2 secondi. Il resto solitamente in 2 secondi o meno.

Memoria

A sistema appena avviato la memoria occupata è di circa 170 MB, ma solo 90 sono di applicazioni (tra cui il terminale), mentre oltre 80 sono di cache.

Tra le applicazioni caricate ci sono IceWM (circa 5.5 MB) come Window Manager, AsusLauncher (13.5 MB) per la gestione del desktop, diverse applet di monitoring (7 MB circa l’una) per un totale di circa 45 MB e alcuni servizi in background, tra cui CUPS, Samba e, naturalmente, udev e X.

Per quanto riguarda le SSD interne, quella da 4 GB è riservata al sistema ed è partizionata in modo un po’ particolare con UnionFS, così da poter ripristinare le impostazioni di fabbrica senza formattare, e quella da 16 GB è montata sotto /home.

1.2 GB liberi sulla root e 14.5 sulla /home.

Batteria

Ma veniamo alla parte interessante.

Ho fatto un primo test di durata della batteria. Non molto scientifico e non assolutamente affidabile, ma che può dare un’idea delle reali condizioni di utilizzo. Il test è stato eseguito con il BIOS originale (0501), quindi senza i nuovi tweak per aumentare la durata. Nei prossimi giorni farò dei test col nuovo BIOS.

La luminosità dello schermo è stata impostata al massimo, lo screensaver disattivato, il WiFi attivato e collegato all’access point e quindi ad Internet per tutto il tempo. Per la prima ora il segnale WiFi era all’80% (ma secondo me era un po’ ottimistico, visto che la velocità non era granché), al piano di sotto (l’AP è al piano di sopra), in linea d’aria a circa 8-10 metri dall’AP (ma con un pavimento e un muro in mezzo), mentre in seguito era al 100% (a 4-6 m dall’AP, sullo stesso piano, con solo un muro in mezzo).

Dopo mezz’ora la batteria segnava già 80%. Dopo un’ora 70%. In questo periodo ho visualizzato continuamente video su Youtube. Poi per mezz’ora ho giocato a Tuxracer. Al termine la batteria segnava 60%. A questo punto l’ho spento (dovevo uscire…).

Alla riaccensione, dopo poco la batteria è scesa al 50%. Visitato il sito delle webradio (il link è già inserito tra i bookmarks), attivato Radio Deejay e provate alcune applicazioni con la musica in sottofondo, tra cui anche Youtube, di cui non si sentiva l’audio. Probabilmente i due plugin, flash e mplayer, bloccano la scheda audio, quindi si possono usare solo uno alla volta. Ho continuato così per circa mezz’ora, quindi ho spento, con la batteria al 40%. Totale finora: 2 ore.

Riacceso dopo un’oretta, la batteria indicava ancora 40%. Mi sono ricollegato alle webradio ed attivato Deejay, ancora un po’ di Youtube e di navigazione generica. Ho aperto OOo e scritto un po’ di righe di prova (il correttore ortografico era attivo). Alla seconda ora e mezza la batteria è scesa al 20% e il led relativo ha iniziato a lampeggiare arancione. Intorno alle 2 ore e 45 è apparso un requester che mi avvisava che entro 4 minuti il computer si sarebbe spento, e di salvare tutti i dati o di collegare l’alimentazione.

Naturalmente l’ho lasciato “soffrire” e, dopo 2 ore, 52 minuti e 30 secondi, è partita la procedura di shutdown.

Devo dire che sono rimasto parecchio soddisfatto del risultato. Quasi tre ore di autonomia con il WiFi sempre attivo, con decoding di video quasi continuo, con mezz’ora di grafica 3D a dettagli molto alti (a proposito, se vi interessa, Tuxracer faceva 8-12 fps con le ombre attive e 12-15 senza ombre, ma disattivando il conteggio degli fps mi è sembrato più fluido) ed altre applicazioni usate in contemporanea, tra cui anche la webcam per una decina di minuti.

Non faccio spesso questo uso del notebook. Per la maggior parte del tempo scrivo o leggo, ma non guardo quasi mai video e raramente ascolto musica, quindi prevedo che per il mio uso la durata sarà molto maggiore.
Purtroppo il geek dentro di me ha insistito per aggiornare il firmware prima di fare un test senza WiFi e con luminosità abbassata, soprattutto perché non avrei saputo cosa fare per tre ore senza un collegamento a Internet. Inizierò a sfruttarlo davvero, principalmente per scrivere e programmare, solo dopo aver installato Debian e tutto il software che mi serve (Abiword, Geany, Apache, MySQL, PostgreSQL, ecc.).

Lo schermo

Una nota riguardo la luminosità dello schermo: non c’è differenza sostanziale tra tenerla al 50% e al 100%, e anche al minimo lo schermo è leggibilissimo, anche se alcuni potrebbero trovarlo un po’ troppo scuro. Già al 30-35% comunque è quasi come a luminosità piena. Magari non potrete farci grafica professionale (siete pazzi??), ma la resa dei colori è, secondo me, molto buona.

Altre informazioni alla prossima puntata!

© Alex for /dev/random, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: asus, Linux, ottimizzazione, subnotebook

Feed enhanced by Better Feed from Ozh

Qualche giorno fa Donald Knuth, uno dei mostri sacri della programmazione, autore di vari libri della serie Art of Computer Programming, ha rilasciato un’intervista a InformIT in cui, tra le altre cose, esprime un parere estremamente negativo sulla attuale tendenza dei produttori hardware verso le architetture multi-core.

Il suo pensiero si può riassumere più o meno con: i produttori hardware non sanno più come migliorare le prestazioni dei loro chip, quindi hanno riciclato l’idea del multiprocessing, mantenendo le prestazioni fisse (o inferiori) su un singolo core, e mettendo diversi core per poter dire che la CPU è più veloce. In questo modo fanno ricadere la “colpa” nel mancato rispetto della legge di Moore (il raddoppio della potenza di elaborazione ogni 18 mesi) sui programmatori, dicendo che non sono in grado di scrivere software adatto alle nuove architetture.

Io, come diceva un saggio, sono “completamente d’accordo a metà col mister”.

Il problema hardware

Tutto si riconduce alla sostanziale stagnazione delle prestazioni delle CPU single-core da qualche anno a questa parte. Si sono raggiunte miniaturizzazioni oltre le quali si rischia di creare corto-circuiti tra i componenti, e frequenze oltre le quali si rischia di generare interferenze tra le piste o, peggio, surriscaldamenti e consumi sproporzionati, che possono portare la CPU a fondere o a esplodere letteralmente in mancanza di sistemi di raffreddamento che sono sempre più esagerati (dai ventoloni da 6″ a 5-6000 giri/minuto a sistemi di raffreddamento a liquido o a celle di Peltier).

Semplicemente sembra che la tecnologia abbia quasi raggiunto il suo limite e, a meno di un “breakthru” nei metodi costruttivi, che comunque molti stanno cercando nel campo ottico o quantistico, sarà difficile spremere ulteriore potenza ai chip.

La soluzione, quindi, è stata quella di riciclare la vecchia idea del multi-processore, ma ottimizzandola: si mettono più processori sullo stesso chip, in modo da non occupare il bus principale di sistema durante le sincronizzazioni tra core, che quindi rimane libero per i trasferimenti da e per la RAM e il resto del sistema. Sono ormai diffusissimi i dual core, e si vedono tri-core, quad-core e anche chip a 8 core.

Il risultato, indubbiamente, è quello di raddoppiare, triplicare, quadruplicare o ottuplicare la “potenza” disponibile.

Il problema software

Dal punto di vista software le cose non sono così semplici, purtroppo.

Il primo problema è quello a carico del Sistema Operativo, che deve garantire una certa sicurezza all’utente: che i suoi dati siano integri. In un’architettura multiprocessore (o multi-core, che è praticamente la stessa cosa) fisicamente vengono eseguite più operazioni contemporaneamente. Questo significa che ognuno dei core può (o potrebbe) modificare la stessa cella di memoria, o magari leggerla mentre un’altro la sta scrivendo, per non parlare dell’accesso contemporaneo a una periferica.

Parte di questo problema viene risolta dall’hardware, che arbitra l’accesso al bus ai processori, ma buona parte viene comunque delegata al S.O., visto che comunque una operazione che un software ritiene “elementare” come può essere scrivere un carattere sullo schermo viene spezzettata in decine o centinaia di istruzioni a livello assembly.

Inoltre il S.O. deve mantenere una certa affinità di un processo con una CPU, per evitare che dopo un context switch, un processo rimbalzi tra una CPU e l’altra, svalidando continuamente la cache relativa, e quindi ammazzando le prestazioni. Ma anche l’affinità deve essere tenuta sotto controllo, per evitare che, morti tutti i processi che giravano su una CPU, i restanti sfruttino solo l’altra, dimezzando le prestazioni.

Questo porta quindi a dei rallentamenti per proteggere zone di memoria o semplicemente per decidere su quale CPU/core debba essere eseguita una certa operazione.

L’altra faccia della medaglia è rappresentata dagli algoritmi: se c’è un solo processo che gira (e che fa calcoli pesanti, per esempio), questo occuperà una sola CPU, mentre l’altra sarà completamente inerte, dimezzando le prestazioni nel caso di un dual-core, o riducendole a 1/8 nel caso di un 8-core. Nel caso di 64 core…

Alcuni algoritmi possono essere resi paralleli, ma anche in questo caso si presentano diversi problemi: per esempio l’algoritmo potrebbe essere parallelizzabile in due “stream” di calcolo, ma allora in una CPU ad 8 core ne sfrutterebbe solo due. Oppure potrebbe essere parallelizzabil, per esempio, con un numero di processi pari a 1/4 del totale dei dati. Ma allora con 16 “dati” si potrebbero sfruttare bene 4 core ma non sfruttarne 8, ma soprattutto con un milione di “dati” si sfrutterebbero bene 250.000 core, ma avendone solo 2 si creerebbero 125.000 processi per core, costringendo il S.O. a gestire questa enorme coda di processi, con la possibilità di passare più tempo a sincronizzare i processi che ad eseguirli.

Visto l’attuale tendenza (2 core, 4 core, 8 core e in aumento costante) è difficile pensare ad algoritmi “ben parallelizzabili” su diverse architetture. In pratica è un bersaglio mobile.

La “terza faccia della medaglia” è data dal fatto che non è affatto semplice, oggi come oggi, scrivere codice parallelo.

Si possono scrivere programmi multiprocesso per isolare i dati da elaborare e comunicare solo tramite dei “bus” (code messaggi, buffer, ecc.) tra i vari processi in esecuzione, oppure multithread, condividendo la stessa area di memoria per evitare l’overhead dei suddetti bus, ma col rischio di andare a sovrascrivere aree di memoria sbagliate e quindi mandando a monte tutti i calcoli effettuati.

I linguaggi di programmazione attuali raramente offrono facilitazioni da questo punto di vista, quindi si tratta di un lavoro fondamentalmente manuale di sincronizzazione e trasferimento dati. Operazioni che rischiano di azzerare i vantaggi di un multicore, se effettuate in modo meno che ottimo.

Conclusioni

La situazione è abbastanza complessa, ma è già stata affrontata in passato, ed esistono tecniche di programmazione e librerie ben collaudate, ma rimane lo scoglio della difficoltà di ottimizzazione, soprattutto rispetto ad architetture che cambiano continuamente numero di core.

Dall’altra parte il multicore è un “male necessario”, altrimenti saremmo ancora fermi a 2 anni fa con le prestazioni, ed il nuovo processore Atom di Intel ne è la dimostrazione: single core a 1.6 GHz più lento del Celeron M a 900 MHz. Certo, consuma meno, ma fornisce prestazioni maggiori solo se in modalità dual-core.

Dovremo quindi abituarci a convivere con questa architettura almeno per qualche anno (poi, per i soliti corsi e ricorsi storici, si tornerà al single core, magari quantistico, finché non si riterrà nuovamente necessario ricorrere ai multi-core quantistici, ecc. ecc.).

Per i programmatori significa adeguarsi ad imparare la programmazione concorrente, e la mia speranza è che i nuovi linguaggi che si stanno affacciando ora sul mondo (D, Vala, ecc.) forniscano strumenti semplici per ottenerla. Con alcuni linguaggi semplicemente è impossibile programmare in modo concorrente, quindi potrebbero essere destinati se non all’oblio almeno a un forte ridimensionamento, in caso non si adeguassero.

Per gli utenti significa capire il proprio PC, e sfruttarlo al meglio. Per esempio lanciare due istanze della stessa applicazione contemporaneamente al lavoro su dati diversi per sfruttare entrambi i core, se l’applicazione non li supporta di suo. Un caso emblematico: compilando software su Linux con make è sufficiente specificare l’opzione -j seguita dal numero di job contemporanei da eseguire. Conviene usare n+1, dove n è il numero di CPU/core, quindi 3 per un dual-core, 5 per un quad-core, ecc. (il +1 serve a sfruttare tutte le CPU in compilazione mentre il processo extra legge o scrive su disco).

© Alex for /dev/random, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: best practices, ottimizzazione, Programmazione

Feed enhanced by Better Feed from Ozh

Per motivi di efficienza nell’allocazione delle risorse, ogni (buon) programma su Linux si appoggia a una serie più o meno lunga di librerie condivise, le cosiddette Shared Objects, riconoscibili per l’estensione .so

Queste librerie sono gestite in modo da averne in memoria una sola copia in ogni momento, e tutti i software che hanno bisogno delle funzioni fornite leggono dalla stessa copia in memoria. In questo modo si risparmia RAM e tempo di caricamento da disco, in quanto la libreria viene letta da disco una volta sola e poi viene collegata (link) agli eseguibili che ne fanno richiesta.

Ma c’è un problema: ogni programma ha una sua area di memoria isolata dagli altri programmi, e il kernel deve mappare all’interno di ognuna di queste aree le diverse librerie, e ricalcolare tutti gli offset delle funzioni all’interno del binario che le richiama. Questa operazione ha il vantaggio di slegare completamente il binario dalle librerie (possiamo avere due versioni della stessa libreria in memoria con due software diversi che le usano, e caricarli quando vogliamo), ma ha lo svantaggio che, al caricamento del programma, tutte queste mappature devono essere ricalcolate.

Ma c’è, naturalmente, un modo per rendere più efficiente questa operazione.

Prelink

Ed è qui che ci viene in aiuto prelink. Questo software, infatti, analizza tutti i programmi e tutte le librerie che abbiamo installato, e precalcola una volta per tutte degli spazi in memoria dove andranno allocate, quindi modifica i binari stessi per “suggerire” tale allocazione. Può anche spingersi ad analizzare le librerie che non vengono mai usate contemporaneamente e sovrapporre le loro aree di memoria, in modo da ottimizzarne la gestione.

Ma allora perché non lo usano tutti, chiederete voi! Il motivo principale è che ogni volta che si aggiorna qualcosa questo prelinking viene perso, quindi le prestazioni decadono, anche se lentamente. Un altro motivo è che alcuni vecchi software non lo supportano molto bene e rischiano di smettere di funzionare. Per esperienza personale non ne ho ancora incontrato uno, a dire il vero. In ogni caso prelink permette anche l’undo, quindi di ripristinare i binari come erano in origine.

Ma se avete una macchina che non aggiornate troppo spesso (un server, un palmare, ma anche un client, a meno che non usiate Debian sid o non aggiorniate la Debian testing 2-3 volte al giorno), o se siete disposti ad aspettare qualche minuto in più alla fine di ogni aggiornamento, il gioco vale decisamente la candela.

Come usarlo

Se avete una Debian (e, presumo, anche una Ubuntu o altre derivate da Debian), l’installazione e la configurazione sono banali:

aptitude update
aptitude install prelink

vi installerà il pacchetto assieme agli script cron necessari. Controllate il file /etc/default/prelink e, se necessario, modificate la linea che inizia con PRELINKING:

PRELINKING=yes

Nello stesso file ci sono altre opzioni impostabili. Lasciate così com’è la seguente:

PRELINK_OPTS=-mR

mentre, se aggiornate spesso, può essere utile modificare l’intervallo in giorni a cui avviene un “full prelink”:

PRELINK_FULL_TIME_INTERVAL=5

Questo specifica ogni quanti giorni il cronjob farà uno scan completo del sistema per ricalcolare i prelink. In questo caso l’abbiamo impostato a 5 giorni. Potete metterlo a 14 o a 30 se aggiornate molto poco (un server, per esempio), oppure a 1 o 2 se aggiornate ogni giorno.

C’è un ultimo parametro in questo file:

 PRELINK_NONRPM_CHECK_INTERVAL=7

Questo serve a specificare che se non ci sono stati cambiamenti di pacchetti (installazioni o disinstallazioni) negli ultimi 7 giorni, non viene comunque forzato un full prelink, e viene eseguito un prelink incrementale. Funziona analizzando il file di stato della distribuzione, quindi non lasciatevi ingannare da quell’RPM: funziona anche coi deb (se usate il pacchetto deb di prelink, naturalmente).

La configurazione è finita. Tranne la prima riga, che di solito è undefined o no di default, le altre potete anche lasciarle come sono. Non era difficile, no?

Avvio del prelink

Ora potete aspettare che cron faccia il suo lavoro (verso le 6 di mattina per il default Debian), o che lo faccia anacron (se spegnete la macchina ogni sera e, naturalmente, avete installato anacron).Oppure potete lanciare l’operazione manualmente richiamando, da utente root, direttamente il cronjob:

/etc/cron.daily/prelink

Undo

Se volete tornare alla situazione di partenza, togliendo tutti i prelink, il comando da dare, sempre da root, è:

prelink -au

Disclaimer

Come ho detto all’inizio, io finora non ho avuto alcun tipo di problema da prelink, e lo uso su una lenny (e prima su una etch, quando era testing) da oltre due anni. Ma, come dicono i ‘mmericani, your mileage may vary: potreste avere qualcosa che non va con prelink, o potrebbe saltarvi la corrente mentre scrive libc.so e impastarvi il sistema (compratevi un UPS!). A vostro rischio e pericolo. Ma la differenza sui tempi di caricamento si vede a occhio nudo, soprattutto su pacchetti grossi come OpenOffice o simili.

 Altre opzioni

La manpage di prelink elenca molte opzioni possibili. Per un uso normale non servono, ma se volete addentrarvi nei meandri del funzionamento del link su Linux, man prelink è vostro amico. L’unica opzione su cui voglio richiamare l’attenzione è -R, che comunque viene impostata di default in Debian, e serve a rendere casuale l’indirizzo di allocazione di ogni libreria. Questo serve ad evitare che un attaccante (un cracker) che abbia un sistema come il vostro possa prevedere a quale locazione di memoria viene installata una certa libreria, rendendogli più facile l’attacco.

In /etc/prelink.conf la Debian preimposta già quali directory controllare e quali tipi di file ignorare durante il prelink. Si può personalizzare questo file nel caso si installino binari in luoghi fuori dalla gestione della distribuzione (per esempio in /usr/local o in /home). La sintassi è molto semplice, se avete letto e capito il man, altrimenti evitate di metterci mano.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: desktop, Linux, memoria, ottimizzazione, server

Feed enhanced by Better Feed from Ozh

Durante questa ricerca sono incappato in due documenti che raccolgono una messe di informazioni su come configurare varie componenti in diversi modi.

Non sono sempre “digita e dimentica”, anzi, a volte richiedono un’analisi preventiva dell’hardware presente, e un tuning dei parametri per funzionare al meglio, ma sono una bella lista abbastanza completa. Alcune cose le ho già scritte nella prima parte di questo articolo.

Ma ecco i link: Velocizzare Debian e Recuperare spazio sull’HD.

I consigli sono diretti a utenti Debian, ma la maggior parte sono validi per qualsiasi distribuzione.

Non tutti sono da applicare ad occhi chiusi, ma richiedono una minima conoscenza del (sotto-)sistema che si sta configurando. Magari in futuro ne estrapolerò qualcuno e lo approfondirò qui. Nel frattempo ne approfitto per ringraziare il progetto Linguistico per queste e per le altre guide che hanno pubblicato, oltre che per i dizionari e i thesaurus in italiano, naturalmente.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: Debian, Linux, memoria, ottimizzazione, server, storage

Feed enhanced by Better Feed from Ozh

• powernow_k6: per le CPU AMD K6 mobile (K6-2+ e K6-3+)
• powernow_k7: per AMD Athlon, Duron e i Sempron a 32 bit
• powernow_k8: per le CPU AMD a 64 bit: Athlon 64, Turion 64, Sempron 64, Opteron 64
• p4_clockmod: per pentium 4, Celeron D, Pentium D, Celeron M
• speedstep_centrino: per Pentium M (Centrino), Core Duo, Core 2 Duo
• longrun: per CPU Transmeta
• longhaul: per CPU Via Cyrix (quelli delle Epia, per esempio)
• e_powersaver:per CPU VIA C7

Purtroppo ho scoperto anche che il p4_clockmod che devo usare per il mio Pentium-D non risparmia energia, ma aiuta solamente a ridurre la temperatura.

Per automatizzare la gestione del frequency scaler ci sono diversi programmi, ma quello che trovo migliore è powernowd che, nonostante il nome, è compatibile con tutte le CPU, perché non è altro che un’interfaccia al sysfs del kernel, che si occupa di tutto. Powernowd non fa altro che verificare il carico sulla CPU a intervalli costanti (configurabili, di default una volta al secondo) e, se sale oltre un certo limite (di default 80%, io l’ho impostato al 50%) aumenta la frequenza della CPU secondo un algoritmo, anch’esso configurabile (di default schizza al massimo e poi scende lentamente, ma si può impostare al contrario, oppure che salga e scenda gradualmente). Quando l’utilizzo scende sotto una certa soglia (di default 20%) cala la frequenza secondo l’algoritmo impostato. Non ha un file di configurazione, solo alcuni semplici flag che, in Debian, si impostano in /etc/default/powernowd in modo che lo script di avvio li trovi.

Mentre testavo questi aggeggini mi sono capitati davanti anche due pacchetti deb molto utili: cpufrequtils e sysfsutils. Il primo fornisce alcuni comandi per interrogare e impostare i parametri di cpufreq, appunto. Usando powernowd non dovrebbero essere necessari (gestisce tutto lui), ma cpufreq-info può essere utile per avere informazioni dettagliate sulle capacità di risparmio energetico della CPU.

sysfsutils fornisce il comando systool per interrogare i vari sottosistemi riconosciuti dal kernel attraverso il file-system virtuale /sys. Onestamente non l’ho usato molto, e non saprei nemmeno immaginarne un uso, che sicuramente c’è per utilizzi avanzati.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: Linux, ottimizzazione, risparmio energetico

Feed enhanced by Better Feed from Ozh

Martin Michlmayr ha pubblicato un paio di articoli su come ottimizzare Linux per l’uso su dispositivi embedded (NSLU2 nel caso specifico): per la riduzione della memoria occupata e per il funzionamento su memorie flash.

Ma molti consigli valgono anche in generale per migliorare le prestazioni di Linux, sia su dispositivi portatili che non. Ne traduco qui alcuni e mi permetto di aggiungerne altri che possono tornare utili, con un’occhio all’uso desktop e uno all’uso server.

Accesso al disco

Linux ha un ottimo sistema di gestione dei dischi, ma di default offre funzionalità che migliorano l’affidabilità e la tracciabilità delle operazioni, perfette per un server, ma costose per le prestazioni su un PC desktop, un portatile o un palmare/cellulare.

Atime

Una di queste è l’atime dei file: viene memorizzata su disco la data e ora dell’ultimo accesso al file. Questa funzione è utile in rarissimi casi, pertanto si può disattivare senza problemi, perché causa una scrittura su disco per ogni lettura effettuata. Sui normali dischi si guadagna in prestazioni, mentre sulle memorie flash si guadagna anche in durata del supporto (le scritture sono limitate su questi dispositivi). Per disattivarlo è sufficiente modificare (da utente root) il file /etc/fstab aggiungendo l’opzione “noatime” ai vari mount-point.

Commit time

Sempre in questo file possiamo modificare il tempo di commit di ext3, in modo da effettuare meno scritture su disco, e da scrivere più dati in un colpo solo, migliorando le prestazioni. Di default sono 5 secondi, ma possiamo alzarlo a 2 minuti (120 secondi). In questo caso lo svantaggio è che se salta la corrente quando i dati non sono ancora stati scritti se ne perderanno di più. Il mio consiglio è di avere sempre un UPS (un gruppo di continuità) anche piccolo (500-650 VA sono sufficienti per reggere 5-10 minuti, dipende dal carico del vostro PC) ed evitare sia questo problema che quello delle sovratensioni che si verificano ogni tanto e che bruciano alimentatori.

fstab

Andiamo quindi a vedere come modificare il nostro /etc/fstab

# /etc/fstab: static file system information.#

# <file system> <mount point>   <type>  <options>                     <dump>  <pass>

proc            /proc           proc    defaults                        0       0

/dev/hda1       /               ext3    defaults,errors=remount-ro,noatime,commit=120 0       1
/dev/hda3       /home           ext3    defaults,noatime,commit=120     0       2
/dev/hda4       /usr            ext3    defaults,noatime,commit=120     0       3
/dev/hda2       none            swap    sw                              0       0

syslog

Possiamo anche modificare syslog perché bufferizzi i log prima di scriverli su disco. Sui normali dischi questo può ridurre la frammentazione, oltre a evitare di scrivere continuamente su disco pochi bytes, mentre sulle memorie flash il vantaggio è lo stesso del noatime: si prolunga la vita della flash. Lo svantaggio è che se il computer ha un crash (molto raro, ma può succedere) o se manca la corrente si perdono i dati dei log degli ultimi minuti. Quindi non attivatelo se state testando nuovi kernel instabili, moduli proprietari del kernel o driver per X o per qualsiasi cosa giri coi permessi di root e vi servono log affidabili. Su un server potrebbe essere addirittura conveniente togliere il buffering già presente su alcuni file.

Il file da modificare, in questo caso, è /etc/syslog.conf e basta aggiungere un trattino (il normale “meno”) prima del nome del file di log. Ecco un esempio:

#  /etc/syslog.conf     Configuration file for syslogd.#

# First some standard logfiles.  Log by facility.

#auth,authpriv.*           /var/log/auth.log
*.*;auth,authpriv.none    -/var/log/syslog
#cron.*                    /var/log/cron.log
daemon.*                  -/var/log/daemon.log
kern.*                    -/var/log/kern.log
lpr.*                     -/var/log/lpr.log
mail.*                    -/var/log/mail.log
user.*                    -/var/log/user.log

Questo è un pezzo del file standard della Debian. Come vedete alcuni file hanno già il trattino davanti, e vengono bufferizzati. Si tratta solitamente di log meno importanti, per cui non è necessario avere un riscontro preciso nei file, mentre, ad esempio, il file di log delle autorizzazioni (quello che vi scrive “root ha fatto login alle 02:37:21 del 25 dicembre”) viene scritto direttamente su disco per motivi di sicurezza. Qui tale log è disattivato.
Le prestazioni guadagnate in questo caso non sono granché, quindi questa modifica ha senso solo su dispositivi con flash memory: palmari, cellulari, media-center e simili, dove interessa poco avere log precisi ed aggiornati. Si può invece aggiungere (o decommentare nel caso della Debian) una sezione apposita che vada a scrivere i log su una console non utilizzata. Io uso quella in Alt-F12:

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty12

In questo modo c’è un riscontro diretto in tempo reale con i più importanti servizi di sistema. Su un server si può addirittura lasciare attiva quella console di default, in modo da vedere i messaggi di log semplicemente accendendo il monitor, senza fare login.

Memoria

Nei PC moderni ormai la memoria si spreca. Non è raro avere 1, 2 o addirittura 4 Gb di RAM, soprattutto se il PC è in dual-boot con Windows per giocare.

SWAP

Allora la cosa migliore da fare è usare tale memoria e limitare al minimo l’uso della swap e del disco in generale, molto più lento della RAM. Nei kernel 2.6 c’è un parametro apposta per indicare al sistema quanto deve usare la swap: /proc/sys/vm/swappiness

Basta fare un cat di tale file per vederne l’impostazione, e con un echo regolare la quantità che vogliamo:

~# cat /proc/sys/vm/swappiness
60

Se vogliamo ridurre al minimo l’uso della swap (a scapito dei buffer e delle cache dei file aperti) possiamo metterlo a 0, per esempio su un sistema desktop in cui si passa spesso da un’applicazione all’altra. Se vogliamo che il sistema metta in swap più memoria possibile possiamo metterlo a 100, per esempio su un server dove ci sono alcune applicazioni che vengono lanciate ogni tanto (i backup) e quindi possono essere messe in cache, mentre vogliamo massimizzare i buffer per avere più dati possibili in memoria in ogni momento (per esempio le pagine web da servire ai client). Basterà quindi un:

echo 10 >/proc/sys/vm/swappiness

per abbassare senza esagerare la tendenza allo swap. Possiamo rendere permanente questa modifica aggiungendo al file /etc/sysctl.conf questa riga:

vm/swappiness = 10

In questo file si possono inserire tutte le modifiche da fare al boot a qualsiasi cosa si trovi sotto /proc/sys come vedremo tra poco.

Cache in scrittura

A metà tra l’uso della memoria e quello del disco viene il laptop_mode, un sistema per impostare il sistema per l’uso minimo del disco. Ormai la sintassi per le modifiche è chiara, quindi andiamo a vedere direttamente come modificare sysctl.conf e quali parametri possiamo impostare:

vm/laptop_mode = 5
vm/dirty_writeback_centisecs = 12000
vm/dirty_expire_centisecs = 12000
vm/dirty_ratio = 95
vm/dirty_background_ratio = 20

Il primo parametro indica dopo quanti secondi, dal risveglio del disco causato da una lettura, iniziare una scrittura. Impostato a 0 disattiva il laptop_mode. Impostato troppo basso può rallentare la lettura per effettuare la scrittura. Qui l’abbiamo impostato a 5 secondi. Abbastanza da permettere di finire la lettura, e abbastanza poco da permettere al disco da tornare a dormire presto. Può essere utile, assieme ai parametri successivi, per l’uso con le flash memory per ridurre le scritture al minimo e migliorare le prestazioni, soprattutto se si ha una buona quantità di RAM.

dirty_writeback_centisecs specifica ogni quanto il kernel deve controllare se ci sono dati da scrivere, in centesimi di secondo. dirty_expire_centisecs specifica dopo quanto tempo i dati da scrivere devono fisicamente essere scritti sul disco. Conviene impostare questi due valori con lo stesso numero. Qui il kernel controlla ogni 120 secondi (2 minuti) se ci sono dati da scrivere e, se ci sono, li scrive su disco. Su un notebook, per far dormire il più possibile il disco, si può impostare a 15-20 minuti, stando attenti al livello della batteria.

dirty_ratio specifica quale percentuale della memoria usare per i dati in attesa. Possiamo impostarlo molto alto, in quanto i dati vengono comunque scritti su disco se la memoria serve per altro. dirty_background_ratio specifica la percentuale di memoria occupata dai dati in attesa alla quale il processo di scrittura si può fermare. Col parametro che abbiamo impostato sopra il sistema cercherà di scrivere dati su disco almeno finché questi non occuperanno il 20% o meno della memoria disponibile.

Questi parametri hanno senso su un portatile o su un dispositivo con memoria flash, ma possono aiutare anche a ridurre la frammentazione dei file su dischi con poco spazio libero (mentre su dischi con molto spazio libero il kernel ha un sistema di allocazione che riduce automaticamente la frammentazione man mano che si usa il disco).

Ridurre la memoria occupata

Naturalmente ha poco senso avere 1 Gb di memoria e lanciare decine di daemon in background senza usarli mai. Conviene quindi “spegnerli” ed attivarli solo quando servono. Per questa modifica bisogna capire, almeno a grandi linee, come funziona il sistema di init di Linux.

Al boot il primo software ad essere eseguito, dopo il kernel, è init, che legge il file /etc/inittab e ne lancia i vari script in base alle informazioni che vi trova. Tra questi c’è l’attivazione del runlevel di default, che in Debian è sempre il 2. Il livello 0 significa “spegnimento”, il livello 1 “monoutente”, il livello 6 “riavvio”. I livelli da 3 a 5 sono personalizzabili, ma per i nostri usi li considereremo equivalenti al livello 2. Quindi dovremo impostare i daemon che ci servono perché partano (start, quindi S) ai livelli da 2 a 5, e perché si fermino (kill, quindi K) ai livelli 0, 1 e 6, mentre impostaremo quelli che usiamo poco (apache, MySQL e Postgres, per esempio, se saltuariamente sviluppiamo per il web) perché siano K (kill) a tutti i livelli. Li avvieremo manualmente quando ci servono. In Debian possiamo usare update-rc.d per automatizzare il tutto, e avremo a disposizione anche alcune opzioni che ci semplificano la vita:

update-rc.d -f apache2 remove
update-rc.d -f mysql remove
update-rc.d -f postgresql-8.2 remove

I nomi da usare per i vari servizi li trovate guardando come si chiamano i file in /etc/init.d.

Questa forma (remove) cancella tutti i link di avvio e di stop del servizio, che quindi andrà sia avviato che fermato a mano prima di spegnere il computer. Dobbiamo quindi ripristinare lo spegnimento dei servizi allo shutdown/reboot/single-user:

update-rc.d apache2 stop 20 0 1 2 3 4 5 6 .
update-rc.d mysql stop 20 0 1 2 3 4 5 6 .
update-rc.d postgresql-8.2 stop 20 0 1 2 3 4 5 6 .

Buona parte degli script di avvio/fermata dei daemon tiene traccia del funzionamento di un daemon, quindi non darà alcun warning allo shutdown. Attenzione al punto alla fine delle righe!

Conclusioni

Si chiude qui questo primo articolo sull’ottimizzazione di Linux. Ci sono molti altri piccoli e grandi accorgimenti adottabili. Li vedremo nella prossima puntata.

© Alex for /dev/random, 2007. | Permalink | 5 comments | Add to del.icio.us
Post tags: Linux, memoria, ottimizzazione, storage

Feed enhanced by Better Feed from Ozh