Tales from the Machine Room |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
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
07/02/2011 08:00
Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
By Angkarn posted 07/02/2011 08:46
Il database in uso è per caso $OracoloDiDelfi?
Perché non so che diamine intendano dire i tizi con "Pulizia della cache", ma le statistiche per l'ottimizzatore delle query ormai sono gestiti in autonomia dal motore centrale.
-- Angkarn
@ Angkarn By Anonymous coward posted 07/02/2011 20:38
Non so di che cache stiano parlando... ma in genere la "cache" è lì per aumentare le prestazioni del database, a meno che l'applicazione non sia codata con la parte appoggiata alla sedia (tipo tablescan che non trovano nulla già in cache e la riempono di dati inutili per il prossimo tablescan...) svuotarla serve solo a peggiorare le prestazioni.
Se poi il database è Oracle le statistiche non sono una "cache" (e non memorizzano le query eseguite...) ma delle vere e proprie statistiche del contenuto delle tabelle (numero di record, distribuzione dei dati, ecc. ecc.) che l'ottimizzatore cost-based usa per scegliere il plan che crede ottimale. Cancellatele e utilizzerà una serie di assunti base che tipicamente sono completamente sballati per una data tabella e genererà un plan "sbagliato". Casomai di notte vanno aggiornate le statistiche, non cancellate!
Oracle ha una "cache" delle query, è lo shared pool, e tipicamente se le query non utilizzano variabili di bind alla fine riempono l'area con statement che non verranno mai riusati peggiorando le prestazioni, si può fare un flush del pool ma dopo un po' il problema ritorna (vedi sopra, applicazioni codate con il punto di appoggio sviluppatore-sedia).
Quanto al database in stdby può anche essere l'unica cosa sensata.... se è Oracle il cluster si paga a parte (e costa). Bisogna vedere com'è configurato il failover, però.
-- Anonymous coward
By Messer franz posted 07/02/2011 08:59
due opinioni:
1)di due database ne usano uno?beh , secondo me anche di tutti i loro neuroni ne usano uno*
2)e fare un riavvio delle loro teste(LART!LART!LART!)?
*no a testa , in tutta l'azienda....
-- Messer franz
By Eladamri posted 07/02/2011 08:59
Wow sembra che sei tornato da $noisalviamoilmondo hahaha
-- Eladamri
By Luca BG posted 07/02/2011 09:26
> "Cosa puo' andare male?"
Tutto. Ma Murphy non ha insegnato proprio niente, a certa gente?
-- Luca BG
By go.17 posted 07/02/2011 10:52
L'umanità intera può andare male.
Per aggiungere una rottura di coglioni alla tua giornata: è battage pubblicitario, non barrage.
Per rendere l'idea: nel battage ti battono le balle con una paletta con la frequenza di 1Hz, nel barrage (che sarebbe più auspicabile) ti sbarrano la strada alla pubblicità.
E visto che è la prima volta che scrivo: grazie per i lunedì di sollazzo che ci regali ogni settimana.
-- go.17
By il codardo senza nome posted 07/02/2011 12:59
..aspettando il kaboom.... perchè succederà prima o poi
By Thomas posted 07/02/2011 19:20
Mi sa tanto che la procedura di "pulizia cache" schedulata per mezzanotte si incarterà, e il mattino seguente ci saranno un sacco di CL e UL urlanti a correre per l'ufficio in preda al panico "nonfunzionapiuniente"...
-- Thomas
By Anonymous coward posted 08/02/2011 01:00
LOL
In tutto questo, l'UL di turno avrà pensato pure "ma guarda questi.. si spacciano per esperti e non sanno nemmeno cos'è la cache del database"....
Peraltro, mi sfugge una cosa: loro hanno PAGATO, se ho capito bene, 8 server di produzione, 2 load balancers, 4 server LAMP per "cacate varie" e, soprattutto, due database server... ... Il che mi porta a pensare: "chi ha pagato per il doppio database server lo sa che uno dei due passa le giornate ad abbronzarsi?" o forse il server in questione è stato fruttuosamente utilizzato per qualcos'altro?
-- Anonymous coward
@ Anonymous coward By z f k posted 08/02/2011 10:00
Qualcuno potrebbe anche sostituire il secondo server con uno scatolone travestito da server a colpi di pennarello e usarlo per scopi piu' degni che non scaldare la stanza.
CYA
-- z f k
@ Anonymous coward By Marco Colombo posted 08/02/2011 13:43
>"chi ha pagato per il doppio database server lo sa che uno dei due passa le giornate ad abbronzarsi?" o forse il server in questione è stato fruttuosamente utilizzato per qualcos'altro?
Ti posso dire per esperienza che a chi paga interessa solo che funzioni. Quello che questi super manager strapagati non riescono a ficcarsi in testa è che "funziona" significa "funziona, per adesso". Non è che pensino di essere immuni da Murphy, è che non sanno manco chi è...
Del resto c'è da capirli:
1) se (o quando) qualcosa succede, sono cazzi altrui, non loro: di sicuro un restore dal backup alle 23:30 del 31 dicembre non lo fanno loro.
2) loro i soldi li prendono sempre, pure se l'azienda fallisce, ossia se sbagliano in ciò di cui sono - sedicenti - direttamente "responsabili"; figurati come li tange se va storto qualcosa che possono attribuire a un errore degli altri...
-- .TM.
@ Anonymous coward By Anonymous coward posted 08/02/2011 20:11
Mai sentito parlare di hot-standby? Quella potrebbe anche essere l'unica cosa sensata che hanno fatto. Dipende anche da che db stanno usando e quali sono le opzioni. Ad esempio Oracle offre sia RAC (soluzione cluster) che Dataguard (soluzione di standby). Sono complementari, non mutualmente esclusive.
-- Anonymous coward
By Domenico posted 11/02/2011 13:56
Ma scusa 'sta cache dove stava?
se parli di redo log ipotizzio che sia Oracle e ipotizzio che sia in tabelle, ma a questo punto non si poteva usare una truncate?
-- Domenico
This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.
This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.
This site isn't optimized for vision with any specific browser, nor
it requires special fonts or resolution.
You're free to see it as you wish.