diff options
author | Abubakar Ango <h4xx22live@gmail.com> | 2017-09-26 00:42:54 +0000 |
---|---|---|
committer | Abubakar Ango <h4xx22live@gmail.com> | 2017-09-26 00:42:54 +0000 |
commit | d0f940c3a92d38f7ce1684c080f9960246fba0b6 (patch) | |
tree | 5e3c575361514c9f74773914e6543299dea9bf76 | |
parent | fc0a7ab67e37b47516e1632c971e7ef1787dfb65 (diff) | |
download | gitlab-ce-abubakar-unicorn-memory.tar.gz |
Updated unicorn.mdabubakar-unicorn-memory
-rw-r--r-- | doc/administration/operations/unicorn.md | 5 |
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. |