L'acquisizione di nuovo hardware, a quanto pare supportato solo da kernel recenti, mi ha costretto ad affrontare uno dei peggiori incubi del sistemista: l'aggiornamento di kernel. Non è un vero e proprio incubo, perché in verità modernamente non è niente di complesso o faticoso, essendo già disponibili versioni pacchettizzate di versioni recenti; ho affrontato in passato in grandi realtà questo tipo di attività, ma sempre in ambiti dove le applicazioni erano scarsamente dipendenti dal sistema operativo (applicazioni Java, database Oracle, web server generici o file server). Qui da me la questione è differente e possiamo individuare almeno tre punti di attenzione:
non voglio soffermarmi su questi aspetti perché non è il tema dell'articolo, ma basti dire che per quanto riguarda Asterisk è stato necessario un aggiornamento da 1.4 a 1.6, per poter supportare il cambio di driver della scheda TDM da zaptel a dahdi; questo ha richiesto a sua volta un aggiornamento del driver per i telefoni Cisco (per fortuna il suo sviluppo è ripreso e sono quindi disponibili per la compilazione) e il codec g729. VMware Server attualmente è del tutto incompatibile con kernel recenti ma per fortuna qualcuno ha sviluppato una patch (aggiuntiva alla patch che già uso per il supporto delle VLAN) per estenderne la compatibilità. La parte domotica per fortuna non ha opposto resistenza.
Terminati i test di non regressione da 2.6.26 (Debian 5, Lenny) a 2.6.32 (Debian 6, Squeeze) durati quasi una intera giornata mi sono rilassato, soddisfatto di aver superato l'ostacolo. Masterizzo qualcosa, avvio nuovamente tutte le mie Virtual Machine... ma vedo che il mio piccolo server fatica a rispondermi. Un top mi comunica che l'estrema lentezza è dovuta ad un elevato i/o wait, insomma siamo tutti in attesa di dati provenienti probabilmente dai dischi.
Se c'è qualcosa che ho cambiato negli ultimi anni è il sistema di gestione dei dischi, passando dal RAID software del vecchio assemblatone al nuovo controller E200 del nuovo ML110G5, questo per vivere più sereno e avere finalmente un vero RAID hardware. Sembra però che si siano materializzati su di esso degli incudini che lo rendono particolarmente lento... cosa fare?
Una volta affrontato l'aggiornamento del kernel e di una marea di librerie e software, tornare indietro è una idea del tutto velleitaria, perché alcuni interventi sono notoriamente irreversibili, primo tra tutti il patching di VMware, per non parlare dell'avvicendamento di alcuni driver; bisogna quindi mantenere la posizione e contrastare l'avanzata dei problemi. Cercando in rete emerge che i problemi di performance si verificano a partire dal kernel 2.6.29, insomma per qualcuno il 2.6.28 viaggia a circa 90MB/s ed il 2.6.29 e successivi a circa 13MB/s; non mi sento di confermare queste stime ma sicuramente il server se la passa male, con un carico che sfiora i 20. Dopo varie ricerche e alcuni tentativi posso dirvi che le prestazioni tornano nella norma con i seguenti settaggi, che possono essere riportati in /etc/rc.local:
echo 64 >/sys/block/cciss\!c0d0/queue/read_ahead_kb
echo 0 >/sys/class/block/cciss\!c0d0/queue/iosched/low_latency
echo deadline >/sys/class/block/cciss\!c0d0/queue/scheduler
in pratica in buona parte dei casi si riportano alcune variabili ai valori di default delle precedenti versioni di kernel, in particolare read_ahead_kb, nel 2.6.29+ di default a128K, e lo scheduler, che in passato era deadline ed oggi sarebbe cfq. Ora il server è più scattante e in attesa di novità questa risulta essere una buona soluzione, valida sia per Debian 6 ma immagino anche per RedHat 6 e derivate.