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
Tempo addietro, uno dei nostri clienti (CL per gli amici), ebbe l'idea di mettere in piedi una specie di "web service" per raccattare certe informazioni da vari sensori tramite una rete radiocellulare per visualizzare il tutto su una specie di "mappa interattiva". La loro idea era di vendere il servizio a diversi enti e societa' e, una volta messa in piedi la cosa, semplicemente sedersi e guardare i soldi arrivare a carriolate.
Ovviamente tra il dire ed il fare c'e' di mezzo "e il".
Prima di tutto si resero conto che per poter raccattare le informazioni in modo continuo un solo server non e' sufficiente, ce ne vogliono due in un cluster in modo da avere una ragionevola continuita' del servizio.
Poi occorre mettere in piedi il sistema vero e proprio. Dopo aver lungamente lamentato dei costi relativi all'hosting, CL ha deciso di sviluppare il tutto in .NET con un backend di SQL Server. Ed allo scopo di ridurre i costi hanno prontamente deciso di utilizzare la versione "free" e prontamente il db si incatasta dopo aver raggiunto e superato i 20 Gb di dimensione.
La ditta incaricata di scrivere tutto l'accrocchione (da ora in poi $massadirimbamba) fa' apparire $brancodipaguri come un mostro di efficienza e di intelligenza.
Una delle prime attivita' che questi portano a termine e' lo scrivere un "servizio" che raccoglie le informazioni inviate dai vari sensori e schiaffarle nel database. La descrizione del servizio in questione rivela la mastodontica difficolta' dell'impresa: il servizio deve "ascoltare" su una specifica porta, raccogliere i messaggi inviati dai vari sensori come una sequenza di caratteri, identificare il sensore in funzione di un "identificativo" facente parte di tale sequenza, dividere il resto in una serie fissa di valori e memorizzare il tutto nel db con un 'timestamp'.
Una applicazione con un tale livello di complessita' che io avrei scritto in perl in dieci minuti probabilmente, loro ci hanno messo due mesi e mezzo e .NET.
Il 'servizio' viene consegnato come una caterva di .dll piu' una doppia caterva di file di configurazione (tutti rigorosamente .xml), richiede l'installazione di un server ftp (?), deve essere eseguito con una utenza "guru" (nella documentazione c'era scritto cosi') e la sua installazione richiede un minimo di 10 riavvi... e poi si scopre che parte delle foxxute DLL vanno in conflitto con altre DLL gia' esistenti e non funziona una mazza.
Dopo numerose bestemmie e ravanamenti riusciamo finalmente a far
funzionare l'accrocchione e scopriamo che il foxxuto coso si ciuccia via
l'80% della memoria della macchina ed ha la tendenza di raggiungere il
100% di uso del processore con sorprendente frequenza. Sorprendente e'
anche il fatto che questo capiti sempre tra le 2 e le tre del mattino,
con tutta la gioia che il povero pirla dotato di
guinzagliocellofono aziendale puo' provare per la cosa.
Ovviamente, il fatto che quella parte del sistema utilizzi uno sproposito di memoria e tempo di processore non fa' presagire nulla di buono riguardo alla web-applicascion stessa che dovrebbe usare tale servizio. Ed infatti, non appena questa viene installata, l'intero sistema diventa di una lentezza da far sembrare una lumaca un fulmine di guerra.
Aggiungiamo anche che il foxxuto servizio adesso tende ad incatastarsi molto piu' spesso e che quando questo succede in genere si incatasta anche la webapplicascion e l'unica e' un bel calcio nel XXXX ad IIS per far ripartire la cosa (dato che non possiamo prendere a calci i programmatroti).
Tutto questo fino ad una bel (si fa per dire dato che piove a dirotto) venerdi', quando la $massadirimbamba decide di fare un qualche aggiornamento che richiede una query da 45 minuti sul database (durante la quale l'intero accrocchio deve essere spento ovviamente) ed un bell'aggiornamento al sito ed al famoso "servizio", con nuove DLL. Io gia' sento puzza di cataclisma.
Ovviamente, il mio suggerimento di evitare un nuovo rilascio sul sistema di produzione al venerdi' e limitarsi ad un rilascio sul sistema di test (aka: l'altro server che e' momentaneamente non usato) in modo da verificare che tutto funzichi e poi eventualmente rilasciare il tutto lunedi' non viene accolto molto bene. Il rilascio viene percio' schedulato per le 7 di sera (!).
Io metto bene in chiaro che io faccio l'aggiornamento ma poi me ne lavo le mani fino a lunedi' e se il coso si incanta sono cavoli loro.
Ovviamente il coso si incanta e rimane 'morto' fino a lunedi' mattina, quando trovo 289 mail ad aspettarmi. La diagnosi: la nuova versione del 'coso' si ciuccia via tutta la ram e poi va' in coma. Ripristino le versioni precedenti di sito e 'coso', spedisco la diagnosi e tutte le informazioni a CL ed alla $massa e poi rimango in attesa della tempesta che gia' so si scatenera'.
Cio' che mi ha fatto ridere dell'intera vicenda e' stata la risposta della $massa al "problema memoria", la loro mail piu' o meno diceva:
"il servizio in questo caso non e' stato la causa del problema, in questo caso il servizio e' stato solo una vittima della mancanza di memoria".
Eccerto, lui e' stato la "vittima" della mancanza di memoria, il fatto che sia lui che si ciuccia via tutta la memoria ne fa' anche il carnefice, dobbiamo parlare di suicidio? Sgrunt.
Davide
16/05/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 Luca Bertoncello posted 16/05/2011 08:28
Solo che poi io ho spedito tutti a quel paese e ho rifatto completamente il tutto in maniera funzionante. Senza .NET. E senza usare piu' di qualche KB di memoria... -- Luca Bertoncello
By Anonymous coward posted 16/05/2011 08:32
"che io avrei scritto in perl in dieci minuti probabilmente, loro ci hanno messo due mesi e mezzo e .NET."
Non ti si addicono queste considerazioni da sempliciotto. E' evidente che il problema è la persona che scrive il codice, e non lo strumento che stava usando (come lasci invece tu intendere)
-- Anonymous coward
@ Anonymous coward By ringo posted 16/05/2011 17:39
"che io avrei scritto in perl in dieci minuti probabilmente, loro ci hanno messo due mesi e mezzo e .NET."
Non ti si addicono queste considerazioni da sempliciotto. E' evidente che il problema è la persona che scrive il codice, e non lo strumento che stava usando (come lasci invece tu intendere)
Mi saprai spiegare come mai quelle persone lì che scrivono quel codice in quel modo, usano quasi sempre .net e quasi mai perl?
-- ringo
By Kim Allamandola posted 16/05/2011 08:59
Se han sviluppato tutto in ambiente Microsoft o con tecnologie Microsoft è
naturale che i tempi siano n volte superiori a soluzioni *nix...
Ma una curiosità 20Gb di dati testuali!? Quanti poll per unità di tempo, per
quanto tempo sono conservati, quanto son grossi i dati e quanti cavolo di
sensori sono? Vogliono la face recognition di tutti i volti che passano il
tutto in base64?
Vabbé se qualcuno paga almeno da il suo contributo all'economia........
-- Kim Allamandola
@ Kim Allamandola By Davide Bianchi posted 16/05/2011 15:11
Se han sviluppato tutto in ambiente Microsoft o con tecnologie Microsoft è
naturale che i tempi siano n volte superiori a soluzioni *nix...
Ma una curiosità 20Gb di dati testuali!?
20 Gb di database (almeno, erano 20... adesso sono molti di piu') Cosa ci sia in quel database non lo so e non lo voglio sapere.
-- Davide Bianchi
By cecchino posted 16/05/2011 09:14
Ovviamente tra il dire ed il fare c'e' di mezzo "e il".
Nonostante sia ormai abusata, questa mi fa sempre cappottare dalle risate . E di lunedì mattina, ci vuole!
Ciao
C.
--
cecchino
By Anonimo cordarto posted 16/05/2011 09:45
«tra il dire ed il fare c'e' di mezzo "e il".» (cit.)
Cmq il problema dei 2 mesi e mezzo non dipende da .NET, ma dai rimbamba...Per un servizio di quella difficolta' l'unico linguaggio che richiede piu' di 10 minuti e' il Klingon.
-- Anonimo cordarto
By Programmatroto posted 16/05/2011 09:52
A me sembra che abbiano un problema di ascolto in polling... Ho avuto un problema simile qualche settimana fa con un thread di una mia applicazione che faceva richieste continue sulla porta e il processore mi schizzava al 90% e più.. Ahò, era la mia prima volta con TCP/IP di windows Però mi ero messo a cercare l'errore e dopo un paio d'ore l'avevo trovato, perlomeno...
By Davide Inglima posted 16/05/2011 10:07
...mi sembra davvero strano che esista ancora un mercato del software custom...
-- http://limacat.blogspot.com
By Anonymous coward posted 16/05/2011 10:13
> dobbiamo parlare di suicidio?
In effetti, se fossi un servizio/applicazione scritto in quella maniera, penserei seriamente anche io al suicidio...
-- Anonymous coward
By Anonymous coward posted 16/05/2011 10:20
"Ovviamente tra il dire ed il fare c'e' di mezzo "e il"
e aggiungerei: "Una rondella non fa primavera" .... (by Elio e le storie tese).
Lorenzo
-- Anonymous coward
By Anonymous coward posted 16/05/2011 10:30
Ciao Davide,
ma in che ambiente operativo è stato installato tutto l'ambaradam?
E quanta RAM ha il server?
Te lo chiedo perchè un mio cliente sosteneva che per un server, che gestisce 100 utenti con tutti i servizi del caso, erano sufficienti 4GB di RAM. Io ne consigliavo 16 come minimo..
Pensavo di andare a lavorare nei campi, credo avrei meno pensieri..
Ciao
Lorenzo
-- Anonymous coward
@ Anonymous coward By Davide Bianchi posted 16/05/2011 15:15
ma in che ambiente operativo è stato installato tutto l'ambaradam?
E quanta RAM ha il server?
quello che hanno richiesto e quanta ne hanno richiesta/sono disposti a pagare. Se loro chiedono un server con Windows X e Ram Y, noi forniamo un server cosi' fatto. Se poi scoprono che per far funzionare l'applicazione c'e' bisogno di Windows X+10 e Ram 20 * Y non dovrebbero essere problemi miei...
-- Davide Bianchi
By Kurgan posted 16/05/2011 10:39
Certo, non e` colpa loro se nel tuo server non ci sono 8 bazillotera di ram.
Ma quando una storia inizia con .NET, so gia` che va a finire male per forza.
-- Il massimo danno con il minimo sforzo
By Carlo posted 16/05/2011 11:17
Qua ci sono almeno due vittime: la programmazione e .net... Se il servizio o quel che è deve fare solo quel che hai descritto in mezza giornata lo scrivi, lo testi e lo installi, senza bisogno di 8 tonnellate di dll!
E.... a che caspita serve un server ftp per un web service?
Se riesci a darmi una risposta logica mi dedico all'agricoltura...
-- --Carlo
@ Carlo By BluNotte posted 17/05/2011 01:18
Qua ci sono almeno due vittime: la programmazione e .net... Se il servizio o quel che è deve fare solo quel che hai descritto in mezza giornata lo scrivi, lo testi e lo installi, senza bisogno di 8 tonnellate di dll!
E.... a che caspita serve un server ftp per un web service?
Se riesci a darmi una risposta logica mi dedico all'agricoltura...
Carlo
Uhm... io la butto lì...
Hanno implementato il... coso... con un sottoprodotto di un'architettura pipe&filter (che qui chiameremo $pippe_e_filtrini), in cui ogni .dll è un filtro, ed è implementato come plug-in. Questi plugin saranno pensati per essere aggiunti, rimossi e modificati a runtime (in realtà non funziona, ma ci hanno provato). Il modo più facile per fare questo è semplicemente ricaricare da zero tutta la catena di dll a ogni richiesta (e qui ci aiuta Windows, che, almeno, non carica la dll una volta per ogni thread che la richiede).
Ovviamente, ogni .dll sarà completamente indipendente, e avrà le sue dipendenze (altre .dll) necessarie per funzionare.
Tutto questo viene caricato ex novo a ogni richiesta. Probabilmente Windows vorrebbe anche tenerle in cache, ma non ci riesce, perché tutta la ram è occupata da altra spazzatura.
Questo potrebbe spiegare le dll...
Per quanto riguarda il ftp, magari hanno associato ad ogni dll un account ftp sul server, e le varie dll comunicano tra loro passandosi dei file tramite ftp. Così si causa anche un comodo surplus di scritture sul disco.
--
BluNotte
By Riccardo Cagnasso posted 16/05/2011 12:16
Ti e' mai venuto il dubbio che per come lavorate voi non possiate fare altro che attirare idioti di questo rango? Voglio dire le mie webapp consumano le risorse che gli servono e non bruciano ram a caso e non si inchiodano ogni 10 minuti, questo sta a dire che quando devo mettere su una web application o pago un hosting/shell su webfaction o un dedicato se il cliente mira ad avere 120.000 contatti al giorno o 300gb di roba, pago una giornata al sistesta di fiducia che installa il sistema operativo, configura i servizi etc (si potrei farlo io, ma mi sembra giusto che ogniuno faccia il suo di mestiere), assieme configuriamo apache, python e io mi configuro la mia webapp e da li saluti e baci (gli aggiornamenti me li faccio da me).
Ora che voglio dire, che non ho bisogno di un servizio come il tuo di hosting, assistenza, guidato_per_manina e cazzi e mi viene il dubbio che chi ne ha bisogno...
-- Riccardo Cagnasso
By Anonymous coward posted 16/05/2011 12:41
"il servizio in questo caso non e' stato la causa del problema, in questo caso il servizio e' stato solo una vittima della mancanza di memoria".
Della serie: "piuttosto di ammettere che e' colpa mia, mi taglio i coglioni e poi li taglio a tutti coloro che proveranno ad addossarmi colpe che, si: sono mie, ma trovero' il modo di riversarle su altri."
-- Anonymous coward
By Anonimo lettore posted 16/05/2011 12:50
E' sempre bello leggere le storielle del Lunedi. Sembra di vivere in un mondo di utenti ed utonti in un rapporto di 1 a infinito.
Quello che non capisco è come mai le aziende sono piene di utonti e rimangono cmq a galla... farò approfonditi studi in tal senso e poi scoprirò che è il nero che tiene a galla tutti. Me lo ha appena detto la mia palla di cristallo.
-- Anonimo lettore
@ Anonimo lettore By Anonymous coward posted 16/05/2011 16:01
Quello che non capisco è come mai le aziende sono piene di utonti e rimangono cmq a galla...
Me lo chiedevo anche io e poi ho capito: poiche' sono TUTTE piene di cialtroni, esse sono TUTTE catorci allo stesso modo. In una mercato dove tutti sono allo stesso livello, (altissimo o bassissimo non importa) ecco che e' facile sopravvivere in quanto i tuoi avversari sono al tuo stesso livello, pr cui per i tuoi clienti non avrebbe senso cambiare.
Corollario "della mediocrita' diffusa".
Sul mercato non importa essere meglio degli avversari, l'importante e' non essere peggio.
Corollario "del miglioramento inutile"
Se per avere un cliente in piu' del tuo avversario devi sbatterti il doppio del tuo avversario, lasciagli pure il cliente.
-- Anonymous coward
By Andrea Ballarati posted 16/05/2011 13:19
"il servizio in questo caso non e' stato la causa del problema, in questo caso il servizio e' stato solo una vittima della mancanza di memoria".
Come dire: "è morto per mancanza di fiato"
Comunque un'apllicazione come quella anche con .NET si scrive in mezz'ora, ma sai come si dice dalle mie parti: "fare e sfare è sempre lavorare"
By Alberto posted 16/05/2011 13:59
Mah, nella mia azienda, pur essendo un po' scalcagnati nelle IT operations, abbiamo una regola aurea, non derogabile "non si fanno rilasci al venerdì".
Per il resto, non vedo che altra risposta potevi aspettarti da $massadirimbamba se non "throw more hardware to your software".
Nella mia azienda, qualche settimana fa si è impianto un DB a causa di un tablespace pieno. Risultato, un'applicativo $chemuovesoldisuinternet è rimasto fermo per 12 ore con più di 500 clienti bloccati ed incazz**** (per non parlare dei nostri manager).
Dopo aver chiesto lumi a $softwarehousechemalauguratementesiimprovvisaanchesysadmin, che da SLA deve mantenere quell'applicativo effettuando anche un controllo mensile dei tablespace., mi sento rispondere che all'ultimo controllo, 5 giorni prima, guarda caso era tutto ok (unica informazione presente nel loro rapporto mensile).
Gli faccio allora notare che era un po' strano che dopo 5 giorni un tablespace (non settato per autogrow) "miracolosamente" si riempisse. Mi rispondono allora che non tenevano di mese in mese la percentuale di saturazione del tablespace e che la avrebbero inclusa dal mese successivo "per trasparenza" (mepensa: che mene frega della trasparenza, siete pagati per mantenere il sistema up and running e se un tablespace si riempie avete già fallito).
Finita la pazienza, vado ad armarmi di LART e passo in audit tutti i controlli che avevano effettuato (nella mia azienda abbiamo un tool che "fotografa" ogni singola schermata di una sessione remota). Guarda caso, il tabelspace era già al 100% alla data del loro ultimo controllo, ma non avevano considerato la situazione critica perchè guardando la videata dell'enterprise manager avevano erroneamente interpretato l'informazione SEGMENT MANAGEMENT = AUTO come autogrow del database (da notare che il database era stato installato ed è amministrato da loro).
Taglio corto allla morale, visto che storie simili le avrete già vissute tutti: "non discutere mai con un idiota: la gente potrebbe non notare la differenza"
PS: Evitate pure qualsiasi discussione filosofica se i database è meglio gestirli con autogrow oppure meno, ciascun amministratore è libero di fare come crede a patto che riesca a svolgere in modo efficente ed efficace il compito che gli è affidato (ed aggiungo: evitando quindi a me, che faccio il project manager, di dovere entrare nei dettagli ed occuparmi dei $sarcassi per cui sei invece pagato tu).
-- Alberto
@ Alberto By Adriano posted 16/05/2011 16:41
> Taglio corto allla morale, visto che storie simili le avrete già vissute tutti: "non discutere mai con un idiota: la gente potrebbe non notare la differenza"
No, la morale era "Non discutere mai con un idiota, prima ti abbassa al suo livello, poi ti batte con l'esperienza di anni".
-- Adriano
@ Alberto By Anonymous coward posted 16/05/2011 20:44
E il bello che puoi anche configurare Enterprise Manager per segnalarti quando è "quasi pieno" e "ormai è pieno tranne un pelino".... probabilmente per loro "threshold" significa "tre soldi"...
-- Anonymous coward
@ Alberto By Anonymous coward posted 17/05/2011 11:09
@ Alberto
Una domanda, come si chiama il software per "fotografare" le sessioni remote?
Grazie.
-- Anonymous coward
@ Anonymous coward By Alberto posted 19/05/2011 07:44
> Una domanda, come si chiama il software per "fotografare" le sessioni remote?
Noi utilizziamo questo prodotto: http://www.observeit-sys.com/
-- Alberto
By ARM_ posted 16/05/2011 14:06
> La ditta incaricata di scrivere tutto l'accrocchione (da ora in poi $massadirimbamba) fa' apparire $brancodipaguri come un mostro di efficienza e di intelligenza.
Ed ecco che anche il mito di $brancodipaguri crolla miseramente sotto i colpi della realtà.
-- ARM_
By Massy posted 16/05/2011 14:13
> Ovviamente tra il dire ed il fare c'e' di mezzo "e il".
Ehm, forse c'è "ed il"
-- Massy
@ Massy By Andrea Ballarati posted 17/05/2011 18:03
>> Ovviamente tra il dire ed il fare c'e' di mezzo "e il".
> Ehm, forse c'è "ed il"
"ed" al posto di "e" si usa se la parola segente inizia per "e", l'uso davanti ad altre vocali è improprio. Es. "Il vecchio e il mare" o in Leopardi (Zibaldone) "[..] altro il doloroso altro anche il brutto e il vile" mentre Manzoni giustamente scrive (Promessi sposi) "Addio, monti sorgenti dall'acque, ed elevati al cielo [..]"
-- Andrea Ballarati
By Alberto posted 16/05/2011 14:23
E dato che un disegno vale più di 1000 parole:
http://marketingroi.robinsonmaites.com/wp-content/uploads/2010/06/cutting-off-branch.jpg
Buona settimana
-- Alberto
By Anonymous coward posted 16/05/2011 19:44
Secondo me l'hanno scritto in Brainfuck xD
-- Anonymous coward
By Flavio posted 16/05/2011 20:13
> Eccerto, lui e' stato la "vittima" della mancanza di memoria, il fatto che sia lui che si ciuccia via tutta la memoria ne fa' anche il carnefice, dobbiamo parlare di suicidio? Sgrunt.
Visto che frequenti gli ambienti del peak oil, dovresti essere familiare con la storiella del lievito
By Nik posted 16/05/2011 20:20
> La ditta incaricata di scrivere tutto l'accrocchione (da ora in poi $massadirimbamba) fa' apparire $brancodipaguri come un mostro di efficienza e di intelligenza.
Letta questa, ho avuto davvero paura...
Però c'è una domanda che mi assilla: cos'è (o almeno cosa è nella testa dei rimbamba) l'utenza "guru"???
-- Chronicles of a Broken Heart
By Anonymous coward posted 17/05/2011 14:40
Bella l'utenza guru... immagino sia quella usata per le "guru meditation" dato l'articolo.
@ Anonymous coward By Alberto posted 18/05/2011 09:02
> Bella l'utenza guru... immagino sia quella usata per le "guru meditation" dato l'articolo.
che, data la qualità enunciata del software, immagino sia il processo eseguito più frequentemente su quel PC
-- Alberto
By Keeper posted 18/05/2011 09:36
C'è uno schema provato che viene utilizzato da questa gente:
http://www.n2h.it/blog/wp-content/uploads/2007/02/soluzione.png
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.