diff options
Diffstat (limited to 'doc/administration/troubleshooting')
| -rw-r--r-- | doc/administration/troubleshooting/elasticsearch.md | 6 | ||||
| -rw-r--r-- | doc/administration/troubleshooting/sidekiq.md | 15 |
2 files changed, 11 insertions, 10 deletions
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md index c4a7ba01fae..13b9c30b29d 100644 --- a/doc/administration/troubleshooting/elasticsearch.md +++ b/doc/administration/troubleshooting/elasticsearch.md @@ -266,9 +266,9 @@ ElasticSearch administrator. Generally speaking, ensure: -* The ElasticSearch server **is not** running on the same node as GitLab. -* The ElasticSearch server have enough RAM and CPU cores. -* That sharding **is** being used. +- The ElasticSearch server **is not** running on the same node as GitLab. +- The ElasticSearch server have enough RAM and CPU cores. +- That sharding **is** being used. Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana). diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md index 9b016c64e29..c41edb5dbfc 100644 --- a/doc/administration/troubleshooting/sidekiq.md +++ b/doc/administration/troubleshooting/sidekiq.md @@ -96,8 +96,9 @@ 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. -> **Note:** Attaching to a process with `gdb` will suspends the normal operation - of the process (Sidekiq will not process jobs while `gdb` is attached). +NOTE: **Note:** +Attaching to a process with `gdb` will suspends the normal operation +of the process (Sidekiq will not process jobs while `gdb` is attached). Start by attaching to the Sidekiq PID: @@ -280,10 +281,10 @@ has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and > This is where the implications get interesting, and terrifying. This means that an exception can get raised: > -> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error) -> * during the cleanup for the network request -> * during a rescue block -> * while creating an object to save to the database afterwards -> * in any of your code, regardless of whether it could have possibly raised an exception before +> - during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error) +> - during the cleanup for the network request +> - during a rescue block +> - while creating an object to save to the database afterwards +> - in any of your code, regardless of whether it could have possibly raised an exception before > > Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :) |