shvayapin

Of course the epoll_wait error is comming from nginx. The fpm does simply time out.

To exclude the option that the epoll_wait timeout is due to missing memory or cpu, we removed the container limits temporarily for the container. Also we raised the fpm pm values:

pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

Should be sufficient enough…

• This reply was modified 1 year, 7 months ago by shvayapin.

Hi @tillkruess
thank you very much for your fast response. I’m aware of that this is no standard and we’re grateful for that.

Well actually we tried this as well. None of the configurations we tried is working. Once switching to WP_REDIS_CLUSTER, we’re getting as error:

epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while reading upstream

We need to connect via tls, with user and password. Logging in into each of our nodes from the WordPress container via redis-cli works fine:

redis-cli -h xxx-0001-001.xxx.xxx.memorydb.sa-east-1.amazonaws.com --user $REDIS_USER --pass $REDIS_PASSWORD --tls

As said, the connection via WP_REDIS_HOST with the following URL once worked (so I can assume that in general all the required data arrives at the php code:

clustercfg.xxx.xxx.memorydb.sa-east-1.amazonaws.com

So I’m wondering why this leads to a connection close:

define( 'WP_REDIS_CLUSTER', [
    'tcp://xxx-0001-001.xxx.xxx.memorydb.sa-east-1.amazonaws.com:6379',
    'tcp://xxx-0001-002.xxx.xxx.memorydb.sa-east-1.amazonaws.com:6379',
    'tcp://xxx-0002-001.xxx.xxx.memorydb.sa-east-1.amazonaws.com:6379',
    'tcp://xxx-0002-002.xxx.xxx.memorydb.sa-east-1.amazonaws.com:6379',
] );

Also tried the protocols redis, rediss and tls.

Any idea how to continue from here?