Prevedibilità delle prestazioni contro analisi delle prestazioni

mercoledì 21 novembre 2007 alle 21:41 | Pubblicato su Diario, Performance Tuning | 4 commenti

predictable performance vs performance tuning

Oggi ho trovato un forte stimolo a scrivere un nuovo post leggendo l’ultimo post di Nuno Souto. Confesso che i toni usati solitamente da questa persona non mi piacciono molto, in ogni caso pare che sia comunque stimato per le sue capacità tecniche. Nel suo blog tali capità trapelano appena, mentre secondo me trapela di più un senso di frustrazione tipico del DBA. Nel suo ultimo post Nuno Souto sponsorizza un gruppo (Real World Performance Group) di cui un membro scrive un blog, già citato anche da Kevin Closson. Su tale blog si trovano anche delle presentazioni tenute all’ultimo Oracle Open World 2007. Da tali presentazioni Nuno prende spunto per il suo post. Secondo me appunto dal post trapela la frustrazione del DBA e un po’ di ipocrisia.

Anche io faccio il DBA (non proprio il consulente come pare faccia lui), anch’io alle volte mi sento frustrato, però lavoro in una azienda che sviluppa software e quindi vedo da vicino come vanno le cose. E’ facile dire: “bisogna fare una buona progettazione dello schema della base dati” mi ricorda i bei discorsi del corso universitario di “Ingegneria del Software”. In realtà nel mondo reale la concorrenza è spieatata e generalmente se un’azienda volesse impiegare il 50% delle risorse tempo uomini nella fare puramente progettuale probabilmente fallirebbe. La realtà è che si cerca un compromesso, si cerca di fare un buon progetto, secondo me però, oltre un certo limite, la proporzionalità fra sforzi e risorse impiegate e qualità del progetto non è lineare, cioè per fare un esempio per raddoppiare la qualità occore impiegare 10 volte tante risorse. Quindi generalmente si arriva fino ad un livello di qualità raggiungibile con una sforzo linearmente proporzionale, poi ci si cerca di barcamenare.

Inoltre, e questo secondo me è ancora più determinante, nella mia esperienza non ho visto progetti nascere con requisiti ben definiti e terminare con la soddisfazione di tali requisiti. Solitamente il prodotto finale ha ben poco a vedere con quanto inizialmente pensato. Questo ha un’influenza determinante sulla qualità globale del progetto, compreso del progetto della base dati.

Oggi su un programma che fa OLTP si vuole anche la reportistica e poi il datawarehouse e poi mille cose.

La mia esperienza quindi rispecchia in effetti quanto denuncia Nuno, i nostri database solitamente sono “I/O bound”, non “CPU bound” ovvero la nostra applicazione richiede un sacco di dati e l’elaborazione di tali dati non impegna tanto la CPU del database server quanto il sistema di I/O. Questo in effetti si discosta molto dai presupposti di molti messaggi di marketing di Oracle. Ne ho gia parlato in passato.

Il post di Nuno (fastidiosamente formattato in paragrafi separati da ampi spazi vuoti) ha una parte centrale dedicata a suggerimenti tecnici per dimensionare correttamente il sistema di I/O, in sostanza la “regola aurea” è di usare almeno un HBA (host bus adapter) per CPU se non due. Inoltre suggerisce di usare più di 4 dischi su RAID10 e definire diverse LUN, non poche e grandi. Qui ovviamente stiamo parlando di sistemi di un certo livello, da noi è ancora molto difficile convincere le persone che sarebbe meglio un RAID10 piuttosto che un RAID5. Anche le HBA mi risultano siano tutt’oggi piuttosto costose.

Nel post c’è un’incursione sul “partitioning” opzione di Oracle Enterprise Edition che permette in sostanza di partizionare le tabelle. Mi pare di capire che Nuno sostenga la validità della soluzione ma ne contesti il sovrapprezzo sulla Enterprise Edition. Io non conosco bene “partitioning” perchè nel nostro mercato già le licenze Entrerprise sono difficili da vendere.

Azzardo solo l’impressione che, per quel che ho visto di “partitioning”, nel caso ad esempio della applicazione sviluppata nella mia azienda, il partizionamento sarebbe di poco aiuto.

Neanche a me piace trovarmi all’improvviso con un’emergenza di prestazioni insufficienti, però è una situazione reale che capita e va affrontata, Oracle ne è ben consapevole e per questo a continuato a introdurre strumenti per affrontare tali situazioni e rimane uno dei compiti del DBA.

About these ads

4 commenti »

RSS feed dei commenti a questo articolo. TrackBack URI

  1. Ciao Cristian

    Un paio di commenti…

    > E’ facile dire: “bisogna fare una buona progettazione
    > dello schema della base dati” mi ricorda i bei discorsi
    > del corso universitario di “Ingegneria del Software”.
    > ….
    > Quindi generalmente si arriva fino ad un livello di
    > qualità raggiungibile con una sforzo linearmente
    > proporzionale, poi ci si cerca di barcamenare.

    Sinceramente non credo che il problema principale sia il tempo. In qualità di consulente specializzato in problemi di performance vedo spesso degli impieghi più che discutibili di Oracle. Il problema, alla base, è che persone chiaramente incompetenti si trovano a dover sviluppare software che usa un database come Oracle. Il risultato è chiaro: errori grossolani che chiunque con un minimo di esperienza non commetterebbe. E questo anche se il tempo a disposizione è scarso.
    Da notare che spesso la colpa è delle aziende stesse che non investono nella formazione del personale. Questo modo di agire a medio/lungo termine non può che nuocere a tutto e tutti (clienti insoddisfatti, dipendenti frustrati, costi più alti per le aziende, e così via…).

    > Azzardo solo l’impressione che, per quel che ho visto
    > di “partitioning”, nel caso ad esempio della applicazione
    > sviluppata nella mia azienda, il partizionamento sarebbe
    > di poco aiuto.

    Partitioning è sempre utile. Per decidere se acquistare questa opzione (come ogni altra cosa) bisogna valutare se i vantaggi (tempi di risposta, diminuzione dei costi per hardware, …) compensano la spesa.

    Buona serata,
    Chris

  2. Christian,
    grazie per i commenti, aggiungo una casa che in effetti conferma quello che dici: per mia personale esperienza, alla incompetenza si aggiunge una certa dose di ”supponenza”, quasi delirio di onnipotenza, interpretabile come arroganza che porta certi sviluppatori a pensare che Oracle si debba comportare come dicono loro. Quindi si fanna delle scelte progettuali senza preoccuparsi se queste portano a implementazioni software poco efficenti su un motore Oracle.
    In effetti per le aziende è molto difficile quantificare il costo della scarsa preparazione dei propri dipendenti, della frustrazione dei dipendenti della insoddisfazione del cliente. Spesso la perdita del cliente viene imputata a motivi “politici”. Ciò che si quantifica sono le “ore uomo”, il tempo necessario per arrivare alla firma del collaudo. Il resto è difficile da quantificare e quindi non lo calcola molto.
    Personalmente cerco di seguire l’approccio che Tom kyte descrive sul suo libro, collaborare con gli sviluppatori per insegnargli come funziona Oracle per permettergli di fare scelte consapevoli. Alcuni mi vengono a chiedere consigli, altri credono di dover prescindere da come Oracle funziana e pensano che sia Oracle a doversi adeguare.

  3. Concordo con Chris.
    Personalmente ho avuto l’esperienza di entrambi i tipi di sviluppatori descritti, in due aziende diverse. Sono felice di sentire che qualcuno, che ne ha viste più di me poiché consulente, la pensa come me.

    @Cristian:
    Lo schema dati è essenziale. È facile dirlo, è vero, ma ho conosciuto programmatori professionisti seri per cui questi principi sono la norma, in aziende medio-grandi.
    Dico ciò avendo anni di esperienza di errori che non si dovrebbero fare con uno schema dati (sempre grandi aziende), e ho risolto la questione cambiando lavoro.

  4. “In realtà nel mondo reale la concorrenza è spietata…”, statement molto italiano, “non c’è tempo, facciamo così, poi…”.
    Purtroppo la realtà è che gli errori prima o poi si pagano. “fare una buona progettazione” non vuol dire metterci anni e impiegare risorse considerevoli. Significa avere gli skill necessari e il tempo necessario in base all’applicazione. Il design dello schema, la scelta degli oggetti adatti (heap table, IOT, cluster? partizioni? Se sì come? ecc. ecc.) non sono scelte banali che si possono cambiare a posteriori facilmente, e hanno un impatto notevole sulle prestazioni.
    Inutile perdere un sacco di tempo a fare tuning di query a suon di hint, modificando parametri documentati e non e aggiungendo tonnellate di hardware nel disperato tentativo di mettere una pezza ad errori di base che spesso si accumulano nel tempo.


Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com. | The Pool Theme.
Entries e commenti feeds.

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.

Unisciti agli altri 71 follower

%d blogger cliccano Mi Piace per questo: