Skip to content

Optimise `gitlab-exporter` running settings

This issue is to talk about optimising running configuration of GitLab Exporter.

Specifically we will look at jemalloc and tune it, as well as Ruby GC specific settings.

Final results

All the improvements are merged. Here is a before-after comparison. Approach: using default settings for gitlab-exporter, boot a fresh Omnibus container and run ab -c 2 -n 20 localhost:9168/metrics which polls all available probes. This was running webrick. I then took memory measurements via smem.

Omnibus 13.8.1-ee.0

root@local:/# smem -P gitlab-exporter
  PID User     Command                         Swap      USS      PSS      RSS 
  725 git      /opt/gitlab/embedded/bin/ru        0   106864   107404   116596

Omnibus 13.9.202102010906-fda84405.738441f3bc2 (jemalloc tweaks only)

root@local:/# smem -P gitlab-exporter
  PID User     Command                         Swap      USS      PSS      RSS 
 4548 git      /opt/gitlab/embedded/bin/ru        0    34376    34986    45248

Omnibus 13.9.202102010906-fda84405.738441f3bc2 (jemalloc tweaks + RUBY_GC_* tweaks)

The RUBY_GC_* settings were manually applied and are not defaults yet.

RUBY_GC_HEAP_INIT_SLOTS=80000
RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO=0.055 # 5k/90k
RUBY_GC_HEAP_FREE_SLOTS_MAX_RATIO=0.111 # 10k/90k
root@local:/# smem -P gitlab-exporter
  PID User     Command                         Swap      USS      PSS      RSS 
 1286 git      /opt/gitlab/embedded/bin/ru        0    38056    38731    49120

Result

The improvement is anywhere between 57%-61% reduction in memory use (~67-71MB). With GC tuning applied, memory use is slightly higher even, but could potentially be less spiky over time. I took a one-time measurement after the test suite finished.

If we ship things "as is", then outcome 2 would apply, i.e. jemalloc is used, but Ruby GC would use defaults.

Edited by Matthias Käppler