Not to detract from the Rails situation because I largely agree with it, but there are also issues with Ruby's memory management, as some memory just can't be reclaimed. Rebuilding Ruby with jemalloc helped in mitigating rampant memory fragmentation for our loads and use cases, but things can only go so far regarding how things are managed. At some point the processes need recycling, so yes, most literally, regularly reaping the workers is most literally a robust way to perform an OS-level sort of GC, as in you're 100% sure it works with any reliability, and even though it may hurt some theoretical sensibilities this is a very hands-on, practical solution.

You are blaming Ruby? Plenty of major orgs running Ruby at scale aren’t resorting to restarting the server to solve memory leaks.

It is a practical hands-on solution. However it’s also bad engineering. I too have used unicorn-killer and it was always the result of trying to make bad code not crash our servers. It is a lazy hack solution that I used because it was easy and at the time didn’t know enough to fix the actual issues. I was inexperienced. No disrespect intended but with the suggestion that essentially restarting the server is a robust strategy against memory leaks, it’s kind of hard to be confident of the technical robustness of the platform, especially at scale.

I can guarantee that Github isn’t using unicorn-killer nor blaming Ruby for performance issues.

Agreed. As someone who has worked with Rails over the past 9 years, the only time unicorn-killer is generally used is to save an application from very bad engineering. That’s it. That’s the only reason to ever use it. No serious (or even not-so-serious) production app should be using unicorn-killer as a strategy. Ridiculous fail. Rather than releasing shiny new stuff, it might be wise to fix the core issues with the stability of the system first. Using New Relic or Skylight should at least help narrow down where the memory leak originates.

I know we are supposed to be “Hurray Gitlab! Open core!” but it feels like GitLab support around here is contrived and astroturffed, by GitLab insiders. Any company that actually claims unicorn killer is a robust way to handle memory leaks has some extremely incompetent technical leadership. The robust way is to not to have memory leaks! Essentially restarting your servers all the time (which is what unicorn killer practically does) is a ridiculous way to handle memory leaks.