# "Your Redis network connection is performing extremely poorly"
**URL:** https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166
**Category:** Self-hosting
**Created:** [December 12, 2024, 10:26pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166 "2024-12-12T22:26:43Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [December 12, 2024, 10:26pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/1 "2024-12-12T22:26:44Z")
I am consistently getting this in the logs - with values between ~100k to ~1.35m - but the readings near 100k seem to be quite common:
`Your Redis network connection is performing extremely poorly. Last RTT readings were [97069, 103986, 98459, 100762, 381617], ideally these should be < 1000. Ensure Redis is running in the same AZ or datacenter as Sidekiq. If these values are close to 100,000, that means your Sidekiq process may be CPU-saturated; reduce your concurrency and/or see https://github.com/mperham/sidekiq/discussions/5039`
This indicates that perhaps Redis isn’t able to use enough CPU? There seems to be plenty of breathing room for CPU and ram on the server itself though.
also:
`Sidekiq is consuming too much memory (using: 3570.19M) for 'www.example.com', restarting`
This is using the all in one app.yml with Discourse stable 3.3.2.
From the app.yml:
```plaintext
UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5
```
I added this configuration to the host also:
> [@MKJ's Opinionated Discourse Deployment Configuration](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/1):
>
> ## Kernel configuration
>
> Redis (one of the key components on which Discourse is built) [strongly recommends disabling transparent huge pages when using on-disk persistence](https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages) (which Discourse does), and I also allow memory overcommit.
>
> ```plaintext
> echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
> echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
> sysctl --system
>
> ```
Sidekiq dashboard info:
It does seem like Redis is not able to surpass 1024M memory usage.
If anyone has any ideas, I’d appreciate it! :meow_heart:
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [December 19, 2024, 2:38pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/2 "2024-12-19T14:38:34Z")
To follow up with this, I’m having this same issue with `Jobs::PostAlert`:
> [@PostAlerter job hangs/OOMs as of late](https://meta.discourse.org/t/postalerter-job-hangs-ooms-as-of-late/270183):
>
> Ever since [https://github.com/discourse/discourse/commit/9cf981f1f15d3a22929003f0ca59ac2fdd28d7d4](https://github.com/discourse/discourse/commit/9cf981f1f15d3a22929003f0ca59ac2fdd28d7d4) (presumably!) we’re having Sidekiq queues fill up/OOM with stuck PostAlert jobs: Given this commit has already had a similar regression ([https://github.com/discourse/discourse/pull/22339](https://github.com/discourse/discourse/pull/22339)) it’s fairly suspect - we’ll try downgrading to a commit before the aforementioned one now though and will report back with the results.
With those jobs often going up to 15 minutes when using 4 sidekiqs with 5 (default) threads with current testing. Seems like the jobs per second speed for Sidekiq is mostly dependent on how many of those jobs are being ran simultaneously and how many threads are free for the other jobs.
Increasing Sidekiqs to 6 or higher (5 threads) will increase the queue clearing speed, but postgres will crash fairly regularly (I am guessing from too many `Jobs::PostAlert` jobs being ran simultaneously.
This is on Stable 3.3.2. The [changes and fixes](https://meta.discourse.org/t/postalerter-job-hangs-ooms-as-of-late/270183/9) from the linked thread seem to be already be implemented in 3.3.2, if I am not mistaken.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [December 19, 2024, 4:11pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/3 "2024-12-19T16:11:59Z")
> [@markersocial](#):
>
> postgres will crash fairly regularly
Postgres should never crash and generally indicates a postgres bug or some sort of larger problem.
Do you have logs?
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [December 19, 2024, 5:10pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/4 "2024-12-19T17:10:16Z")
Have you rebooted the server since making those kernel config changes?
> [@3.1.x to 3.2.0 upgrade hangs/fails on 1GB instance](https://meta.discourse.org/t/3-1-x-to-3-2-0-upgrade-hangs-fails-on-1gb-instance/293743/33):
>
> my list of standard instant diagnostics:
>
> ```plaintext
> cat /etc/lsb-release
> uptime
> df -h /
> free
> vmstat 5 5
> dmesg|egrep -i "memory|oom|kill"
> ps auxrc
>
> ```
Maybe
```plaintext
lscpu
```
would also be helpful
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [December 19, 2024, 5:21pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/5 "2024-12-19T17:21:45Z")
> [@markersocial](#):
>
> From the app.yml:
>
> ```plaintext
> UNICORN_SIDEKIQS: 9
> DISCOURSE_SIDEKIQ_WORKERS: 5
>
> ```
You should never bump `UNICORN_SIDEKIQS` that high, only increasing workers but
> [@markersocial](#):
>
> postgres will crash fairly regularly
This should never happen.
The possibilities are:
1. You are constrained on resources because either
a) Your site has over grown the server resources
b) You are misallocating resources
2. There is a bug somewhere in the stack
I’d start making
```plaintext
UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20
```
which should release some RAM from your server.
For further information you will need to run the offending jobs in a PostgreSQL console and report what is the bottleneck.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [February 16, 2026, 7:10am UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/6 "2026-02-16T07:10:20Z")
Apologies for disappearing and thank you for the responses. 🙂
I believe that the main issue for Redis being slow, was that THP was still enabled (when I had thought otherwise):
> [@MKJ's Opinionated Discourse Deployment Configuration](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/34):
>
> I think there may be an issue with the THP configuration in the wiki. I was having issues with Redis on Ubuntu: Your Redis network connection is performing extremely poorly. Last RTT readings were [96585, 101554, 97189, 99769, 94618], ideally these should be \< 1000. Ensure Redis is running in the same AZ or dat I believed that THP was already disabled (from following the wiki) - but turned out it was still enabled sweat_smile. Disabling THP ended up resolving the above for me iirc (late la…
For PG crashing, the main solution for me was adding this to the app.yml:
```plaintext
docker_args:
- "--shm-size=34g"
```
With the value set to db\_shared\_buffers + 2GB, with db\_shared\_buffers being 25% of the total host machine ram.
Overriding the default 512m:
>
>
>
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [February 16, 2026, 12:13pm UTC](https://meta.discourse.org/t/your-redis-network-connection-is-performing-extremely-poorly/342166/7 "2026-02-16T12:13:37Z")
> [@markersocial](#):
>
> For PG crashing, the main solution for me was adding this to the app.yml:
>
> ```plaintext
> docker_args:
> - "--shm-size=34g"
>
> ```
I looked back at your posting history, and I see in [Very slow Sidekiq issue … massive numbers of unread user notifications](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716) that you were running a 32 core 128 GB server, with a very large and active userbase. So in that context, I see why 34G is not such a large number! For context, though, it might be helpful (and interesting) to know the size of your setup - possibly here or even in your bio? (maybe daily and monthly active users, size of database backups, server config in RAM, swap, disk, CPUs.) Maybe even a thread where we just share our stats - large and small.