Hacker News Reader

Comment by swills | Hacker News Reader

Another performance issue is Sidekiq leaking memory, which the enterprise edition has a work around for but the community edition does not:

https://docs.gitlab.com/ee/administration/operations/sidekiq...

View on HN

It appears that the workaround is open source, though, and is loaded in the open source version?

https://github.com/gitlabhq/gitlabhq/blob/master/lib/gitlab/...

https://github.com/gitlabhq/gitlabhq/blob/master/config/init...

Many other reasons to be concerned about performance, but there's no evidence that they're withholding essential features like this from their free version.

Sorry, you're right, I misspoke. I should have said the CE version has the work around, but it's disabled by default.

The Sidekiq memory killer is enabled for both CE and EE by default with the Omnibus package. If you're seeing something different please let us know and we'll see what's going on.

Can't you use jemalloc for sidekiq? https://brandonhilkert.com/blog/reducing-sidekiq-memory-usag...

That doesn't help in my experience, good idea though.

We are using it already in omnibus install.

The fact that it's acceptable to restart sidekiq instead of working on fixing the memory leaks in the first place is a perfect example everything that's wrong with software engineering in Ruby land.

Reminds me of the classic "The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average".

Reply on news.ycombinator.com