Il giorno gio, 19/12/2013 alle 14.06 +0100, Roberto De Ioris ha scritto: > > Il giorno gio, 19/12/2013 alle 13.07 +0100, Roberto De Ioris ha scritto: > >> >> > >> >> 2013/12/19 Pietro Battiston <m...@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. > >> > >> > >> > >> > - 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? > > > per context switch in realta' si intende il tempo (software) impiegato dal > sistema a tornare in "kernel mode" (e viceversa) diciamo che e' solo una > piccola parte di 'sy' (che comprende anche il tempo impiegato dalla > syscall stessa) ma ha comunque il suo peso nell'insieme. >
OK, perfetto. > Se ti interessa (presumo di si) leggiti le vecchie (ora e' cambiato > parecchio ed e' imho piu' complesso da capire) guide su come chiamare una > syscall in assembler x86 (int 0x80). Questi frammenti di codice (sperando > che siano commentati) di solito chiariscono le idee molto piu' di interi > libri di teoria sui sistemi operativi. > Uhm... dovrei darmi una rinfrescatina (notevole eufemismo) all'assembler, ma se ho tempo ci do un occhio. > > > >> > > >> > - 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%... > > > > perche' andrebbe a pesare su redis nuovamente, di fatto introducendo > un'altra problematica, ovvero che redis deve gestire due stream di > richieste diventando il vero collo di bottiglia. > Già, certo. > Ovviamente se cambi l'architettura in modo che uno solo legga e tutti e > due processano il discorso cambia, ma non so quanto sia fattibile nel tuo > caso. > In realtà nel mio caso specifico il collo di bottiglia è comunque la comunicazione con Redis (dovuta a scritture più che letture), quindi no, non cambierebbe molto. Grazie mille dei chiarimenti. Pietro _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
