Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Never scaling past 1 runner #56

Open
willfore opened this issue Aug 31, 2024 · 2 comments
Open

Never scaling past 1 runner #56

willfore opened this issue Aug 31, 2024 · 2 comments

Comments

@willfore
Copy link

willfore commented Aug 31, 2024

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.

@nickdichev-firework
Copy link

I'm having similar problems with the latest changes, also using max_concurrency: 1 in my pool. What I observe though is that my pool never scales past the min config. I also observe multiple calls being assigned to a single worker, even though max_concurrency is 1.

The behavior of the pool changed in 0.4, see this PR: #54

Have you tested with 0.3? I had some successful tests on that version with max_concurrency: 1, but the scaling behavior wasn't quite right for my use case (so I implemented #51 take a look if you're curious)

@willfore
Copy link
Author

willfore commented Sep 9, 2024

I'll check those options out and I did look at your PR which would essentially solve the problem for me :) thanks for the work on that portion and for the advice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@willfore @nickdichev-firework and others