diff options
Diffstat (limited to 'doc/administration/troubleshooting/sidekiq.md')
| -rw-r--r-- | doc/administration/troubleshooting/sidekiq.md | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md index 8d19a8a163b..297a8355036 100644 --- a/doc/administration/troubleshooting/sidekiq.md +++ b/doc/administration/troubleshooting/sidekiq.md @@ -11,7 +11,7 @@ tasks. When things go wrong it can be difficult to troubleshoot. These situations also tend to be high-pressure because a production system job queue may be filling up. Users will notice when this happens because new branches may not show up and merge requests may not be updated. The following are some -troubleshooting steps that will help you diagnose the bottleneck. +troubleshooting steps to help you diagnose the bottleneck. GitLab administrators/users should consider working through these debug steps with GitLab Support so the backtraces can be analyzed by our team. @@ -42,7 +42,7 @@ Example log output: When using [Sidekiq JSON logging](../logs.md#sidekiqlog), arguments logs are limited to a maximum size of 10 kilobytes of text; -any arguments after this limit will be discarded and replaced with a +any arguments after this limit are discarded and replaced with a single argument containing the string `"..."`. You can set `SIDEKIQ_LOG_ARGUMENTS` [environment variable](https://docs.gitlab.com/omnibus/settings/environment-variables.html) @@ -58,7 +58,7 @@ In GitLab 13.5 and earlier, set `SIDEKIQ_LOG_ARGUMENTS` to `1` to start logging ## Thread dump -Send the Sidekiq process ID the `TTIN` signal and it will output thread +Send the Sidekiq process ID the `TTIN` signal to output thread backtraces in the log file. ```shell @@ -66,7 +66,7 @@ kill -TTIN <sidekiq_pid> ``` Check in `/var/log/gitlab/sidekiq/current` or `$GITLAB_HOME/log/sidekiq.log` for -the backtrace output. The backtraces will be lengthy and generally start with +the backtrace output. The backtraces are lengthy and generally start with several `WARN` level messages. Here's an example of a single thread's backtrace: ```plaintext @@ -88,8 +88,8 @@ Move on to other troubleshooting methods if this happens. ## Process profiling with `perf` Linux has a process profiling tool called `perf` that is helpful when a certain -process is eating up a lot of CPU. If you see high CPU usage and Sidekiq won't -respond to the `TTIN` signal, this is a good next step. +process is eating up a lot of CPU. If you see high CPU usage and Sidekiq isn't +responding to the `TTIN` signal, this is a good next step. If `perf` is not installed on your system, install it with `apt-get` or `yum`: @@ -134,8 +134,8 @@ corresponding Ruby code where this is happening. `gdb` can be another effective tool for debugging Sidekiq. It gives you a little more interactive way to look at each thread and see what's causing problems. -Attaching to a process with `gdb` will suspends the normal operation -of the process (Sidekiq will not process jobs while `gdb` is attached). +Attaching to a process with `gdb` suspends the normal operation +of the process (Sidekiq does not process jobs while `gdb` is attached). Start by attaching to the Sidekiq PID: @@ -285,7 +285,7 @@ end ### Remove Sidekiq jobs for given parameters (destructive) The general method to kill jobs conditionally is the following command, which -will remove jobs that are queued but not started. Running jobs will not be killed. +removes jobs that are queued but not started. Running jobs can not be killed. ```ruby queue = Sidekiq::Queue.new('<queue name>') @@ -294,7 +294,7 @@ queue.each { |job| job.delete if <condition>} Have a look at the section below for cancelling running jobs. -In the method above, `<queue-name>` is the name of the queue that contains the job(s) you want to delete and `<condition>` will decide which jobs get deleted. +In the method above, `<queue-name>` is the name of the queue that contains the job(s) you want to delete and `<condition>` decides which jobs get deleted. Commonly, `<condition>` references the job arguments, which depend on the type of job in question. To find the arguments for a specific queue, you can have a look at the `perform` function of the related worker file, commonly found at `/app/workers/<queue-name>_worker.rb`. |