# Could sidekiq queue be reason for 500 errors?

**URL:** https://meta.discourse.org/t/could-sidekiq-queue-be-reason-for-500-errors/89631
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [June 11, 2018, 7:06pm UTC](https://meta.discourse.org/t/could-sidekiq-queue-be-reason-for-500-errors/89631 "2018-06-11T19:06:47Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![bartv](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bartv/32/130052_2.png) [@bartv](https://meta.discourse.org/u/bartv)
#### Post date: [June 13, 2018, 11:20am UTC](https://meta.discourse.org/t/could-sidekiq-queue-be-reason-for-500-errors/89631/30 "2018-06-13T11:20:19Z")

</div>

> [@danmaby](#):
>
> Please check Redis logs for details about the error.

What does the Redis log say? I had a similar issue with Redis running out of memory; the rebuild log provided the solution to this:

```plaintext
186:M 01 Jun 11:02:31.042 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
186:M 01 Jun 11:02:31.042 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

```

Perform these commands then restart your Discourse:

```plaintext
sysctl vm.overcommit_memory=1
echo never > /sys/kernel/mm/transparent_hugepage/enabled

```

Note that you’ll still need to make these persistent! (See the quoted text above to learn how)

---

_[View the full topic](https://meta.discourse.org/t/could-sidekiq-queue-be-reason-for-500-errors/89631)._