Ricerca in FOLBlog

[SdSM] Cosa puo’ andare male?

 Scritto da alle 15:27 del 30/05/2011  Aggiungi commenti
Mag 302011
 
closeQuesto articolo è stato pubblicato 6 anni 2 mesi 24 giorni giorni fa quindi alcuni contenuti o informazioni presenti in esso potrebbero non essere più validi. Questo sito non è responsabile per eventuali errori causati da questo problema.

Ritorniamo a parlare di $allupati, di cui avevo accennato in questa storia.

Allora, avevamo lasciato il branco a smazzarsi la loro server-farm composta da una dozzina di macchine per capire perche’ la foxxuta applicascione e’ cosi’ lenta prima di andare in produzione.

Fedeli al modo standard di pianificare le cose, l’intero ambaradan e’ andato in produzione prima che i problemi di cui sopra fossero corretti. Cosi’ ci ritroviamo alla prima settimana di attivita’. Settimana che e’ stata preceduta da un barrage pubblicitario inaudito per promuovere una qualche cosa che sta’ gente vorrebbe vendere.

Il risultato e’ che il primo giorno e’ tutto calmo sul fronte occidentale, il secondo giorno cominciamo a vedere che dalle 11.30 circa il numero di richieste comincia ad aumentare e la webapplicascion comincia ad andare in panico. Ogni tanto qualche cosa si incatasta ed io mi ritrovo con Tomcat a palla con 300 thread attivi in stato di attesa e niente che arriva. Risultato: si riavvia tomcat.

Avendo questi 8 (otto) applicascionserver il gioco consiste nell’avere su uno schermo un computo dei thread attivi sui vari servers e quando uno dei servers comincia ad aumentare (20… 23…. 28…. 31… 38…) significa che e’ andato in palla ed e’ il momento di fare un restart. Il che va’ avanti dalle 11.30 fino circa alle 14.00, poi la gente ritorna a lavorare (o far finta di) e tutto ritorna tranquillo fino al giorno dopo.

Solo che $allupati non gradisce di ricevere una fattura per 3 ore di lavoro extra ogni giorno, specialmente da quando io ho cominciato a chiamare tale attivita’ “retarded craplication pick-and-spin-up” (cioe’ dal primo giorno). Quindi oggi, verso le 10.30, ci becchiamo la telefonata dall’UL di turno del branco di mammalucchi che hanno scritto l’applicascion che fa’ domande varie.

IO – …e quindi penso che il problema non sia tanto in TomCat quanto nella connessione tra la vostra applicazione ed il backend che fornisce i dati.
UL – Ma il backend non lo abbiamo fatto noi.
IO – E mi sta bene. Ma tu mi hai chiesto che cosa ne penso, e questo e’ quello che ne penso.
UL – Mi viene in mente… avete provato a fare una pulizia della cache del database?
IO – La cache di che cosa?
UL – La cache del database.

Pausa, mentre io e DB ci guardiamo pensando “di che ca$$o sta’ parlando questo qui’?”.

IO – No, noi manco sapevamo che ci fosse una roba del genere… dove sarebbe sta’ cosa, come si fa’ ed a che serve?

E qui’ UL si e’ lanciato in una spiegazione irta di buzzwords in cui specificava che nel database esistono una serie di tabelle che contengono le query che sono state eseguite precedentemente allo scopo di stilare delle classifiche e statistiche e tali tabelle vengono elaborate ogni ora e sarebbe opportuno ripulirle di tanto in tanto in modo da mantenerle il piu’ possibile pulite.

Ora, sorvoliamo sulla logica della cosa e sul fatto che se non ce lo dici sara’ dura che ce lo sogniamo di notte, ma la faccenda mi ha fatto venire un dubbio.

IO – ‘momento… ma di database ce ne sono due e dovrebbero essere sincronizzati, quindi a che vi serve calcolare ste’ statistiche?
UL – Ah no, i databases non sono sincronizzati. Ne usiamo solo uno.
IO – ??? Come sarebbe a dire ne usate solo uno? Tutto sto’ popo’ di front-end con 8 server ed avete UN SOLO database?
UL – Bhe’, si’, perche’ altrimenti e’ un casino e… Ma che cosa puo’ andare male in ogni caso?
IO – Hu… che il database si incatasta e tutto smette di funzionare?
UL – Heee… Ma no, questo non succede. Comunquesia, io suggerisco di eseguire la pulizia delle statistiche.
IO – (guardando DB che sta’ eseguendo un perfetto face-palm) Ok, lo possiamo schedulare per stanotte?
UL – No, no. Facciamolo subito!
IO – (guardando l’orologio) Ma sono gia’ le 11. E fra mezz’ora comincia il momento di massimo carico. Forse e’ meglio evitarlo.
UL – Ma no, la procedura e’ rapida e dovrebbe risolvere il problema. Che cosa puo’ andare male?

Cosi’ dopo un rapido giro di mails, lanciamo sta’ cosa e rimaniamo a guardare mentre il db server comincia a macinare ed il load average comincia a salire fino ad assestarsi intorno ad un 49 e rimane li’.

E di concerto gli otto servers cominciano ad incatastarsi uno dopo l’altro quando le loro richieste non ricevono risposta.

Verso le 12, DB che e’ al telefono da una parte con $allupati e dall’altra parte con gli sviluppatori decide che e’ il caso di tirare giu’ tutti e 8 i servers, fare un bello shutdown del database e ripartire da capo.

Io do’ lo shutdown al database e rimango ad aspettare mentre quello comincia il rollback di quella famosa procedura di pulizia, con il redo log che si riempie a ritmi allucinanti.

Dopo un quarto d’ora DB decide che forse e’ il caso di mettere una pagina di “lavori in corso” sul sito.

Finalmente, alle 13.45, il database riesce a spegnersi, noi riavviamo tutto in sequenza e le cose ritornano in vita. A quel punto abbiamo schedulato la procedura di pulizia per mezzanotte e vedremo come vanno le cose.

Ed adesso ho visto che stamani c’era pure una mail da parte di SL di $allupati che voleva avere una misura della frequenza dei riavvii dei servers durante il “round-up”. Be’, per oggi e’ facile, la frequenza e’ UNO.

Quindi dei DUE database servers in realta’ ne e’ usato solo uno. Per la serie: che cosa puo’ andare male?

Davide

legenda personaggi

Articoli simili:

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

 Lascia un commento

Puoi usare questi tag e attributi HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(richiesto)

(richiesto)

Pinterest
EmailEmail
PrintPrint
%d blogger hanno fatto clic su Mi Piace per questo: