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 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
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 Messer Franz posted 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
By Anonymous coward posted 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?
By Anonymous coward posted 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
By Thomas posted 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
By Guido posted 05/12/2011 09:56
potresti far diventare il server di test di produzione e quello di produzione di test...
By argaar posted 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
By melanippe posted 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
By Anonymous coward posted 05/12/2011 11:51
Io!.. io!..
By Anonymous coward posted 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?
By Anonymous coward posted 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 By Anonymous coward posted 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
By ITcoward posted 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
By Anonymous coward posted 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
By Fame posted 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...
-- --
By Anonymous coward posted 07/12/2011 22:45
Impari? Imparasse!
-- Anonymous coward
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.