TecnicaMENTE
Ci sono persone che riescono a parlare di roba che non capiscono in maniera tale che sembrano degli esperti, almeno ai non-esperti. Ci sono anche persone che riescono a parlare di roba che capiscono e conoscono in maniera tale che sembrano dei completi interdetti, agli esperti ed ai non esperti. E ci sono poi persone che non capiscono e non conoscono un argomento ma si intestardiscono a riempirsi la testa di articoli e nozioni e cercano poi di riversare le loro idee su persone che capiscono e conoscono l'argomento. Il risultato e' prevedibile.
Il grosso problema e' che se non si conosce o capisce un argomento e' molto difficile distinguere tra un articolo che e' una pila di cazzate ed un articolo serio. Soprattutto quando chi legge si e' gia' fatto una idea di cosa dovrebbe esserci scritto ed invece di leggere quello che c'e' scritto lo interpreta liberamente. Di solito (non so bene perche') quelli che cascano in questa categoria sono UL ed SL vari.
Ok, fine del preambolo. Ritorniamo a parlare di $noiguardiamolavostrarobba di cui ho gia' detto precedentemente. L'SL superstite (nel senso che e' l'unico rimasto in forze) e' impegnato a cercare di rimanere a galla e cacciare via i piranha che si aggirano. Per fare cio' sta cercando di spremere tutta la potenza che puo' dalla webapplicascion che costituisce l'unica sua fonte di guadagno. Il che e' cosa buona e giusta se non fosse che l'applicascion e' stata scritta da un programmatroto che non ha mai letto nessun manuale di programmazione. Una delle prime cose che io mi ricordo dei miei studi di programmazione di rete sono le seguenti regolette:
- La rete e' fallibile - fallira' quando meno te lo aspetti o piu' ti serve. Regolati di conseguenza
- Le risorse (memoria, processore, disco) non sono infinite, usale con parsimonia e rilasciale quando non ti servono
- La rete e' lenta. Non provare a fare cose in 'real time' perche' non funziona.
Che, lette cosi', sembrano estremamente logiche. Ma andate a dirlo ad un moderno programmatroto 'agile', 'flexible' e robe cosi' o al di lui capo e vi guardera' come un marziano.
Il risultato e' che l'applicascion assume che a) ogni connessione vada a termine in 0 nanosecondi b) si puo' allocare un infinita quantita' di memoria, disco e connessioni di rete e c) non c'e' bisogno di fare nessun controllo che le connessioni siano terminate correttamente. Il che assicura una marea di problemi. Come il fatto che una certa parte dell'applicascion deve essere riavviata giornalmente o crasha miserabilmente (di solito tra le 2 e le 3 del mattino) per out of memory.
Il rifacimento dell'intera webapplicascion dovrebbe anche risolvere certi "problemi di allocazione delle risorse". Ed in effetti una parte dei problemi vengono ridotti. Solo che SL comincia a prendere un'interesse quasi morboso nella "ottimizzazione" delle risorse. In particolare si mette a guardare cose di cui non capisce un tubo. Per esempio, dato che il suo sistema e' basato su un 'server' che riceve connessioni ed inserisce i dati in un database, diventa quasi nevrastenico al pensiero che il database "rimanga indietro".
Arriva pertanto una prima mail che domanda come si puo' "ottimizzare" il database. La mia risposta e' che non sapendo un tubo di come il database sia utilizzato dall'applicazione e' impossibile dare indicazioni precise. Ma dato che ho capito che questi pisquani cercano di infilare i dati il piu' in fretta possibile, a parer mio l'uso di un database -server- SQL sia una boiata e sarebbe molto meglio usare un database file-based o nessun database e poi riprocessare i dati off-line per poter analizzare le informazioni con comodo. Devo supporre che questo suggerimento sia entrato da un orecchio ed uscito dall'altro senza minimamente disturbare una delle migliaia di cellule cerebrali all'interno del cranio perche' un paio di ore dopo mi e' arrivata una seconda mail (quotando in toto la mia precedente) con un paio di link ad articoli di 'ottimizzazione' dei database scritti dai soliti noti di interdet e riportanti suggerimenti tanto innoqui quanto inutili. Okkido' mister, NMP!
Ovviamente le 'ottimizzazioni' non hanno alcun risultato ma se non altro SL e' contento ed ha esaurito le sue ore di assistenza gratuita per questo mese quindi mi rilasso fino al mese prossimo. E dato che hanno deciso che i rilasci li vogliono fare da soli non mi preoccupo nemmeno piu' di quando le loro applicascion si incartano.
Poi arriva il momento in cui l'SL vede il grafico del 'load average' del suo server e si spaventa a vedere un L.A. tra 4 e 5. Ora, premetto che un L.A. di 5 con una macchina biprocessore potrebbe anche essere considerato 'alto', ma io ho visto macchine monoprocessore con un load average di 20 andare avanti tranquille per dei mesi, quindi non e' che mi preoccupo moltissimo. Soprattutto dato che sto coso va' a "raffiche", ogni tanto si becca la raffica di connessioni e fa qualche cosa ma per il resto del tempo sta li' a girarsi i pollici. Ma spiegarlo all'SL della situazione e' praticamente impossibile.
Comunque sia, soppesando il costo di aggiungere una cpu al sistema (50 euro) ed il costo di continuare a fare il pieno al Volvo StascionUagon per un altro paio di giorni decide di rischiare e mettere la CPU. Mi ritrovo cosi' a vedere un server con 3 cpu (!). Vabbe'...
Tuttavia il capitale investimento non ha gli effetti che l'SL sperava. In particolare il load average rimane piu' o meno lo stesso. Percui mi becco l'odierna telefonata.
SL - Ma io mi chiedevo, le CPU che abbiamo aggiunto sono dualcore?
IO - E' una macchina virtuale quindi LA cpu che abbiamo aggiunto e' UNA cpu e basta, non essitono dual core.
SL - Ma se io guardo la descrizione della cpu in cosiliproc...
IO - Quello e' come la cpu si presenta al sistema ed il sistema riporta quello che vede e basta, ma e' UNA cpu e basta.
SL - Ma se e' dual core allora...
IO - E' una macchina virtuale, l'hardware virtuale puo' avere qualsiasi nome e non significa nulla. La Cpu e' UNA cpu e basta.
SL - Perche' se io guardo il load average allora devo dividerlo per 6 o per 12?
IO - ??? Che ? Il load average che c'entra adesso?
SL - Perche' io stavo leggendo questo articolo che...
Mi faccio mandare link del famoso articolo che risulta essere una roba che sembra messa insieme da un laureando in storia dell'architettura che ha incespicato su una rivista di informatica mentre broccolava studentesse nei pressi dell'aula magna, l'unica cosa giusta che dice e' una descrizione di che cosa il load average indica (cosa che puo' essere estratta da qualunque 'howto' o 'readme' sulla rete) ma a parte questo nada. Soprattutto fornisce indicazioni sul 'quanto' dovrebbe essere il load average che non hanno alcun senso. Dopo aver madonnato contro chi scrive articoli del genere e chi li legge senza capirli mi preparo a spiegare le cose all'SL.
SL - Quindi devo dividere il load per 6?
IO - Il load puoi dividerlo per quanto ti pare ma ci sono sempre e solo 3 cpu in quel coso. Ed il load non significa niente da solo. Il load e' solamente una indicazione di quanti processi concorrenti vengono eseguiti, non ti dice cosa quei processi stanno facendo. Non puoi fare ottimizzazione di un sistema guardando solo un elemento del sistema.
SL - Perche' io vedo che il database non resta indietro...
IO - E perche' dovrebbe restare indietro?
SL - Perche' il server e' troppo carico...
IO - Un load di 5 su un server, anche se avesse un solo processore non significa niente. Soprattutto dato che quello e' l'average di 5 minuti. Come ho gia' detto, non si possono fare ottimizzazioni guardando un solo parametro.
SL - Ma quell'articolo...
IO - Oltre a leggere l'articolo sarebbe bene anche leggere i commenti, soprattutto gli ultimi che lo tagliano a fettine con ottimi argomenti tecnici.
SL - Ma io non sono un tecnico
E questo lo avevamo capito tutti
SL - Ed e' per questo che domando a voi.
IO - Ed io ho risposto: il load average non significa nulla se non viene guardato insieme ad altri parametri. In questo caso quella macchina non si puo' considerare 'carica'.
SL - Quindi voi non consigliate di aggiungere processori?
IO - Al momento no. Ovviamente solo voi sapete cosa volete farci con questa macchina, se sia il caso di aggiungere processori adesso o aspettare.
Dopo un lungo tira-e-molla con SL che mi recita parti dell'articolo ed io che gli ri-spiego daccapo la faccenda, SL si convince che puo' aspettare ancora un po' e si rimette tranquillo. Ora, io lo so gia' che la settimana prossima ricomincera' a farsi venire le paturnie quando comincera' a pensare allo spazio libero sui dischi. Lasciamo perdere che lo spazio libero e' lo stesso dall'inizio dell'anno. Certa gente proprio non dovrebbe occuparsi di problemi tecnici. Manco un po'.
Davide
30/04/2012 08:00
Precedente Successivo
