Il giorno gio, 19/12/2013 alle 13.07 +0100, Roberto De Ioris ha scritto: > >> > >> 2013/12/19 Pietro Battiston <[email protected]> > > > > > >> [...] > >> > >> 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 _______________________________________________ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
