[Python] Python, redis e bottleneck

[Pietro Battiston]

Il giorno gio, 19/12/2013 alle 13.07 +0100, Roberto De Ioris ha scritto:
> >>
> >> 2013/12/19 Pietro Battiston <me a pietrobattiston.it>
> >
> >
> >> [...]
> >>
> >> Io credo che ci possa essere relazione a come e' scritto il codice.
> >
> >
> > OK, ragionevole dubbio. Prendi _questo_ codice:
> >
> > import redis
> > import random
> >
> > r = redis.Redis(db=0)
> >
> > try:
> >     while True:
> >         r[random.random()] = random.random()
> > except KeyboardInterrupt:
> >     r.flushdb()
> >
> >
> > che gira su un vecchio Intel Core2 Duo CPU T7300, a 2 GHz, con 4 GB di
> > RAM DDR2 a 667 MHz.
> 
> 
> 
> Scusa ho iniziato a leggere il thread solo ora, spero di avere tutti gli
> elementi per risponderti:
> [...]
> > - Cosa posso immaginare che stia succedendo: che ci sia una latenza tra
> > CPU e cache, o tra una CPU e l'altra CPU, o tra le CPU e la RAM, che
> > "top" non sia affidabile al 100%.
> 
> 
> no no fermo, i risultati che hai sono in linea con il tuo approccio, il
> collo di bottiglia e' il tuo hardware nel suo insieme :)
> 

Wow. Confesso che la tua mail mi ha suggerito che forse la seguente riga
di "top":

%Cpu(s): 41,5 us, 13,2 sy,  0,0 ni, 44,8 id,  0,2 wa,  0,0 hi,  0,4 si,
0,0 st

non fosse lì per bellezza.

A questo punto mi resta un dubbio: "sy" dovrebbe in effetti
rappresentare per l'appunto il tempo speso in kernel space. Considerato
che i valori sopra sommano a 100, il tempo speso nel context switching
in sé sarà incluso in questo valore? In "id"? Spalmato tra "sy" e
"us" (a seconda della "direzione" del context switching)? Tutto sommato
irrilevante?


> >
> > - Cosa me ne frega: pura curiosità, e magari pure un indizio di quanto
> > parallelizzare codice che utilizza in modo intensivo redis possa o meno
> > migliorare le prestazioni in modo lineare, o se viceversa qualunque cosa
> > mi stia facendo da bottleneck adesso si riproporrebbe anche
> > parallelizzando, magari su più di 2 CPU.
> >
> 
> 
> redis e' mono thread, puoi 'parallelizzare' la parte python ma visto che
> l'hardware ha "solo" 2 cpu e hai comunque 2 processi fissi nell'equazione
> (python e redis) non otterresti alcun vantaggio (anzi peggioreresti)
> 


Sento che sto per vedere la luce, ma non mi è ancora chiarissimo perché
un processo python aggiuntivo, magari con niceness bassa, non potrebbe
sfruttare il 60% di CPU che il processo redis non utilizza - anche
eventualmente "sprecandone" un 10% in kernel space, e quindi girando al 50%...

O in altre parole: il campo "sy" di top mi suggerisce che il 13% speso
in kernel space sia proprio "quel 26% che manca" al processo python per
girare al 100%, e che quindi quasi tutto il tempo in kernel space sia
speso, per l'appunto, nella "sua" CPU. È un modo sbagliato di
ragionare?
Magari la risposta è la stessa di sopra - il context switching è in
realtà conteggiato in "id"?


> 
> Spero di averti tolto i dubbi :)
> 

Ci vedo già parecchio più chiaro, grazie!

Pietro