Page Timeout

Hey Oliver, I’m not sure what unresponsive means, but if Redis Server is not reachable then your site won’t be either and you’ll see a friendly error message about out. Think of Redis the same as MySQL server, you need it to run WordPress.

Unless you’re seeing some odd error messages in your logs?

What “unresponsive” means is that no page is served by Apache and eventually the request times out. For reference, Apache, MySQL and Redis all exist on the same VPS server.

Deleting /wp-content/object-cache.php is the only way to resolve the issue. Restarting the VPS has no effect.

I have enabled logging on that server so we can see if there are any errors for next time and will report back.

By the way, we have seen the “friendly error message” on three servers when upgrading WordPress core to v6.3. I assume there is another bug in the plugin whereby when you update core the connection to Redis is broken and the upgrade is interrupted. It doesn’t appear to be an issue but a WordPress database update is required on the next page request which I assume is the last step in the WordPress core update procedure that was not run due to the interruption. In future we will disable Redis before running WordPress core updates. This is a separate issue though which I will raise a separate support topic about when I have a chance to test the steps to replicate.

Anyway, in the instance of this support topic … when the page requests time out, there is no friendly error. Just a generic 5xx timeout message in the browser.

I’ll update when it does it again with any errors in debug.log.

Quick update, we are actually seeing this behaviour on another server now too (10,000 rows in both wp_posts and wp_users) … very, very slow page load times until Redis has been disabled (which we have now done until we can find a permanent solution). Is it possible that Redis needs configuring on the server?

Another update … we are seeing this quite regularly in the logs …

[23-Aug-2023 08:58:20 UTC] RedisException: read error on connection to 127.0.0.1:6379 in /wp-content/object-cache.php:2161

Not sure if this is related as we cannot be certain that this co-incides with the unresponsive pages.

As mentioned above, Redis is installed on the same server. The CPUs on the server are running well … there’s 4 CPUs and the load average is 0.43, 0.57, 0.37. There’s also plenty of RAM on the server (530Mb used of 3.77Gb).

Any ideas?

Thanks for the details. Are you monitoring Redis Server?

read error on connection is a timeout, meaning Redis failed to respond. Does it have enough connection and is it’s memory pressure low?

Thanks, I’m new to Redis so please can you explain how to find out how many connections there are? With regards to memory, the server has plenty of RAM (530Mb used of 3.77Gb). Or is there a setting somewhere to delegate RAM to Redis?

If you’re new to Redis, I’d suggest using New Relic APM or a similar too to monitor the process to see what’s going on. I think Grafana has modules for Redis as well.

Why is this topic marked as resolved? It’s not resolved at all!

I’m going to look through /var/logs/redis/redis-server.log and see if I can find any issues there. I will report back here so that anyone else finding this support topic can see how the issue was resolved.

This is all that I can find in the log that looks like any kind of issue. It’s when the server was rebooted to resolve the unresponsive page requests (which didn’t resolve the unresponsive page requests).

935:M 11 Aug 2023 13:48:49.043 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
935:M 11 Aug 2023 13:48:49.043 # Server initialized
935:M 11 Aug 2023 13:48:49.043 # 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.
935:M 11 Aug 2023 13:48:49.043 # 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.

Do you recognise any of the warnings above that might cause the symptoms we are experiencing?

There is no mention of low memory or connections so I think I can rule that out, right?

Please note that the only action that resolved the unresponsive pages was to delete?/wp-content/object-cache.php Redis again in your plugin’s settings for the site to work again.

This is why we opened this support topic and why I would kindly request that this topic’s “resolved” status is removed until it is actually resolved.

Thanks.

This is an issue with your Redis Server not responding or not running.

Redis Object Cache requires Redis Server to be available, just like WordPress requires MySQL to be available.

Consider using supervisord for your redis-server process or use monitoring software, like New Relic.

Hmm. We are seeing the same issue on three different VPS servers running Ubuntu 20.04 and fresh installations of Redis. The CPUs are not loaded and there’s plenty of RAM on each virtual machine.

When we discover what the issue is I’ll update this thread … but in the meantime we’re uninstalling your Redis plugin because the sites all work better without it.

Thank you.

To update this topic, we have successfully eradicated these warnings on our VPS servers (running Ubuntu 20.04) …

935:M 11 Aug 2023 13:48:49.043 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
935:M 11 Aug 2023 13:48:49.043 # 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.
935:M 11 Aug 2023 13:48:49.043 # 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.

Unfortunately however, this is not a happy ending. After running this Redis plugin for a few days successfully, the server then started timing out page requests again and the only way we could resolve the issue was to again delete /wp-content/object-cache.php

I can understand why you might think that the issue is with our Redis server but …

1. Enabling Redis again with this plugin allows the site to render pages again no problem (the server does not need to be restarted and Redis itself doesn’t need to be restarted). All that is required is for the /wp-content/object-cache.php to be put back!
2. The server has plenty of free RAM
3. There are no errors in /var/logs/redis/redis-server.log
4. Both Apache and Redis exist on the same server so there are no connection issues

So we will once again delete this plugin but we will keep an eye on your development log to see if anything changes / is fixed in the future.

Oliver

You can try WP Redis, but I bet you’ll have the exact same issue.

I was going to try Memcached first but that’s not a bad idea. Thank you.