Possible memory leak issues in Puma.

[ozzyjohnson]

@GUI dropped a link about this the other day.

puma/puma#342

Today two instances crept over their limits - see cf events for details. The result is a spike in response time as the new droplet launches. The average doesn't look bad, but ~1% will be a multiple of that.

For the meantime, I'll see about cycling instances preemptively to keep this predictable.

[GUI]

Just for reference, when I hit this problem on other apps, I ended up adding a cronjob to periodically run pumactl restart on my app. It's certainly not ideal, but it should be a zero-downtime operation (although, there may be some brief pauses depending on whether your using hot or phased restarts). The puma_worker_killer gem referenced in that issue seems like it might do something similar, but integrated into the app (instead of cron). Or if it's easier for you to manage this on the CF side of thing, that might be better.

Unfortunately, I never had time to do a deep-dive into some of my apps to see if I could pinpoint the real issue that was causing memory growth, but based on that long-running issue we're at least not alone. So hopefully it will be fixed some day, but in the meantime, even with the hacky periodic restarts, the scalability benefits of Puma over other options has been a net win for most of my apps.

[ozzyjohnson]

Thanks @GUI.

I'm liking the look of puma_worker_killer, more granular than handling things in CF.

[yozlet]

Here's a direct link to the gem: https://github.com/schneems/puma_worker_killer