Newsgroup: it.comp.appl.notes-domino
Titolo: Performance DB <--> Size DB.

Mi sono accorto, ma vorrei sbagliarmi, che i database di un certo
spessore ( diciamo oltre i 100Mb ) hanno performance di accesso
veramente ridicole.
Ho un archivio di planing locale, che in origine era una bomba, negli
ultimi tempi per salvare un documento ci puo' impiegare anche 20
secondi.
Il database in questione e' di 8-9000 documenti per una grandezza di
160Mb.
Vi sono delle accortezze che possano eliminare-ridurre il problema?
Grazie a tutti come sempre.

160Mb.
!!
Io lavoro con DB anche di Oltre 2 Giga.
NON ho problemi alcuni di tempi salvataggio.
Avevo problemi x' x'erano una marea di viste fatte a cazzo... e una
marea di interrogazioni su queste viste che (spesso) nella formula di
selezione e nelle colonne ordinate comprendevano formule.
Allora si che c'era da piangere.
Passata la fase, anche con 150.000 documenti su una macchinetta, tutto
va benone.
Spero Aiuti.
Ciao!

va benone.
Non sara' mica la macchinetta PII400 256Mb che inizia ad essere
stretta per una 20 di persone in contemporanea?!?!
Oppure la release 5.0.3?!?!

Oppure la release 5.0.3?!?!
Bel mistero... io credo che l'HW sia sufficiente.
Magari la release qualche problem potrebbe averlo.
Faccio davvero fatica a capire.
Ci devo pensare un po', se mi viene in mente qalcosa te lo comunico.

Ci devo pensare un po', se mi viene in mente qalcosa te lo comunico.
Non e' che Domino col passare del tempo ( almeno questa versione ) si
genera grossi trash?!?!
Esisteranno parametri per l'UPDALL mirati?

Chiamami e risolviamo...
--
Juda of 3AM - juda(strudel)
despammed.com
/---------------/
Nella mia condizione di base sono piuttosto acido, ma difficilmente
rimango di sale.

 Esisteranno parametri per l'UPDALL mirati?
Se il sistema e' multi processore puoi avviare piu' istanze di updall. A
me ha aiutato tantissimo avere su un sistema due processi
di update. Non ho mai provato su un sistema monoprocessore ad avere piu'
updaters.
Poi ci metterei un bel tunig dei vari parametri come buffer a cache
varie, anche uqesto aiuta. A domino piace la ram piu' ne ha
e piu' e' contento. Ci sono anche le voci dei proreties del db come il
non considerare i non letti, e tenersi poco storico su chi modifica
il documento. Dovresti fare qualche esperimento ... ogni applicazione e'
un mondo a parte, se sei convinto che il db sia apposto di
design ... prova con i vari paratri nel notes.ini. Te ne posso suggerire
alcuni.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Oppure la release 5.0.3?!?!
... io avrei preso un processore meno potente e piu' ram ... mio parere.


 NON ho problemi alcuni di tempi salvataggio.
... a settembre 2001 ho ultimato un progetto che altri avevano inziato e
che ritardava ormai da 6 mesi.
L'applicazione vive ancora ed e' abominevolmente grande: il db e' 4 GB,
la directory dell' text index e'
circa 2 GB ... ci sono 600.000 documenti. Quanto sono arrivato lo
sviluppo era praticamnte concluso
e sul sistema di test era anche veloce ... quanto sono stati caircati
tutti i dati ... l'applicazione era inutilizzabile:
15 minuti per salvare un documento ... processori sempre al 100%, dischi
che facevano scintille.
Abbiamo preso il template e sono stati rivisti tutti gli agents e
semplificato viste, tolti controlli dai documenti e questo
ha significato rivedere l'anali dell'applicazione ... in maniera
profonda, trovare soluzioni alternative per ottenre lo
stesso risultato ... ma in maniera piu' performante.
Ho reinstallato la macchina configurando opportunamente il controller
raid ( write back ) ... usato NT4 e non
 W2K, giocato con i parametri del notes.ini fino alla paranoia. Non ho
mai lasciato che creasse gli indici delle viste
in automatico ... sempre un bel updall -r , -c , ecc.
Alla fine posso dire che l'applicazione e' decisamente performante ...
non rimance una scheggia ma si lavora bene
sia in remoto via web che in local con notes. Il bilancio cmq e' un 50%
e' stato il design del template e 50% la configurazione
della macchina ... per la quale ho preso solo altri 512MB di ram ...
adesso c'e' un NFS_BUFFER di 800MB ... il resto era
per NT ... in modo da non swappare mai :-)


... io avrei preso un processore meno potente e piu' ram ... mio parere.
Inizio a pensare che sia la RAM che non regge bene DB di certe
dimensioni.
Infatti un copia database in una directory TEST fa' viaggiare
l'applicazione come una bomba. Quindi le uniche differenze sono le
indicizzazioni delle viste. Secondo me da quando ce le ha tutte
indicizzate piega le gambe.
CMQ, TNKS.

Chiamami e risolviamo...
Ti chiamo, ma non per questo problema, in questo momento secondario ed
interno, ma....
per risentirci visto che sono un latitante nei tuoi confronti....
per pizza e vino ( visto che Firenze- Siena e' ad un tiro di schioppo)
e....
per una cazza da un cliente che non cio' capito una mazza...
Infatti postero' a breve il problema anche sul news.

per una cazza da un cliente che non cio' capito una mazza...
Vabbuò...
--
Juda on the web
--------------------------------
Inviato via 
http://usenet.iol.it
 

 indicizzate piega le gambe.
Ti paresse poco...
