[Py-ES] Sistemas de colas

[Federico Mon]

Es un buen apunte, yo no he trabajado con procesos que consumiesen tanta RAM

On July 5, 2021 11:12:24 PM GMT+02:00, Jose Manuel <jakermater at gmail.com> wrote:
>Quería señalar que si te quedas sin RAM y el trabajo está ya lanzado, si te
>quedas sin el.
>
>Y aunque hagas try, except finally. Al ser matado por el sistema no lo
>captura ni el try ni sentry.
>
>Hablo de creación de ficheros de más de 10GB .
>
>Y lo resalto porque bueno, parece obvio cuando ya lo sabes, pero cuando no,
>te pegas de leches con los try except...
>
>El lun., 5 jul. 2021 22:41, Federico Mon <gnu.fede at gmail.com> escribió:
>
>> Yo he usado Celery (poco) y Redis Queue (algo más) y me quedo con este
>> último.
>>
>> En general, no tengo la experiencia de que se mueran los workers. Los
>> trabajos pueden fallar, si salta alguna excepción, etc, pero con un Sentry
>> o similar puedes estar al tanto.
>>
>> Creo que en tu caso sería levantar tantos workers como cores tengas, y así
>> no te excedes con los trabajos simultáneos. Quizás meterlo bajo un
>> supervisor para asegurarte de que no mueren?
>>
>> On July 5, 2021 9:30:25 PM GMT+02:00, Felipe Maza <felipe at felipem.com>
>> wrote:
>>>
>>> Hola,
>>>
>>> Llevo unos días viendo diferentes programas para gestionar sistemas de
>>> colas y, en principio, creo que casi todos parecen complejos para lo que
>>> necesito.
>>>
>>> Mi problema a resolver es el siguiente, tenemos un modelo de predicción
>>> que se ejecuta periódicamente y también bajo demanda del usuario. Ese
>>> modelo se ejecuta en un solo hilo y tarda bastantes minutos en completar la
>>> tarea. Por tanto, puedo tener varias ejecuciones simultáneas siempre que no
>>> excedamos el número de cores disponibles, ya que en ese caso se vuelve el
>>> sistema excesivamente lento. Al modelo se le invoca a través de una pequeña
>>> api hecha con flask. En el futuro puede que haya otros modelos en la
>>> misma máquina.
>>>
>>> Hace un par de años para un problema similar ya me programé mi propio
>>> gestor de colas rudimentario,pero ahora busco algo que sea estable, con
>>> pocos bugs, mantenible, etc.
>>>
>>> Las características que (creo que) necesito son:
>>> - Encolar tareas (logicamente)
>>> - Tener colas con diferente prioridad (manuales, periódicas).
>>> - Registrar la salida, tanto si ha tenido éxito como si ha tenido errores.
>>> - (opcional) En un futuro ejecutar otras apis con modelo en la misma
>>> máquina.
>>>
>>>
>>> Lo primero que he explorado ha sido Celery, y es impresionante el montón
>>> de posibilidades que ofrece, tantas que ir poco más de los ejemplos
>>> iniciales me parece muy complejo para solucionar el problema anterior. Me
>>> da la sensación que hay que controlar un montón de aspectos para montarlo y
>>> mantenerlo correctamente; y que cuando aparezca algún error no va a ser
>>> rápido dar con la solución.
>>>
>>> Después de mirar otras alternativas, con la que parece que he montado una
>>> primera versión que parece que me lo soluciona, es Redis Queue (
>>> https://python-rq.org/). La forma en la que utiliza Redis es
>>> relativamente simple, y más o menos ofrece lo que necesito.
>>> En el tema de los worker creo que ahí flojea un poco, pues parece que
>>> tendré que gestionar manualmente cuántos hay arrancados y si no se han
>>> muerto.
>>>
>>>
>>> ¿Tenéis experiencia resolviendo algún problema similar? ¿Creéis que
>>> merece la pena el esfuerzo para aprender celery (u otra solución) para
>>> algo que no debería ser muy complejo? ¿Redis os parece buen motor o
>>> debería ir a Rabbitmq? Nunca había usado ninguno de ellos. ¿Cómo
>>> gestionais el tema de los worker? Seguro que es más sencillo de lo que
>>> creo.
>>> Cualquier comentario que queráis hacer será bienvenido.
>>>
>>> Gracias,
>>>
>>> Un saludo.
>>>
>> _______________________________________________
>> Asociación Python España: http://www.es.python.org/
>> general mailing list
>> general at lists.es.python.org
>> https://lists.es.python.org/listinfo/general
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/general/attachments/20210706/87734056/attachment.htm>