Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

Migliora il mio disco

Hardware contro Software. E' la solita vecchia storia quando ci sono problemi di prestazioni, o in effetti ogni tipo di problema, che affliggono ogni tipo di sistema informatico complesso.

Il punto e' che quando un sistema va oltre un certo livello di complessita', nessuno capisce piu' esattamente cosa fa cosa e quale parte e' responsabile per quella o questa funzione. Tutti quanti pero' capiscono che se c'e' un problema e' sicuramente nella parte che qualcun altro ha in carico. Deve esserlo. La MIA parte e' assolutamente immacolata e priva di errori! Yup! Niente errori qui.

Ed il guaio e' che per la maggioranza hanno anche ragione.

Il "problema" non e' che la LORO parte ha degli errori, ma piu' precisamente che il modo in cui la loro parte "parla" (o si rifiuta di farlo) con il resto del sistema e'... non molto corretto. E piu' complesso e' il sistema, piu' le varie parti devono seguire un ben preciso protocollo per "parlare" tra di loro in modo che il tutto funzioni correttamente e quando una o piu' parti non si "incastrano" e' un gran casino.

Quindi che succede quando un sistema di questo tipo comincia a manifestare "problemi"? Che tutti quanti entrano in panico ovviamente.

Ed in generale, che tutti cominciano a puntare il dito verso l'hardware, perche' se non altro e' una parte facile da vedere e da gestire.

Ed adesso possiamo parlere di $masterofdisaster, una piccola societa' che si era messa a mettere insieme una specie di tool di data-analysis di qualche tipo.

L'idea era di collezionare informazioni tra varie applicazioni usando degli "analizzatori" e quindi processre il tutto in una interfaccia sciccosa. E vendere il servizio per mucho dinero ovviamente. In sostanza, stavano cercando di re-inventare NewRelic o qualche cosa di simile.

Per fare cio', andarono pazzi con lo "stacking", sostanzialmente incollarono insieme cose di ogni tipo mediante la libera applicazione di Mule e codice NodeJS.

E poi.. disastro.

Dopo circa un mese di operazioni, tutto quanto comincio' a diventare molto ma molto lento... ed anche abbastanza "imprevedibile". Cose che funzionavano e poi smettevano di funzionare senza nessuna ragione apparente.

Ovviamente il primo grido fu "prestazioni". Si perche' meglio fornire risultati sbagliati di corsa che risultati corretti ma lentamente, esattamente come e' meglio prendere decisioni sbagliate ma velocemente che pensarci su e prendere decisioni giuste, no?

Ondepercuicio, un lungo meeting fu organizzato tra noi (hosting) e qualcuno della societa'. Ovviaemnte loro stavano cercando un modo rapido e veloce di aumentare le prestazioni senza "impattare la struttura generale". Aka: noi non vogliamo cambiare il nostro software noi vogliamo cambiare il vostro hardware. Che e' ok per noi, voglio dire, tu paghi di piu' ed alla fine e' il tuo fottuto problema quindi... chissenefotte, ma se l'hardware non e' il problema, e quasi mai lo e', puoi cambiarlo quante volte vuoi e non fara' un cazzo di differenza.

Noi, ok, in effetti IO, cercammo di spiegare che quando hai una pletora di cosi che cercano di parlare l'uno con l'altro e' molto importante tenere sotto controllo il ritardo con il quale queste conversazioni sono effettuate per poter puntare il dito verso il vero problema. Quindi gli sviluppatori del coso dovrebbero essere molto attenti nel

1. aggiungere 'punti di debug' per misurare quanto tempo richiede ogni singola operazione.
2. ottimizzare ogni processo per quanto possibile
3. se salta fuori che uno dei processi non e' tanto buono dal punto di vista delle performance, essere pronti a rivederlo o sostituirlo

e, per ultimo ma non da ultimo

4. non aggiungere merda che tu non capisci solo perche' e' semplice da aggiungere.

Ovviamente potete immaginarvi quale fu la ricezione di queste semplici e credo logiche considerazioni.

Per procedere alla "velocizzazione" del processo una decisione fu presa di raddoppiare l'hardware. Quindi il doppio dei servers, con il doppio della ram, il doppio dei processori... il doppio di tutto. Il che ovviamente risolse... niente. Il sistema passo' da lento ed attivo a lento e molto poco attivo. Ed a questo punto tutti quanti cominciarono a strillare l'uno con l'altro. E con noi ovviamente perche' e' piu' facile strillare contro qualcun altro che contro te stesso.

Come finisce la cosa? Be'... non finisce. Cambia. Cambia perche' la societa' decise che la "successiva iterazione" del software avrebbe dovuto essere testata in modo diverso. Ed adesso dobbiamo scendere nei dettagli di come il software era sviluppato.

Non in un ambiente di test. Almeno non un ambiente di test "regolare". Sapete, quella specie di "copia" dell'ambiente di produzione dove voi provate le vostre cose. No. Quello sarebbe stato troppo facile. No, loro avevano deciso di andare con il modo "agile". Il che significa che ogni sviluppatore aveva una smazzata di macchine virtuali su cui testare il software.

A questo punto il problema era come ognuna di queste macchine virtuali erano "assemblate". Si perche' mentre l'ambiente di produzione era CentOS, niente di meglio che fare l'ambiente di test su... qualche cosa di completamente diverso. Qualche cosa che non avenva ne' gli stessi package, ne' le stesse versioni del software di base ed ogni singolo file di configurazione era diverso ed in  un posto diverso. E quindi strillare che non si potevano confrontare gli ambienti.

E quando domandammo come mai avevano deciso di usare quella roba per mettere insieme le loro vm invece di usare quello che usavamo in produzione, la risposta fu che avevano scelto di usare una cosa che fosse 'ottimizzata' per basso consumo di memoria e di disco. E stiamo parlando di un paio di gigabytes su macchine con almeno 16 Gb di ram e centinaia di giga di disco.

Non devo dire che non riuscirono mai a risolvere il problema per davvero, giusto?

Davide
29/08/2018 11:32

Precedente

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

7 messaggi posta messaggio
Guido Di Guido - postato il 10/09/2018 09:41 - rispondi

L'immagine:

a) e' bellissima

b) rende troppo bene l'idea

;)

--
who uses Debian learns Debian but who uses Slackware learns Linux


Messer Franz@ Guido Di Messer Franz - postato il 11/09/2018 10:01 - rispondi

 

L'immagine:

a) e' bellissima

b) rende troppo bene l'idea

;)

Hai perfettamente ragione, DB è un genio a scegliere le immagini migliori, quella di terminator x il supporto tecnico è senza dubbio la migliore; quando l'ho vista sono partito a ridere e mi sono fermato solo minuti dopo, ed anche oggi (che l'ho vista decine di  volte) mi fa sorridere.

 

--
Messer Franz


Guido@ Messer Franz Di Guido - postato il 14/09/2018 06:56 - rispondi

quella di terminator x il supporto tecnico è senza dubbio la migliore; 

Purtroppo quella mi ricorda l'hosting pampers nostro - tutte le volte che ci parlo mi verrebbe voglia di mandargliene un paio (abbiamo un ticket aperto da piu' di un anno, apparentemente non riescono a configurare un jboss 10 con apache* davanti...)

*short story long - jb+apache+jsf in https non funziona tanto bene perche' a jb la connessione arriva in http e jsf se la gestisce come gli arriva da jboss per loro era colpa del nostro applicativo che redirigeva da https ad http solo che se non mi dicono che c'e' apache davanti non posso nemmeno rendermi conto del problema - per dire... Un anno per arrivare alla conclusione che LORO devono aprire un ticket al LORO primo livello

'nuff said

 

 

--
who uses Debian learns Debian but who uses Slackware learns Linux


Akart72 Di Akart72 - postato il 10/09/2018 09:45 - rispondi

Ultimamente sto metodo "agile" ha preso molto piede 

Una volta il ciclo era "raccolta specifiche" -> sviluppo -> test -> rilascio    (con l'idea che se il test non era ok non rilasciavi)

Ora "raccolta specifiche minimali" (tanto le cambierai man mano) -> sviluppo (fatto a cane) -> rilascio -> test -> madonne del cliente -> riparti a mettere immondizia nel codice

 

Se una pagina web ha un bug vabbe, ma per chi come me usa software per uso industriale non e' mica tanto bello 

--
Akart72


Guido Di Guido - postato il 10/09/2018 09:47 - rispondi

Mi hai fatto venire in mente una cosa: in $ENTE tengono i file su db (horresco referens) - TANTI.

Ho fatto notare la cosa, come forse sarebbe meglio metterli su disco a fronte di una gran rottura di balle a farlo, ma comunque penso che il guadagno sarebbe notevole e valevole di perderci tempo.

Risposta: Tu non ti preoccupare quando sara' il momento aumenteremo lo spazio del db

Devo dire altro?

--
who uses Debian learns Debian but who uses Slackware learns Linux


Zimpazum Di Zimpazum - postato il 10/09/2018 09:49 - rispondi

E fu così che si comprarono tutti i datacenter di Google e riuscirono a mandarli in palla... :D

--
Zimpazum


emi_ska Di emi_ska - postato il 10/09/2018 14:03 - rispondi

Ciao,

Anche noi sviluppiamo con un programma che gira sotto oracle, che si ciuccia tutte le risorse a disposizione, dopodiche' si pianta miserandamente sputando fuori una camionata di exception che riempirebbero il camion nella foto!!!

Buona settimana a tutti e grazie a te Davide, per la storia che mi allieta il lunedi'!!

--
emi_ska


7 messaggi posta messaggio

Precedente


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira