Skip to main content

Redis

This page collects the Redis problems reported most often on FPT Database Engine, with the symptoms that identify each one and the steps that resolve it. Use it to diagnose an incident yourself, or to gather the detail FPT Support needs.

Each entry follows the same shape: symptoms, cause, impact, then resolution.

Known issues​

Redis closes the connection unexpectedly​

Symptoms​

A client application connecting to Redis returns:

Redis error: Server closed the connection

The connection ends mid-processing. The application then times out or reconnects repeatedly.

Cause​

The Redis server closed the connection from its side. The usual causes are:

  • An unstable network between the application and Redis.
  • Redis resource exhaustion, whether CPU, memory, or connection count.
  • Incorrect connection configuration in the application.
  • A firewall or network device such as a NAT gateway or Load Balancer terminating the connection.

Impact​

  • Requests that depend on Redis for cache, session, or queue data fail.
  • Application latency rises through retries and reconnection.
  • Data not yet written to Redis is lost.
  • Overall performance degrades as the application falls back to the database or reruns logic.
  • Failures can cascade where Redis is a critical component, such as a session store or message broker.

Resolution​

Check network connectivity. Confirm the application can reach Redis:

redis-cli -h YOUR_REDIS_HOST -p YOUR_REDIS_PORT -a YOUR_REDIS_PASSWORD ping

If the reply is not PONG, the problem is network connectivity or access configuration rather than the client.

Check Redis performance. Review the monitoring dashboard, tracking CPU and memory usage, connection count, and response time. See Monitor database with FMON.

Check the client configuration. Parameter names differ across Redis clients, but confirm all four behaviors are configured:

  • Connection health check, which detects broken connections and re-establishes them. In redis-py this is health_check_interval.
  • TCP keepalive, which stops connections being closed on network or intermediary timeouts. In redis-py this is socket_keepalive.
  • Retry on timeout, which retries a request after a timeout. In redis-py this is retry_on_timeout.
  • Retry on error, which retries after a transient error such as a dropped or server-closed connection. In redis-py this is retry_on_error.

Consult your client's own documentation for exact parameter names:

Check firewalls and network devices. Where a firewall or intermediary device sits between the application Subnet and the database Subnet, review its logs for dropped or terminated connections, confirm no unusual timeout or connection limits apply, and watch the traffic for instability.

See also the Redis connection documentation.

tip

Connection pooling with keepalive enabled prevents most of these drops. Pair it with application-level retries and monitoring alerts so a transient failure never reaches your users.

Next steps​