Predis: Error al leer la línea del servidor

¿Ya siguió los pasos que se describen aquí para depurar su problema antes de abrir un nuevo problema con el mismo título? Consulte también este hilo en la lista de Redis, también podría ser algo no relacionado con problemas del lado del cliente.

Gracias nrk. Intentaré configurar socket_timeout y read_write_timeout e informar mis hallazgos aquí más tarde.

Si está utilizando Predis en una secuencia de comandos similar a un demonio, debe establecer read_write_timeout en -1 si desea deshabilitar completamente el tiempo de espera (este valor funciona con versiones anteriores y nuevas de Predis). Además, recuerde que debe deshabilitar el tiempo de espera predeterminado de Redis configurando timeout = 0 en redis.conf o Redis

nrk, probé como se mencionó y ahora funciona perfectamente. ¡Gracias!

Sin embargo, todavía hay muchos tiempos de espera de conexión de vez en cuando. Ya configuré timeout = 0 y read_write_timeout en -1. ¿Hay algo que podamos hacer para depurar esto cuando ocurre?

timeout no es un parámetro de conexión reconocido por Predis, debe usar connection_timeout lugar. El valor predeterminado para connection_timeout es de 5 segundos, podría intentar aumentar su valor, pero no creo que sea una solución a su problema. Debería intentar ver qué está sucediendo en su servidor cuando se produzcan esos tiempos de espera, realmente depende de su aplicación, por lo que no puedo ser de ayuda. Las posibles razones de esos tiempos de espera podrían ser:

1. problemas de conectividad de red si su servidor Redis no está en el host local
2. ¿Está seguro de que no está utilizando costosas llamadas al comando KEYS en algún lugar de sus scripts? Dependiendo de la cantidad de claves almacenadas en Redis, KEYS puede terminar bloqueando el servidor que, mientras tanto, no podrá procesar otras solicitudes o conexiones entrantes.

Dejaré este problema abierto por ahora, pero estoy bastante seguro de que definitivamente no es algo relacionado con Predis.

nrk. Como se aconsejó, elevé connection_timeout a 30. Estaré monitoreando esto.

1. Sí, estamos usando varios nodos redis que no son localhost pero están en una red privada (¿al menos deberían ser más estables?)
2. No usar LLAVES. Sin embargo, estamos tomando instantáneas cada 900. Según el registro, parece que el sistema está tardando 8 segundos en guardar en HD. ¿No debería ser la causa del tiempo de espera de la conexión, verdad?
3. ¿Algún consejo sobre cómo monitorear el servidor cuando se agota el tiempo de espera? El tiempo de espera es bastante aleatorio. Revisé el registro de redis y, en su mayoría, solo se trata de instantáneas de mensajes.

Otra actualización, medí la conexión y parece que, de hecho, la excepción se produjo después de 5 segundos. Intenté modificar el connection_timeout a través de:

new Predis_Client ($ param, array ('read_write_timeout' => -1, 'connection_timeout' => 30));

¿Es eso correcto? No parece tener efecto los 30s connection_timeout y aún arroja una excepción.

Son parámetros de conexión y no opciones de cliente, por lo que read_write_timeout y connection_timeout deben especificarse como parámetros en $param .

1. A menos que no sea una red privada en Amazon EC2 (alta latencia y varios problemas de vez en cuando), entonces no debería.
2. Las instantáneas no deberían bloquear el servidor que yo sepa
3. Puede verificar los tiempos de los tiempos de espera con los registros de instantáneas. Aparte de eso, realmente depende de la arquitectura de su aplicación y su infraestructura, lo siento, pero no puedo brindarle apoyo en eso.

Honestamente, Predis no hace nada elegante con los recursos de socket cuando se conecta a un host, ya que es algo delegado casi por completo a los componentes internos de PHP, por lo que puede ser un error en PHP (poco probable, pero aún una posibilidad) o alguna configuración / tiempo de ejecución. problema en sus servidores, o Redis realizando algunas operaciones pesadas que terminan bloqueando el servidor por un tiempo.

nrk, gracias de nuevo por su respuesta. Encontré el problema, y ​​es solo que el servidor se está quedando sin problema de ip_conntrack. Una vez que se soluciona el conntrack, el tiempo de espera de la conexión también desaparece.

Es bueno saber que finalmente ha encontrado el problema real detrás de esos tiempos de espera. Probablemente agregaré esto en alguna parte de las preguntas frecuentes para brindarles a los usuarios una lista inicial de comprobaciones para solucionar problemas de tiempo de espera.

estaba obteniendo el mismo error, resuelto usando la configuración read_write_timeout como 0.
Hice eso en predis, ¿podemos hacer lo mismo con predis client?
como se muestra aquí http://code.google.com/p/dires/source/browse/trunk/predis/examples/PubSubContext.php?r=4
Estoy creando un cliente predis usando: $ redis = new Predis \ Client ("tcp: //". $ TurboConfig-> getActivitiesRedisHost ()); ¿Cómo debo pasar read_write_timeout en mi implementación?

@amitchhajer el cliente acepta los mismos parámetros de conexión con matrices con nombre o cadenas de URI, por lo que si está utilizando una cadena de URI, puede agregarla como si fuera una cadena de consulta: tcp://127.0.0.1:6379?read_write_timeout=0 .

@nrk gracias por la información, funciona bastante bien ahora.

¿Qué pasa si necesitamos cambiar read_write_timeout en tiempo de ejecución? ¿Existe algún setter para parámetros de tiempo de espera (excepto el constructor)?

Los parámetros de conexión de

$connection = $client->getConnection();
$stream = $connection->getResource();
stream_set_timeout($stream, 2);

Tenga en cuenta que hacer $connection->getResource() activa efectivamente la operación connect() en Redis, por lo que podría terminar perdiendo los beneficios de las conexiones diferidas dependiendo de cómo vaya a utilizar esta función.

Tenga en cuenta que el parámetro connection_timeout ha sido renombrado a timeout en la nueva versión de Predis.

Estoy usando 'teclas h ' bastante extensivamente. ¿Puede esto conducir a bloqueos?

Si está utilizando Predis en una secuencia de comandos similar a un demonio, debe establecer read_write_timeout en -1 si desea deshabilitar completamente el tiempo de espera (este valor funciona con versiones anteriores y nuevas de Predis). Además, recuerde que debe deshabilitar el tiempo de espera predeterminado de Redis configurando timeout = 0 en redis.conf o Redis

¿Algún inconveniente o precaución asociado con la configuración del tiempo de espera = 0 en redis.conf?

Lo que sospecho es ... ya que las conexiones nunca se caerán
La utilización de Redis seguirá siendo alta

nrk, gracias de nuevo por su respuesta. Encontré el problema, y ​​es solo que el servidor se está quedando sin problema de ip_conntrack. Una vez que se soluciona el conntrack, el tiempo de espera de la conexión también desaparece.

¿Cómo arreglar este contrato ... dónde buscar?

¿Algún inconveniente o precaución asociado con la configuración del tiempo de espera = 0 en redis.conf?

@ aditya-rewari-cb en realidad timeout = 0 en redis.conf es el valor predeterminado desde Redis 2.4 (lanzado hace unos años), así que diría que no hay inconvenientes.

Si está utilizando Predis en una secuencia de comandos similar a un demonio, debe establecer read_write_timeout en -1 si desea deshabilitar completamente el tiempo de espera (este valor funciona con versiones anteriores y nuevas de Predis). Además, recuerde que debe deshabilitar el tiempo de espera predeterminado de Redis configurando timeout = 0 en redis.conf o Redis

@nrk Estoy usando Redis con procesos de demonio (trabajadores de supervisor de laravel), así como con almacenamiento en caché regular
¿Alguna precaución al usar 'read_write_timeout' => -1?
Quería confirmar cualquier posibilidad de rotura o error ... en mi uso habitual de almacenamiento en caché de Redis, debido a este cambio.

Gracias !