[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Postgresql e kernel/user mode benchmark



[...]
> > secondo me stai facendo i test sbagliati, ovvero il problema dei
> > database e' piu' facile che sia l'I/O piu' che il consumo di CPU.
> > Dovresti giocartela sul filesystem piu' che altro. 
> 
> Mmm, potresti avere ragione, pero' prima devi chiarirmi perche'
> dovrebbe esserci una differenza nell'I/O se i db sono su 2 istanze
> differenti o sulla stessa.

ah, nessuna, era una considerazione generale sulle prestazioni dei DB.
Anche se, ora che mi e' tornata la memoria, ho visto piu' DB schiattare
sul tempo in CPU che su quello in I/O... ma il problema era del database
fatto coi piedi, non dell'hardware sottodimensionato. 

Magari il fatto che siano 2 processi a dover scrivere/leggere peggiora
l'I/O ?

> > Credo che il fatto che che 2 istanze e 2 db perdano piu' tempo in
> > kernel mode sia dovuta allo scheduler del kernel che deve switchare
> > tra i 2 processi... mentre il fatto che il tempo in usermode di 1
> > istanza e 2 db sia piu' alto e' per il sovraccarico di PG.
> 
> Questa analisi la condivido.
> 
[...]
> Non ho postato i dati della macchina per non appesantire troppo la
> mail. Per ora le prove le faccio sul mio portatile, tra poco le faro'

figurati, pensavo fosse un problema pu' specifico e non puramente
accademico (da qui anche l'affermazione sull'I/O di prima) 

[...]
> Grazie ancora per gli spunti che mi hai dato, inseriro' la lettura
> dell'I/O nel comando time, tanto non mi costa niente farlo.

poi posta i risultati, mi interessa :)

In generale comunque un processo bloccante in kernellandia e'
_veramente_ bloccante, in userlandia ci si puo' lavorare per lo meno.
c'e' da dire anche che esistono un popo' di patch per il kernel che
dovrebbero rendere piu' reattiva la macchina in casi estremi, ma non
sono mai andato a fondo sulla questione e potrei spararle grosse anche
su questo... preemtion, uml...

aloha
-- 
mattia



Reply to: