Para nada ha sido pedante o chapas Lasizoillo, es genial contar con comentarios tan completos y tan bien documentados, ¡gracias! :)
Nunca me había parado a mirar sobre extender Celery, y ahora ya sé por dónde empezar. Por curiosidad, ¿para qué habéis tenido la necesidad de ampliarlo? En mi caso uso Celery por los mismos motivos, ya que se adapta a las necesidades de cualquier proyecto sin necesidad de conocer todos sus requerimientos. Además, al usarlo en más proyectos, adquiero conocimiento reaprovechable. Otra ventaja es su robustez, su documentación y añadiría su monitorización. Es importante monitorizar el correcto funcionamiento de las colas, y para Celery al ser tan utilizado hay muchos recursos. Un cordial saludo: -- Nekmo. Sitio web: http://nekmo.com Dirección de contacto: conta...@nekmo.com XMPP/Jabber: conta...@nekmo.com Google+: Nekmo Com El mar, 6 jul 2021 a las 8:17, Federico Mon (<gnu.f...@gmail.com>) escribió: > 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 <jakerma...@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.f...@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 <fel...@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 >>> gene...@lists.es.python.org >>> https://lists.es.python.org/listinfo/general >>> >> _______________________________________________ > Asociación Python España: http://www.es.python.org/ > general mailing list > gene...@lists.es.python.org > https://lists.es.python.org/listinfo/general >
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es