Never scaling past 1 runner
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 25/100
Línea de trabajo
Start by reviewing the FLAME.Pool configuration, especially max_concurrency, and the FLAME.FlyBackend settings in runtime.exs. Reproduce the behavior with roughly 30 concurrent FLAME.call invocations and debug logging enabled, then determine why additional runners are not spawned and document or fix the cause.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This could be a misunderstanding on my part but from reading all of the documentation and everything else I can get my hands on I can't figure out why my setup will not utilize more than one runner. Here is my setup
{
FLAME.Pool,
name: Demo.FlamePool,
min: 0,
max: 50,
max_concurrency: 1,
idle_shutdown_after: 30_000,
timeout: 60_000,
log: :debug
}
The backend is configured properly in my runtime.exs file and setup for using Fly as:
config :flame, FLAME.FlyBackend,
token: System.fetch_env!("FLY_API_TOKEN"),
cpu_kind: "performance",
cpus: 4,
memory_mb: 8192
I am using FLAME.call for a function that gets called around 30 times in a short period of time. These are fairly long running functions (some more than the timeout) which I have adjusted the timeout option for to accommodate this and prevent for the runner being terminated. For the life of me I can't figure out why it's only ever choosing to run the jobs on one runner and never spawns more than one. What am I missing here? Any help would be greatly appreciated.
- Lenguaje dominante
- Elixir
- Estrellas
- 1.2k
- Forks
- 68
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de phoenixframework/flame
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
phoenixframework/flame#86 · 3 reacciones ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
phoenixframework/flame#84 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
phoenixframework/flame#75 · 2 comentarios ·
-
Clean up code_sync tmp files on terminator shutdownQuizá libre de nuevo @chrismccord la tomó hace 718 días y no hay ningún pull request abierto. Abierto
phoenixframework/flame#70 · 1 asignado ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
phoenixframework/flame#66 · 1 comentario ·
Todos los issues de phoenixframework/flame
Issues similares
-
Bug: Table layout and date column are cut off on mobile screens on the Tournaments -> History pageAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
hexlet-codebattle/codebattle#2375 ·
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
wintermeyer/vutuv#2388 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
Broadcast API docs say to prepend realtime: to the topic, which breaks deliveryPosiblemente ocupada @mandar1045 la tomó hace 1 día. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
phoenixframework/phoenix_live_view#4509 ·
Los mantenedores suelen responder en 1 día