summaryrefslogtreecommitdiff
path: root/doc/administration/operations/sidekiq_memory_killer.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/administration/operations/sidekiq_memory_killer.md')
-rw-r--r--doc/administration/operations/sidekiq_memory_killer.md8
1 files changed, 7 insertions, 1 deletions
diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md
index d1ff98a0079..d99468411e3 100644
--- a/doc/administration/operations/sidekiq_memory_killer.md
+++ b/doc/administration/operations/sidekiq_memory_killer.md
@@ -1,3 +1,9 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
# Sidekiq MemoryKiller
The GitLab Rails application code suffers from memory leaks. For web requests
@@ -8,7 +14,7 @@ MemoryKiller applies the same approach to the Sidekiq processes used by GitLab
to process background jobs.
Unlike puma-worker-killer, which is enabled by default for all GitLab
-installations since GitLab 13.0, the Sidekiq MemoryKiller is enabled by default
+installations of GitLab 13.0 and later, the Sidekiq MemoryKiller is enabled by default
_only_ for Omnibus packages. The reason for this is that the MemoryKiller
relies on runit to restart Sidekiq after a memory-induced shutdown and GitLab
installations from source do not all use runit or an equivalent.