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

[Ezequiel Brizuela [aka EHB or qlixed]]

No se como son esas implementaciones. Pero lo mejor es hacer que la
serializacion a el archivo sea via mmap.
El abr 7, 2014 8:20 PM, "Andres Riancho" <andres.riancho en gmail.com>
escribió:

> Esa no es una mala idea! Serializar los parametros a disco seria
> posible ya que tambien tienen que ser serializables para entrar en una
> multiprocessing.Queue... hmmm... lo agrego a mi lista de cosas a
> probar.
>
> La gente de scrapy tiene una implementacion [0] de una queue que se
> guarda en disco. Y aca [1] hay otra que tiene un cache para no ir a
> disco cada vez que se hace put/get.
>
> Nota: en realidad estoy usando el ThreadPool de multiprocessing, por
> lo que no seria tanto problema reemplazar el Queue de entrada que
> utiliza eso (que es un simple Queue y no un multiprocessing.Queue) con
> alguna de estas opciones
>
> [0] https://pypi.python.org/pypi/queuelib
> [1] http://code.activestate.com/recipes/501154-persistent-queue/
>
> 2014-04-07 20:01 GMT-03:00 Ezequiel Brizuela [aka EHB or qlixed]
> <qlixed en gmail.com>:
> > Respecto al tema de limitar el tamaño de la cola, no te sirve limitar la
> > cola en memoria "tirando" el resto a disco? Si el pool es siempre para la
> > misma funcion solo deberias serializar los parametros....
> >
> > El abr 7, 2014 6:45 PM, "Andres Riancho" <andres.riancho en gmail.com>
> > escribió:
> >
> >> Uy, se torno algo interesante finalmente mi post :) Les tiro algunas
> >> cosas extras y comentarios sobre todos los mails anteriores:
> >>
> >>  * Disclaimer: La pregunta no es especifica de w3af, pero la estoy
> >> haciendo debido a que mi problema se encuentra en ese software. De
> >> todas maneras, es un problema que posiblemente se encuentren otros
> >> cuando empiecen a mandar muchas tareas a un multiprocessing.Pool
> >>
> >>  * Se dijo en uno de los emails: "Creo q estas tratando de hacer una
> >> especie de ratelimit sobre la creacion de procesos", no, ojo que esto
> >> es un multiprocessing.Pool, y no hay creacion de nuevos procesos
> >> (salvo que alguno del pool se muera). Lo que estoy intentando limitar
> >> es la cantidad de tareas que quedan encoladas, esperando ser
> >> procesadas por el pool.
> >>
> >>  * Una de las partes de w3af que más abusa de encolar nuevas tareas en
> >> el Pool, corriendo desde un worker es el web_spider [0], más
> >> especificamente el metodo _extract_links_and_verify [1]
> >>
> >>  * En el codigo de w3af lo que ocurre en general es que el core llama
> >> al web_spider con una URL, el spider hace un GET a la URL, parsea el
> >> response body, y para cada una de las URLs nuevas verifica a ver si es
> >> un 404 o no (usando el Pool). En caso de que esa URL NO sea un 404, la
> >> misma se envia nuevamente al core para continuar con su procesamiento.
> >>
> >>     Continuar con su procesamiento significa que ocurre nuevamente lo
> >> mismo, el core envia la URL al plugin de web_spider, se encuentran
> >> links, etc. El core desde el main thread va mandando tareas al pool,
> >> que corre los plugins.
> >>
> >>     Al menos en esta parte del codigo, solo tengo "1 nivel de
> >> funciones de multiprocessing.Pool" anidadas.
> >>
> >>  * Hice una prueba rapida con un limite de 500 en el Queue, no obtuve
> >> problemas mayores... pero todavia me falta hacer mucho más testing.
> >>
> >>  * Mientras que escribia esta respuesta se me cruzo por la mente el
> >> RLock [2], quizás estaría bueno tener algo de ese estilo pero para la
> >> queue de entrada del Pool? Es decir, si el queue esta lleno y quiero
> >> encolar una tarea desde dentro de otra tarea: me lo permite, pero si
> >> quiero encolarla desde el main thread no me lo permite. De esa forma
> >> podria evitar los dead-locks. No se si existe... pero es lo que se me
> >> cruzo por la mente.
> >>
> >> [0]
> >>
> https://github.com/andresriancho/w3af/blob/master/w3af/plugins/crawl/web_spider.py
> >> [1]
> >>
> https://github.com/andresriancho/w3af/blob/master/w3af/plugins/crawl/web_spider.py#L199
> >> [2] https://docs.python.org/2/library/threading.html#threading.RLock
> >>
> >> 2014-04-07 12:53 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:
> >> > 2014-04-07 10:40 GMT-03:00 Alejandro Santos <listas en alejolp.com>:
> >> >>> No es exactamente lo mismo, y para páginas web, con un alto índice
> de
> >> >>> conectividad, la anchura puede ser considerable.
> >> >>>
> >> >>> También, pensándolo mientras escribo esta respuesta... ¿deduplicás
> los
> >> >>> links antes de meterlos en la cola?
> >> >>>
> >> >>
> >> >> Disclaimer: no tengo nada que ver con W3AF, solamente me resulto
> >> >> atractivo el problema :)
> >> >>
> >> >> (y en algun momento hace muchos a;os use w3af y me parecio una
> >> >> herramienta interesante)
> >> >
> >> >
> >> > No entiendo.
> >> >
> >> > Del thread, me dio la impresión que lo que hacías era similar a un
> >> > crawler.
> >> >
> >> > ¿Qué hacés realmente que genera un grafo tan ancho que no te entra en
> >> > memoria?
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >>
> >> --
> >> Andrés Riancho
> >> Project Leader at w3af - http://w3af.org/
> >> Web Application Attack and Audit Framework
> >> Twitter: @w3af
> >> GPG: 0x93C344F3
> >> _______________________________________________
> >> 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
>
>
>
> --
> Andrés Riancho
> Project Leader at w3af - http://w3af.org/
> Web Application Attack and Audit Framework
> Twitter: @w3af
> GPG: 0x93C344F3
> _______________________________________________
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140407/f8454d2a/attachment.html>