[pyar] Limitando size del input Queue de multiprocessing.Pool

[Alejandro Santos]

Lo decis por la llamada al time.sleep(random.randint(1,9) / 10.0)?
Esta puesta solo para darle mas emocion! Si comentas la linea se sigue
colgando en deadlock.

Aumentando la cantidad maxima de elementos en la Queue o la cantidad
de Workers solo dilata el problema, tarda mas en colgarse pero
eventualmente llega al deadlock. Por ejemplo aca en una PC con 8
cores, 20000 tareas maximas y 16 workers tarda 5 segundos en colgarse,
sin la llamada al time.sleep.



2014-04-07 14:26 GMT+02:00 Ezequiel Brizuela [aka EHB or qlixed]
<qlixed en gmail.com>:
> Creo q estas tratando de hacer una especie de ratelimit sobre la creacion de
> procesos. Para eso creo que tenes dos formas de resolverlo:
> 1) Rate control dinamico: vas lockeando 1 de cada n pedidos de nuevos
> procesos, haciendo n cada vez mas chico, a medida de q la queue crece.
> 2) rate control estatico: definis un valor, como tenes ahora, y con las
> peticiones q siguen podes hacer un lock como ahora, podes hacer descarte si
> ttenes la logica de reintento en el proceso encolador, o podes hacer una
> queue en disco y que el proceso encolador jamas sepa que paso, sssolamente
> note el delay de ejecucion de proceso.
>
> My 2 cents.
>
> El abr 7, 2014 4:44 AM, "Alejandro Santos" <listas en alejolp.com> escribió:
>>
>> 2014-04-06 15:20 GMT+02:00 Andres Riancho <andres.riancho en gmail.com>:
>> > 2014-04-05 19:52 GMT-03:00 Alejandro Santos <listas en alejolp.com>:
>> >
>> >> al tener un límite en la Queue de espera, sí, podés tener un
>> >> deadlock. El caso patológico es cuando tenés un límite de 1 en la
>> >> Queue del Pool, que scrapea una web y vuelve a encolar en el Pool las
>> >> webs linkeadas.
>> >>
>> >> Estoy (casi) seguro que, en general, si tenes un límite de X tareas en
>> >> la Queue del Pool, cada tarea no puede re-encolar más de (X-1) nuevas
>> >> tareas al Pool, de lo contrario llegás a un deadlock (pero hoy me
>> >> duele mucho la cabeza y una segunda opinion no me vendría mal).
>> >
>> > Bien, entonces creo que para estar seguro de que no haya un dead-lock
>> > voy a armar un test case en el cual una pagina devuelva X * 2 (solo
>> > para estar seguro) links a crawlear. De esta manera veremos a ver si
>> > ese dead-lock se triggerea o no :)
>> >
>>
>> Andres,
>>
>> Fijate que el segundo párrafo está mal lo que dije. En cambio, esto si
>> se cumple:
>>
>> 2014-04-06 1:10 GMT+02:00 Alejandro Santos <listas en alejolp.com>:
>> >
>> > El caso que se rompe con un deadlock, en general, es cuando tenés que
>> > procesar un grafo con forma de arbol y llegás a procesar el nivel del
>> > árbol que tiene X nodos con al menos un hijo/adyacente cada uno.
>> >
>>
>> ¿Cómo estás usando el Pool? Leyendo la doc de Pool encontré esto[0]:
>>
>> > Note that the methods of a pool should only ever be used by the
>> > process which created it.
>>
>> Asi que lo que hice fue un pool propio. Este programa entra en
>> deadlock muy rapido, cada vez que lo ejecuto en mi máquina imprime en
>> promedio 46 líneas.
>>
>>     https://gist.github.com/alejolp/10016215
>>
>> [0]
>> https://docs.python.org/2.7/library/multiprocessing.html#using-a-pool-of-workers
>>
>> --
>> Alejandro Santos
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar



-- 
Alejandro Santos