Skip to content

The dangers of pool_max_idle_time defaulting to :infinity #309

@PragTob

Description

@PragTob

👋

As usual, thanks a ton for finch - it's been serving us well!

Over the weekend we ran into an issue where our system ran out of processes and if my analysis is correct that was due to too many HTTP pools that were never terminated. This morning in ~4hs our related finch/finch configuration made it to ~30k children. I think this because one of the end points we're adding seems to have a subdomain as part of its domain (dqX1PIrNfb81743399336.bla.woot.com) and these seem to be changing frequently. So, if for each of these (of course depends on how often we get those), we create count many new HTTP pools (which for us was ~40 which may be a bit much but see #279 ) and never terminate them we run out of processes eventually.

This brings me to a question: is the pool_max_idle_time of :infinity a good default?

And, I don't know. It's clearly somewhat dangerous (if I'm understanding it right) but for most applications it should not be dangerous - as it stands to reason that you'd only ever talk to a set number of known origins and so you wouldn't notice the explosion we've seen.

We only saw the problems we're seeing because:

  • we're acting as a fancy proxy with unknown destinations, so we'll hit more origins than the average application
  • we have that one (ok, multiple actually) destination that decides to make random strings part of their subdomain

So, in summary - I guess it's a safe default for 99.99% of users and the 0.01% should know better (that's me! 😁 ). But I think documenting that impact of this default better is worth it and I'm happy to do so. I looked at it this morning and was like "maybe that's it... nah if it was then it wouldn't be the default, I should trust the default" and too me some time to circle back around.

What do you think? :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions