summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAbubakar Ango <h4xx22live@gmail.com>2017-09-26 00:42:54 +0000
committerAbubakar Ango <h4xx22live@gmail.com>2017-09-26 00:42:54 +0000
commitd0f940c3a92d38f7ce1684c080f9960246fba0b6 (patch)
tree5e3c575361514c9f74773914e6543299dea9bf76
parentfc0a7ab67e37b47516e1632c971e7ef1787dfb65 (diff)
downloadgitlab-ce-abubakar-unicorn-memory.tar.gz
Updated unicorn.mdabubakar-unicorn-memory
-rw-r--r--doc/administration/operations/unicorn.md5
1 files changed, 3 insertions, 2 deletions
diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md
index e52b367be0a..25880a432be 100644
--- a/doc/administration/operations/unicorn.md
+++ b/doc/administration/operations/unicorn.md
@@ -61,12 +61,13 @@ This is a robust way to handle memory leaks: Unicorn is designed to handle
workers that 'crash' so no user requests will be dropped. The
unicorn-worker-killer gem is designed to only terminate a worker process _in
between requests_, so no user requests are affected. You can set the minimum and maximum memory threshold (in bytes) for the Unicorn worker killer by uncommenting and setting values for the following in `/etc/gitlab/gitlab.rb`:
-```
+
+```ruby
# unicorn['worker_memory_limit_min'] = "400 * 1 << 20"
# unicorn['worker_memory_limit_max'] = "650 * 1 << 20"
```
-Or by setting the `GITLAB_UNICORN_MEMORY_MIN` and `GITLAB_UNICORN_MEMORY_MIN` [environment variables](https://docs.gitlab.com/ce/administration/environment_variables.html#environment-variables).
+Or by setting the `GITLAB_UNICORN_MEMORY_MIN` and `GITLAB_UNICORN_MEMORY_MIN` [environment variables](../../environment_variables.md#environment-variables).
This is what a Unicorn worker memory restart looks like in unicorn_stderr.log.
You see that worker 4 (PID 125918) is inspecting itself and decides to exit.