Storie dalla Sala Macchine |
Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register
Ritorniamo a parlare di quel branco di programmatroti di cui avevo parlato in questa storia.
Come detto precedentemente il branco di mammalucchi sta passando da un sistema pesantemente basato su Windows ad uno pesantemente basato su postgre. Il che non e' un male. Cio' che e' male e' che questi insistono a fare sviluppo e testing su un server che apparentemente non mostra mai nessun problema mentre quando l'applicazione viene portata in produzione si incrocchia piu' si che no.
Io ho gia' fatto notare che gli ambienti di test e di produzione dovrebbero essere il piu' possibile identici, altrimenti che "test" e'? Ma pare che tale concetto passi del tutto inosservato al programmatroto di turno.
Comunque sia, un paio di settimane fa c'e' stato l'ennesimo rilascio di una manica di roba in produzione e adesso pare che il database sia di una lentezza allucinante. Dato che il database non e' cambiato quello che ho pensato io e' che forse forse forse e' il caso di fare un po' di ottimizzazioni alle query che sono utilizzate.
Cue una richiesta del CL di turno di "abilitare il profiling" del database. Hemmm... non c'e' nessun profiling. Si puo' abilitare il logging del database e poi analizzare i files di log per vedere cosa si puo' ottimizzare ma la cosa migliore sarebbe che il programmatroto impari a scrivere le sue query ed utilizzare il database come si comanda e non alla ca$$o come e' fatto attualmente probabilmente.
Percui oggi mi becco la seguente conversazione con il CL di turno.
CL - ...e quindi vogliamo attivare il logging sul database di produzione
in modo da avere le informazioni necessarie per il profiling.
IO - Ma siamo sicuri di voler attivare il logging sul databsae di
produzione? Quel sistema e' gia' lento adesso, se attiviamo anche
il logging mi sa che le cose peggiorano di sicuro.
CL - Che impatto puo' avere sulle performance?
IO - E come faccio a saperlo? Un impatto ce lo avra' di sicuro, solo
per scrivere i dati nel file di log, ma quanto sia questo impatto e' una
cosa su cui non posso pronunciarmi. Non sono io che ho fatto l'applicazione,
non ho idea di come il database sia usato.
CL - Ma non siete voi i sysadmin?
IO - Si ma non siamo quelli che hanno scritto l'applicazione. Sono loro che
sanno come il database viene usato e come e se le query possono essere
ottimizzate. Io sono quasi sicuro che possano essere ottimizzate ma quali
e come non e' affar mio dirlo.
CL - Vabbe', comunque sia attiviamo il loggin. Si puo' fare oggi alle 12?
IO - ...certo che si puo' fare, ma io insisto che non bisognerebbe
farlo, non sul database di produzione, bisognerebbe fare questi lavori sul
database di TEST e poi, eventualmente, riportare le cose in produzione.
C'e' un sistema di test, usiamolo.
CL - Ma il mio programmatroto mi assicura che l'impatto non dovrebbe
essere eccessivo e yada yada yada...
E va bene. Do' un'occhiata al file di configurazione di postgres (standard come da distribuzione) abilito il logging delle query in modo da avere qualche informazione, poi alle 12 fermo tutte le millemila applicazioni, cambio il file di configurazione (facendomi una copia di quello originale), riavvio, faccio ripartire le applicazioni.
Dieci minuti dopo guardo e mi spavento: il file e' cresciuto di 8 Gb.
Altri dieci minuti dopo mi ri-spavento quando mi rendo conto che le varie applicazioni che scrivono su questo coso sono passate da "lentissimo" ad "abominevolmente lento". Ed infatti altri 5 minuti dopo mi arriva la richiesta del CL di turno di "disattivare il profiling".
Ok, rimetti il file di configurazione come era prima, riavvia eccetera eccetera.
Quando dico "abbiamo un sistema di test: usiamolo", perche' non mi danno mai retta? E adesso voglio vedere chi e' che se lo analizza questa barcata di roba (15 Gb di log). Qualche cosa mi dice che quel qualcuno saro' io... e qualche cosa mi dice che le mie raccomandazioni sul come fare o non fare le query verranno semplicemente ignorate. Chi e' che scommette?
Davide
05/12/2011 08:00
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.
Di Messer Franz postato il 05/12/2011 08:16
>Chi e' che scommette?
Io!Io!
Ma scommetto che te lo chiederanno , lo analizzerai , ti accorgerai subito degli errori nel programma , li consiglierai di come mettere a posto le cose (oh anima candida che non ha ancora capito che bisogna solo dare una scorsa al file di log e poi sparare computerese incomprensibile a raffica "ma il vostro programmatore saprà cosa intendo,no?") e loro se ne strafregheranno incasinando tutto ancora di più.
-- Messer Franz
Di Anonymous coward postato il 05/12/2011 08:53
Ideona: proponi lo spegnimento del server di test: non e' mai usato, consuma corrente, spazio, costi di amministrazione etc. Spegnerlo e' un bel risparmio, no?
-- Anonymous coward
Di Anonymous coward postato il 05/12/2011 09:54
ovviamente seguiranno i tuoi consigli... se fossimo in un mondo dove gli utonti non esistessero e la gente sapesse fare il proprio lavoro...
-- Anonymous coward
Di Thomas postato il 05/12/2011 09:54
Un giga di log al MINUTO? I casi sono due, o il sistema di logging registra anche la più piccola fesseria, oppure Il database ritorna una quantità apocalittica di errori.
...perché qualcosa mi dice che l'ipotesi giusta è la seconda?
-- Thomas
Di Guido postato il 05/12/2011 09:56
potresti far diventare il server di test di produzione e quello di produzione di test...
-- Guido
Di argaar postato il 05/12/2011 10:09
perché dovresti analizzarlo te? nel senso che se come ditta fate anche questo tipo di supporto (pagato a parte) allora si, altrimenti non c'entra nulla col tuo lavoro...è un problema loro!
-- argaar
Di melanippe postato il 05/12/2011 10:59
Mai scommettere quando sai di perdere.
Per quanto riguarda il mettere in produzione un sistema non sufficientemente testato, in Italia hanno cominciato ad utilizzare il cosiddetto processo civile telematico che, sulla carta, è una cosa fantastica.
Peccato che da quando è divenuto obbligatorio in alcuni tribunali, consultare quello invece di andare in Cancelleria, hanno già bloccato il sistema in diverse occasioni per più giorni, per fare degli aggiornamenti.
E pensarci prima no?
-- melanippe
Di Anonymous coward postato il 05/12/2011 11:51
Io!.. io!..
-- Anonymous coward
Di Anonymous coward postato il 05/12/2011 14:16
E adesso voglio vedere chi e' che se lo analizza questa barcata di roba (15 Gb di log). Qualche cosa mi dice che quel qualcuno saro' io...
Un altro lavoro per ScriptMan! Ta-dahhh!
Lo hai messo il costume sotto il vestito, stamane? Altrimenti devi ricorrere alla cabina telefonica per cambiarti in tutta fretta. E se c'e' la vecchina rompicoglioni con un sacchetto di monetine per poter raccontare in tutta calma alla sorella la sua ultima operazione di emorroidi? Mica puoi saccagnarla di bastonarte per avere la cabina, o si?
-- Anonymous coward
Di Anonymous coward postato il 05/12/2011 14:52
Poverini, non è che in Postgres possano fare molto... comunque ci sono dei log analyzer per pg... se sono furbi ne usano uno. Ma se fossero furbi userebbero un database migliore...
-- Anonymous coward
@ Anonymous coward Di Anonymous coward postato il 06/12/2011 08:45
E se fossero ancora più furbi cambierebbero mestiere ma sarebbero troppo furbi per essere dei CL
Poverini, non è che in Postgres possano fare molto... comunque ci sono dei log analyzer per pg... se sono furbi ne usano uno. Ma se fossero furbi userebbero un database migliore...
-- Anonymous coward
Di ITcoward postato il 06/12/2011 08:59
Il concetto di ambiente di produzione/staging/sviluppo è tanto semplice quanto sconosciuto.
Mi ricordo che i primi giorni di lavoro, appena uscito dall'Università, i colleghi mi parlarono di ambiente di produzione/staging/...e io rimasi stupito perchè non avevo idea di cosa fossero, mentre oggi sono termini banali e che considero basilari.
Un esempio del gap che esiste tra l'Università e il mondo vero.
-- ITcoward
Di Anonymous coward postato il 06/12/2011 09:24
(mi immagino la scena)
BD: bene, abbiamo questo file di log, come da vostra richiesta.
UL: file di log?
BD: si, quello che mi avevate detto di attivare.
UL: ah, si. allora?
BD: beh, non posso mandarvelo per posta, sono 15G. anche compresso e' comunque grosso.
UL: 15G!??!?! Ma come e' possibile?
BD: sono i livelli di log da voi richiesti, "LOG ALL" e il sistema logga tutto.
UL: e come facciamo?
BD: potete accedere al nostro server ftp per scaricare il file.
UL: server ftp?
BD" si, vi collegate e (spiegazione)
UL: non mi e' molto chiaro. Senta, facciamo cosi, me lo mandi per posta.
BD: come dicevo poc'anzi, il vostro server di posta mi rimbalza mail troppo grosse.
UL: no intendevo per posta cartacea, lo stampa e me lo manda per corriere espresso.
BD: click! (tono di portante telefonica uuuuuuuuuuuuuuuuuuuuuuuuuuu......)
-- Anonymous coward
Di Fame postato il 07/12/2011 12:14
secondo me basta analizzare le prime 100 righe e fornire un report su quelle, tanto quando gli dirai che la soluzione è cambiare programmatore acquisteranno altri 4 server e un load balancer...
-- --
Di Anonymous coward postato il 07/12/2011 22:45
Impari? Imparasse!
-- Anonymous coward
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".