2016-04-09 45 views
6

Ho un programma che utilizza questo library fondamentalmente fa qualcosa di molto semplice, come questoprogramma python che blocca il 6% della CPU?

blocchi presa
receiver = multicast.MulticastUDPReceiver ("192.168.0.2", symbolMCIPAddrStr, symbolMCPort) 
    while True: 
      print 'Spinning' 
      try: 
        b = MD() 

        data = receiver.read(1024) 

Il ricevitore fino a quando i dati in arrivo, in modo che le uniche impronte print 'Spinning' una volta fino alla ricezione dei dati sul socket. Quando chiedo il sistema operativo quanta CPU questo processo è in corso, anche se si è in attesa di ricezione, si ritorna con:

[[email protected] ~]$ ps -p 4294 -o %cpu,%mem,cmd 
%CPU %MEM CMD 
6.3 0.4 python ./mc.py -s EUR/USD 
[[email protected] ~]$ 

Infatti, se corro molti di questi processi, il mio computer con due CPU e 8 core ciascuno, tutti i core passano al 100% di utilizzo e il computer diventa inutilizzabile.

Devo fraintendere la nozione di "blocco" di Python perché anche un processo di non fare niente che dovrebbe sostanzialmente dormire sta occupando molta CPU.

Esiste un modo più corretto per scrivere ciò in modo che i programmi che sono fondamentalmente in attesa di I/O [interrupt-driven] cedano la CPU?

+0

FWIW, ho appena programmato un programma molto simile in golang e l'utilizzo della CPU è come previsto quando nessun dato arriva nei processi, quasi a zero. – Ivan

+0

Dovrei aggiungere, però, che ho "compilato" il codice go. Sto iniziando a credere che molto di più è l'interprete python in testa. – Ivan

+0

Mi affido a Vai di più ogni giorno e Python in meno dato che è così conveniente scrivere codice ottimizzato in Go. – user161778

risposta

0

Non hai pubblicato un esempio completo, quindi è difficile dire con certezza cosa sta succedendo.

Tuttavia, vedo che c'è un blocco try all'interno del loop e il codice di rete è all'interno del blocco try. Non so cosa faccia la gestione delle eccezioni. Tuttavia, suppongo che faccia qualcosa come ingerire involontariamente un errore importante. Il ciclo quindi viene eseguito nuovamente e probabilmente genera lo stesso errore. In questo modo, il programma è in realtà occupato a ciclo continuo anche se pensavi che fosse addormentato, bloccando l'I/O.