Newsgroup: it.comp.software.database
Titolo: [postgresql] lentezza database

Ciao a tutti.
    da qualche tempo il mio database postgresql gira molto lento. Ho provato
a fare un vacuum ma non ho risolto niente.
Ho provato a fare anche il seguente test. Ho creato un nuovo database sullo
stesso motore sul quale gira il mio database ed ho caricato tutti i dati del
database di lavoro.
Pur girando sullo stesso motore, con la stessa struttura del Db e con gli
stessi dati, il nuovo database gira mooolto più velocemente di quello di
lavoro.
Da cosa può derivare tutta questa lentezza del DB di lavoro e soprattutto
come faccio a ottenere delle prestazioni accettabili dal DB di lavoro ??
Grazie

Hai fatto solo un vacuum o un vacuum full analyze ..?
Prova con vacuumdb -f -z -d database 
Forse potrebbe migliorare la situazione ..
Saluti,
Fabrizio Mazzoni



:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

 che riparta "a mente sgombra".
A come avevo capito io, la VACUUM FULL ANALYZE dovrebbe farlo...
IMVVVHO, il problema delle diverse prestazioni tra DB "vissuto" e DB 
"fresco" potrebbe anche stare a livello più basso, ovvero del 
filesystem, specie se è journaled. Ma non ho dati per confermare questa 
tesi, è solo una cosa... istintiva, per così dire.
-- 
Fabrizio "Hermooz" Ermini

filesystem, specie se è journaled.
Ci avevo pensato ai tempi, e difatti avevo fatto la prova (tar di tutto
il database, a server fermo, cancellazione della directory e ripristino
di tutto l'ambaradan). Non gli fa :-(
(almeno a me)
Alla fine m'ero ridotto, una volta ogni molto, a fare un dump & restore
totale seguito da un VACUUM FULL ANALYZE. Questo su una macchina sola -
non so perche', ma solo quella manifestava il "problema". Ed il sintomo
piu' lampante era che ci metteva quasi un secondo per una DROP TABLE, a
server scarico (1 client -- il mio).
Non so se questa cosa e' poi sparita nelle versioni recenti, ne' ti do'
per certo che fosse collegata al rallentamento. Ho tentato di seguire i
voli di pg-hackers per un po', ma non stavo loro dietro :-)
Leonardo



potrebbe dipendere da tante cose.
Il mio consiglio e' usare pg_autovacuum e ogni notte
fare il reindex delle tue tabelle piu' stressate.
Facci sapere.
K.

 server scarico (1 client -- il mio).
Questo mi tornerebbe per un pgsql d'antan (ramo 6.x), che tentava (con 
esiti a volte distastrosi e comunque sempre poco efficienti) di 
mantenere in stato transazionale (cioč rollbackabbile) anche gli 
statement DROP. Ma se mi parli  di "vacuum full analyze" mi sa che ti 
stai riferendo a una 7.x... se te lo faceva su una sola macchina, č 
possibile anche che si trattasse di un problema generale della macchina 
(di glibc, o dei driver degli HD). Non saprei davvero dove andare a 
cercare pero'...
bye!
-- 
Fabrizio "Hermooz" Ermini

Grazie a tutti per la quantità e la qualità delle risposte. Ho provato un
vacuum full analyze ma ho visto che i tempi erano troppo lunghi per farlo
sul db di lavoro. Tale DB viene utilizzato per un portale web quindi gli
utenti non potevano più loggarsi nel portale e lavorare, con la logica
conseguenza di telefonate di protesta. Stasera provvederò a bloccare gli
accessi e a lanciare di nuovo il comando, sperando che lunedì tutto sia
sistemato
Mandi !
MX

 conseguenza di telefonate di protesta.
Questo purtroppo è un problema congenito di postgres (forse il più 
grosso). Per ridurlo si può schedulare dei vacuum periodici notturni, in 
momenti di poco traffico.
Per eliminarlo nella nuova 7.4 hanno introdotto il concetto di 
"auto-vacuum"... ma non ho capito se è cosa buona o no.
