Newsgroup: it.comp.os.linux.sys
Titolo: [OT] DB Assurdi

-rw-rw---- 1 mysql mysql 937G giu 28 15:18 Log.MYD
-rw-rw---- 1 mysql mysql 177G giu 28 01:50 Log.MYI
 
 
via con la gara....


4.7 TB su un unico DB mysql, ma � partizionato in maniera decisamente
pi� opportuna di questo...

 più opportuna di questo...
 
Ah no, troppo facile così, voglio vedere l'ls...

 -rw-rw---- 1 mysql mysql 177G giu 28 01:50 Log.MYI
 
Sta facendo il truncate da oltre 4 ore...


Il truncate della tabella log ?
Se è cosi 4 ore mi sembrano un po troppe
 

 Se è cosi 4 ore mi sembrano un po troppe
 
E' poco meno di 1TB di database.
Comunque ho brutalmente killato mysql ed ora sta cancellando la tabelle, poi riavvio e ricreo. Si fa prima.


Non essendo uno dei miei db preferiti (prefisco oracle e postgresql), ti 
faccio una domanda se posso
Un kill brutale, con conseguenti cancellazioni a livello di file system 
(cosi mi sembra che tu voglia operare) non porta problemi al riavvio ?
 

 (cosi mi sembra che tu voglia operare) non porta problemi al riavvio ?
 
Trattandosi di MyISAM, quindi con tutti i suoi bei file, no, al riavvio non vede più la tabella e se ne sbatte allegramente.
 
Già fatto milioni di volte. Stoppo il DB, cancello, riavvio il DB e ricreo le tabelle. Fatto anche 10 secondi fa con successo.
 
Perchè, postgresql è più pignolo ?

 Ah no, troppo facile cos�, voglio vedere l'ls...
 
Sono una roba tipo 1200 tabelle, non credo di volerlo fare :-P
 


Postgresql non lo so, non ho mai provato
E oracle non ha una mappatura file <=> tabella, ma usa una 
rappresentazione logica chiamata tablespace (composto da uno o piu file 
del file system) contenente oggetti (tabelle,viste,ecc..)
 
Buono a sapersi
Grazie
 
 


Macch�, son rimasto un po' indietroin...
 
myserver:/var/lib/mysql/${database}# du -sh .
5.9T	.
 
myserver:/var/lib/mysql/${database}# find . -type f | wc -l
11400

 11400
 
In tutti e due i casi, spero si tratti di tabelle di log o simili e non
di un db di un ERP o simile. Altrimenti � da ammazzare sul posto chi ha
scelto mysql.

 Sono una roba tipo 1200 tabelle, non credo di volerlo fare :-P
 
Te imbrogli, la mia è *UNA* tabella da quasi 1TB, non 1200. :-D


Non proprio log, ma qualcosa di simile. In ogni caso, la scelta di mysql
� stata ben pesata: la stessa cosa su altre piattaforme andrebbe
decisamente peggio...
 

 Usare MySQL � da pazzi a prescindere.
 
Questa � una troiata col botto :-D
 

 Non c'e' ragione alcuna per non usare posgresql. Altra galassia IMHO.
 
Spiacente, ma insisto, e fidati: lo faccio a ragion veduta... :-)
 
Il punto è tutto in un vecchio motto: "one size doesn't fit all".
 
Non tutte le applicazioni hanno necessità di integrità referenziale,
transazioni etc.; che, se da un lato sono vitali per chi vuole un RDBMS
full featured, dall'altro rendono il motore piuttosto pesante.
 
Nè tutte le applicazioni sono sufficientemente semplici nella loro
struttura d'accesso da poter essere portate facilmente ad approcci NoSQL.
 
 
Mysql (e per ridicolo: MyISAM più ancora di InnoDB) riempie un gap
piuttosto consistente in quella terra di mezzo, e soddisfa le esigenze
una pletora di applicazioni tutt'altro che banale.
E non necessariamente roba "piccola e cretina" come un guestbook,
fidaty(TM)... ;-)
 
Poterbbe fare altrettanto anche Postgres, certo; ma richiederebbe HW più
grosso per cavar fuori le stesse prestazioni...
 
Di nuovo: dipende da chi sei, cosa fai e quali sono le tue necessità.
 
Tra Postgresql a BerkeleyDB c'è un sacco di posto... :-D
 

 del file system) contenente oggetti (tabelle,viste,ecc..)
 
<OT>
Oracle si pianta solo a guardarlo ed è incasinatissimo da gestire.
</OT>
 
-- 
chi va pian va san e va lontan


 
Se non lo conosci
 
 
 

 peggiori di un MySQL moderno ... anzi scommetterei il contrario ;)
 
un po' di tempo fa avevo visto dei benchmark mysql vs. postgresql 9.
 
Alla fine e' saltato fuori che pg rimane un po' piu' pesante per la roba
piccola, ma poi appena si hanno parecchi accessi e/o tabelle molto
grosse scala decisamente molto meglio.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?


 
Si,le avevo lette anch'io quelle comparazioni
con oracle e con mysql
Ritengo postgresql un gran database, ricco di funzionalità, efficiente e 
scalabile
 
 
 

 grosse scala decisamente molto meglio.
 
Più o meno (almeno nella mia esperienza con tabelle molto grosse).
Mysql su alcune applicazioni "meno da RDBMS" (aka: MyISAM) si comporta
meglio (anche con tabelle enormi), fintantochè l'uso è semplice e diretto.
Quando inizi a tirare dentro query più complesse, mysql si siede molto
più velocemente di Postgres, il che fa sì che il primo possa avere un
best-case migliore, ma ha anche un worst-case molto peggiore...
 
Di nuovo, questa è esperienza personale, ma quel che capita a me di
farci è abbastanza anomalo, e "non molto RDBMS" (anzi, praticamente
non-R per nulla).
 

 peggiori di un MySQL moderno ... anzi scommetterei il contrario ;)
 
Se non ricordo male, l'obiettivo principale di PostgreSQL 8 fu quello di 
migliorare le prestazioni (che, fino a PostgreSQL 7, erano modeste). 
Obiettivo centrato anche grazie al modello architetturale scelto dagli 
sviluppatori, che differisce decisamente con quello di MySQL (pgsql esegue 
un fork, mysql crea un thread)
 
Enrico

 grosso per cavar fuori le stesse prestazioni...
 
Non mi sembra (ovvero ho provato sulla mia pelle) che ci voglia un hardware 
degno di mostri blasonati (leggasi Oracle RDBMS) per ottenere prestazioni 
importanti con PostgreSQL. Inoltre, da quello che vedo, nemmeno MySQL e` 
quel fuscello che si vuol far credere...
 
Enrico

 Oracle si pianta solo a guardarlo ed è incasinatissimo da gestire.
 
Che abbia una pletora di parametri da gestire e` vero, che si pianta solo a 
guardarlo e` palesemente falso
 
Enrico

 un fork, mysql crea un thread)
 
Scusa, ma un fork dovrebbe essere piu`
"pesante" di un thread.
Non sara` in contrario?
Oppure intendevi altro?
 
bye,
 
-- 
 
piergiorgio

 "pesante" di un thread.
 
Se non ricordo male lo e` a livello di memoria, ma non lo e` a livello di 
prestazioni (anche perche, storicamente, i sistemi *nix sono pensati per 
gestire meglio i fork piuttosto che i thread)
 
Enrico


Solo l' atto di creazione del nuovo processo è più pesante rispetto alla 
creazione del thread
Una volta fatto,praticamente non c'è differenza
Ovviamente se la durata nel tempo del processo è relativamente piccola 
allora il fork è relativamente pesante, ma un db non fa così, mantiene 
un pool di processi attivi
 

 un pool di processi attivi
 
Non ne sono convinto... :-)
 
bye,
 
-- 
 
piergiorgio


Da quello che so io il fork e` piu` pesante da
eseguire, cioe` il fork del processo, ed e`
anche piu` pesante run-time, dato che causa
un task switch (che e` pesante).
 
Storicamente, i thread non esistevano in Unix,
ma non siamo piu` nel 1980, i thread sono gestiti,
anche a vari livelli.
 
bye,
 
-- 
 
piergiorgio


Sulla durata od il pool (o altro) ?
 

 nello stesso contesto del processo.
 
no.
I thread sono visibili dall'OS che ne gestisce il context switch sui
processori. Infatti si parla di "Thread Nativi" e sono per l'OS delle
entita' separate dal processo padre (ogni thread ha un suo stack, anche
se condivide la memoria e il codice).
 
Il vantaggio di usare processi al posto di thread principalmente e' che
la memoria e' separata (non rischi che se una thread si impalla blocca
tutte le altre a causa di un lock) e che se crasha uno dei processi
"cloni" non influisce sul funzionamento degli altri.
Di contro la comunicazione fra processi e' piu' difficile e la creazione
di un processo e' piu' pesante che un thread.


 se condivide la memoria e il codice).
 
Sono anni che non studio la faccenda, ma da quel che sapevo la 
differenza, in Linux, tra thread e processo è minima.
 
Sono entrambi rappresentati da processi in memoria e per lo scheduler, ma 
i thread hanno un'area di memoria (quella per i dati) condivisa, mentre 
nei processi è in COW (quindi condivisa all'inizio, ma clonata e allocata 
dinamicamente alla prima modifica).
 
Il vantaggio dei thread è che non devi usare IPC per accedere ai dati 
"condivisi", ma di contro devi implementarti tu l'arbitraggio di accesso, 
soprattutto su un SMP. Se due processi scrivono contemporaneamente la 
stessa variabile sono tutti ca**i tuoi. :)
 
La creazione di un processo o di un thread costa più o meno uguale. Un 
processo è più lento di un thread nel momento in cui deve condividere 
dati con gli altri processi (deve chiamare delle IPC e attendere gli 
altri processi), ma d'altro canto se non implementi le stesse 
sincronizzazioni, rischi di rompere tutto, su un thread.
 
Bye.

 di un processo e' piu' pesante che un thread.
 
Appunto, ma qui si scriveva di "prestazioni migliori"
usando i processi invece che i thread.
 
Da quello che so io, i thread sono fatti _apposta_
per fornire un multi-tasking leggero, pagando come
prezzo la minore o totale mancanza di separazione.
 
bye,
 
-- 
 
piergiorgio

 Sulla durata od il pool (o altro) ?
 
Sul fatto che avere un pool attivo di processi
sia equivalente ad avere thread.
 
Il punto e` che in caso di contex switch, per un
processo _tutto_ il contesto deve essere salvato
(prima) e caricato nuovo (dopo).
Per un thread solo alcune parti.
Per esempio, tutti i registri della MMU non devono
essere salvati e ricaricati in caso di thread.
 
Anche se il DB non crea processi uno dietro l'altro
ma usa un pool, ha sempre il peso del contex switch.
 
La mia domanda iniziale si riferiva al perche`
*passare* dai thread ai task (cioe` fork) dovrebbe
migliorare le prestazioni (velocistiche, intendo).
 
bye,
 
-- 
 
piergiorgio

 differenza, in Linux, tra thread e processo è minima.
 
Parte della differenza sta addirittura in glibc.
Nel senso che e` solo una cosa user level.
 
D'altro canto, non e` che vi sia solo quel modello.
 
bye,
 
-- 
 
piergiorgio


 
Quella frase non è mia ed effettivamente non condivido molto,credo che 
sia piu importante concentrarsi sugli algoritmi interni al db che farsi 
pippe mentali se usare fork o thread
 
Le  motivazione thread vs fork possono essere riassunte (il primo url 
che mi è capitato) qui:
http://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel/
 
 
 

 (infatti si chiama thread context switch)
 
Ripeto, il context switch dei thread e` piu`
*leggero*, rispetto ai task.
Nel caso di task di deve "swappare" _tutto_ il
contesto, nel caso di thread solo alcune parti.
 
bye,
 
-- 
 
piergiorgio


Chiedo scusa, una svista
 

 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 pesa di più della rapidità del multithread?
 
Dipende dal modello di programmazione che adotti.
 
Esempio stupido: hai un algoritmo altamente parallelizzabile che può 
agire su zone diverse del tuo dominio dati. Mettiamo che devi sommare 
tutti i numeri da 1 a 100.
 
A questo punto puoi allocare 100 long e poi lanciare 10 thread. Al primo 
assegni le posizioni da 0 a 9, al secondo da 10 a 19, ecc.
 
A questo punto non hai bisogno di nessuna sincronizzazione. Ogni thread 
lavora nel suo spazio senza dover segnalare niente a nessuno. Quando ha 
finito mette il risultato in un altro long predefinito e muore.
 
Il processo padre si mette in ascolto delle morti dei figli e, quando 
tutti hanno finito, prende i 10 long e li somma tra loro.
 
In questo caso fare 10 processi sarebbe molto più costoso che fare 10 
thread.
 
In altri casi, può capitare che il S.O. gestisce la sincronizzazione 
meglio di quanto puoi fare tu, quindi paradossalmente i processi 
potrebbero essere più veloci dei thread.
 
Bye.

tutti i numeri da 1 a 100.
 
L'esempio e' anzi parecchio sottile :-)
 
Infatti, in questo caso (ma accade piu' spesso di quanto uno creda!), se uno
cambia l'algoritmo guadagna piu' che da tutte le parallelizzazioni di questo
mondo :-)
 
Leonardo
 
-- 
Were I Glenallan's Earl this tide, and were you Roland Cheyne,
My spur would be in my horse's side, the bridle upon his mane.
If they hae twenty thousand blades and we twice ten times ten,
Yet they hae but their tartan plaids, and we're mail-clad men.

 di questo mondo :-)
 
Conosco Gauss, eravamo in classe insieme! ;)
 
Sì, l'esempio era stupido proprio per questo, ma ci sono campi in cui una 
divisione del genere può avere un senso. Mi pare, per esempio, che il jpeg 
consideri griglie di 8x8 pixel durante la compressione, e quindi possa 
essere parallelizzato bene, e lo stesso alcuni algoritmi di crittazione, 
ma la matematica dietro è fuori dalla mia portata.
 
Bye.

 più della rapidità del multithread?
 
Potrebbe anche essere, per questo ho
chiesto spiegazioni.
 
La "teoria" e` che i thread siano piu` veloci
dei task, ma la "pratica"?
 
Forse, nel caso specifico di postgres, vi sono
delle ragioni per cui i task sono piu` prestanti
dei thread.
 
bye,
 
-- 
 
piergiorgio

 un fork, mysql crea un thread)
 
Una domanda, visto che non ho mai avuto modo di fare comparazioni di
performance tra Postgres ed altri motori, né conosco l'architettura
interna di Postgres.
 
Se ho un processo unico su cui gira tutto il motore del db, quando un
utente fa una query, vengono caricati i dati in ram. Se un altro utente
esegue una query che interessa gli stessi dati, questi ultimi sono già
in ram, quindi la risposta è più veloce.
Se invece ho un processo per ogni connessine, la seconda connessione
deve ricaricare i dati dal disco, oltre a tenerli due volte in ram.
Forse la cosa è mitigata dal fatto che su *nix la cache dei dati su
disco è molto più utilizzata rispetto a windows?

 deve ricaricare i dati dal disco, oltre a tenerli due volte in ram.
 
No, PostgreSQL dedica una locazione di memoria proprio per tenere in cache 
questi dati, chiamata shared buffer (qua trovi un po' di informazioni: 
http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf
 )
 
Enrico

 </OT>
 
Oh, è il thread dei luoghi comuni, questo? :)
Preferisco Postgres, ma insomma, da qui a dire che Oracle si pianta solo a guardarlo...

 </OT>
 
Chissà perchè *tutte* le più grosse banche al mondo lo usano...

 Oh, è il thread dei luoghi comuni, questo? :)
 
A dire il vero era il thread dei DB dalle dimensioni assurde ma poi qualcuno me l'ha rubato in favore di una pallosissima discussione :-D paurosamente OT.


A me risulta che quasi tutte le piu' grosse banche usino DB2 su z/OS...


Usano anche Oracle, non hanno solo i mainframe
 

 a guardarlo e` palesemente falso
 
Lo so, sono sfortunato. Ma a causa del numero incredibile di parametri 
succede che uno di questi (mi pareva il max numero di cursori aperti ma non 
mi ricordo bene) ti pianta uffici e produzione e di solito succede di notte.
 
Nicola.
 
-- 
chi va pian va san e va lontan


Occorre saperne regolare il massimo per sessione e naturalmente 
chiuderli quando non servono
Quando succedono queste cose quasi mai la colpa è di Oracle, ma del 
programmatore
 

 programmatore
 
Oh, beh di sicuro è colpa del programmatore. E' colpa del programmatore 
anche quando sbaglia le sintassi delle query, ma per fortuna il db se ne 
accorge e non crasha.
Mi aspetterei che dopo aver chiuso tutti i client con il software 
(sicuramente bacato) che si collega al db, oracle riprenda a funzionare. 
Invece niente, rimane lì inchiodato.



Cosa significa inchiodato, che non ti puoi più collegare con un client ?
 

 Cosa significa inchiodato, che non ti puoi più collegare con un client ?
Esatto.



 
Che versione hai  e su quale OS ?
Hai parlato con un  admin per dare una occhiata al sistema ?
Quando ti colleghi viene emesso un errore oppure la connessione rimane 
appesa ?
 
 

 appesa ?
Boh, non mi ricordo. Ho fatto un po' di modifiche ad oracle, ho fatto un po' 
di modifiche all'applicazione ed infine ho detto agli utenti di non aprire 
il software 100 volte. Al momento la cosa tiene botta ma non so quale dei 3 
interventi ha avuto successo :)
Magari la prossima volta che succede (spero mai!) mi faccio sentire sul 
newsgroup.



Se per questo usano anche Windows... e non solo le banche!
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 


 
O Ubuntu server...ma il core buisness rimane su zOS e DB2...

> A me risulta che quasi tutte le piu' grosse banche usino DB2 su z/OS...
 
Nella banca dove lavoravo io c'era dl1, db2 e oracle.
La gestione dei conti correnti era in grandissima parte in dl1, nel mio
ambito lavoravo quasi solo in db2, oracle non so in che ambito veniva
usato, ma c'era.
 
-- 
------
 
 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it