Update Sidekiq memory killer docs

There was some unfortunate wording on here that
I removed or rewrote.

High memory use in Sidekiq workers is not due to bugs
like memory leaks in the application, but is in the nature
of Ruby GC and also data volume processed by a job.

Changelog: changed

doc/administration/sidekiq/sidekiq_memory_killer.md

@@ -6,22 +6,12 @@ title: Reducing memory use
 ---
 
 The Sidekiq memory killer automatically manages background job processes that
-consume too much memory.
+consume too much memory. This feature monitors worker processes and restarts them before
+the Linux memory killer steps in, which allows background jobs to run to completion
+before gracefully shutting down. By logging these events, we make it easier to
+identify jobs that lead to high memory use.
 
-This feature monitors worker processes and restarts them before they crash your instance.
-Background jobs continue processing with minimal interruption.
-
-The detailed logging makes troubleshooting easier by identifying which jobs trigger
-high memory usage.
-
-## Memory management
-
-The GitLab Rails application code suffers from memory leaks. For web requests
-this problem is made manageable using a [supervision thread](../operations/puma.md#reducing-memory-use)
-that automatically restarts workers if they exceed a given resident set size (RSS) threshold
-for a certain amount of time.
-We use the same approach to the Sidekiq processes used by GitLab
-to process background jobs.
+## How we monitor Sidekiq memory
 
 GitLab monitors the available RSS limit by default only for Linux package or Docker installations. The reason for this
 is that GitLab relies on runit to restart Sidekiq after a memory-induced shutdown, and self-compiled and Helm chart