3 ms·

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

by swills 8y ago

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_memory_killer.html https://docs.gitlab.com/ee/administration/operations/sidekiq...

btown 8y ago
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/sidekiq_middleware/shutdown.rb https://github.com/gitlabhq/gitlabhq/blob/master/lib/gitlab/... https://github.com/gitlabhq/gitlabhq/blob/master/config/initializers/sidekiq.rb#L15 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.
- swills 8y ago
  Sorry, you're right, I misspoke. I should have said the CE version has the work around, but it's disabled by default.
  - dblessing 8y ago
    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.
skunkworker 8y ago
Can't you use jemalloc for sidekiq? https://brandonhilkert.com/blog/reducing-sidekiq-memory-usage-with-jemalloc/ https://brandonhilkert.com/blog/reducing-sidekiq-memory-usag...
- swills 8y ago
  That doesn't help in my experience, good idea though.
- brodock 8y ago
  We are using it already in omnibus install.
q3k 8y ago
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".

by swills 8y ago

btown 8y ago

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/sidekiq_middleware/shutdown.rb https://github.com/gitlabhq/gitlabhq/blob/master/lib/gitlab/... https://github.com/gitlabhq/gitlabhq/blob/master/config/initializers/sidekiq.rb#L15 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.

swills 8y ago
Sorry, you're right, I misspoke. I should have said the CE version has the work around, but it's disabled by default.
- dblessing 8y ago
  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.

skunkworker 8y ago

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

swills 8y ago
That doesn't help in my experience, good idea though.
brodock 8y ago
We are using it already in omnibus install.

q3k 8y ago

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".