Error while reading line from the server. [tcp://10.0.0.1:6379]

[chilumb...@gmail.com]

So here is the issue; we are getting this error from predis:

    Error while reading line from the server. [tcp://10.0.0.1:6379]

And we are trying to pint point the cause of this error, and also determine whether it is an issue from the predis side, or redis cluster's side. 

Now this is what i am now considering as a potential issue. Maybe the way predis uses connections is leading to IP connection tracking on the server getting overloaded. But when i run this 

    $dmesg| grep conntrack

on the redis server, i get  [11351916.175115] nf_conntrack version 0.5.0 (16384 buckets, 65536 max). The ip_conntrack does not show that the table is full, or dropping of any packets. Would the result above still prove possible this can be causing the error above?

[Greg Andrews]

You need to start with the error report that you have, develop it, and follow where it points.

The message you have is not sufficient.  It says "Error reading line" and identifies the server, but it does not give the nature of the error.  Did predis receive a line from the server and get an error parsing it?  Was predis waiting for a reply to a command, but timed out waiting for the reply?  Was predis waiting for a reply but got an exception indicating the connection was broken?

You need a sufficient message.  That may mean increasing the verbosity of the predis logfile or your client's logfile.  Find out exactly what error it's getting and exactly what it was doing when it got the error.

Checking for a broken connection is a reasonable thing to do.  You can increase the verbosity of the Redis server log and see if it complains about unexpected disconnections.  This can give you evidence agreeing with the broken connection theory or disagreeing with it.  More evidence is better because you want to find the cause.

Get the complete report of the error from predis and see what errors the Redis server is seeing.

  -Greg

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

[chilumb...@gmail.com]

We found the cause of the problem. We had set up rdb to "save 60 100" on the node being identified in the error message, in an environment with periodic heavy bursts of writes to the redis cluster. The frequency of data persistent to disk was causing issues with the system's I/O, and also blocking clients very frequently from performing more writes while the  bgsave of the past data bursts is taking place. 

So the solution was simply to change the rdb saving mechanism to "save 3600 100000", which reduced the frequency to persist data to disk.