资讯专栏INFORMATION COLUMN

read error on connection的两种原因分析

0x584a / 1321人阅读

摘要:最近线上模块偶现具体报错日志如下通过分析和学习之后,发现两种原因可能导致返回执行超时使用已经断开的连接下面将对这两种情况进行具体的分析。四参考和错误排查超时问题及解决

最近线上php模块偶现 read error on connection;具体报错日志如下

 Uncaught exception "RedisException" with message "read error on connection" 

通过分析和学习之后,发现两种原因可能导致 phpredis 返回 "read error on connection":

执行超时

使用已经断开的连接

下面将对这两种情况进行具体的分析。

一、执行超时

超时又可以分两种情况:一种是客户端设置的超时时间过短导致的;另外一种是客户端未设置超时时间,但是服务端执行时间超过了默认超时时间设置。

1.1 模拟复现 1.1.1 客户端设置超时时间过短

测试环境的 get 操作 执行耗时约 0.1ms 数量级;因此客户端设置执行超时时间为0.01ms, 测试脚本如下:

pconnect("127.0.0.1", 6390);
    if ($ret == false) {
        echo "Connect return false";
        exit;
    }
    //设置超时时间为 0.1ms
    $rds->setOption(3,0.0001);
    $rds->get("aa");
} catch (Exception $e) {
    var_dump ($e);
}

手动执行该脚本会捕获"read error on connection"异常;

1.1.2 客户端未设置超时时间,使用默认超时时间

客户端未设置超时时间,但是在命令执行的过程中,超时达到php设置的默认值,详见 phpredis subscribe超时问题及解决 分析

1.2 原因分析 1.2.1 strace 分析

通过strace 查看执行过程可以发现发送 get aa 指令后,poll 想要拉取 POLLIN 事件的时候等待超时:

1.2.2 代码逻辑分析

php连接redis 使用的是phpredis扩展,在phpredis源码中全文搜索 "read error on connection" 可以发现 此错误位于 phpredis/library.c 文件的 redis_sock_gets 函数,详见 phpredis ;

phpredis 的 library.c 文件的 redis_sock_gets 函数

/*
 * Processing for variant reply types (think EVAL)
 */

PHP_REDIS_API int
redis_sock_gets(RedisSock *redis_sock, char *buf, int buf_size,
                size_t *line_size)
{
    // Handle EOF
    if(-1 == redis_check_eof(redis_sock, 0)) {
        return -1;
    }

    if(php_stream_get_line(redis_sock->stream, buf, buf_size, line_size)
                           == NULL)
    {
        char *errmsg = NULL;

        if (redis_sock->port < 0) {
            spprintf(&errmsg, 0, "read error on connection to %s", ZSTR_VAL(redis_sock->host));
        } else {
            spprintf(&errmsg, 0, "read error on connection to %s:%d", ZSTR_VAL(redis_sock->host), redis_sock->port);
        }
        // Close our socket
        redis_sock_disconnect(redis_sock, 1);

        // Throw a read error exception
        REDIS_THROW_EXCEPTION(errmsg, 0);
        efree(errmsg);
        return -1;
    }

    /* We don"t need 
 */
    *line_size-=2;
    buf[*line_size]="";

    /* Success! */
    return 0;
}

附: 这个msg 看着比线上的msg 多了 host 和 port , 是因为最近合并分支的原因,如图

从源码中可以发现如果php_stream_get_line读取stream数据为NUll的时候就会抛出read error on connection这个错误。那么什么时候php_stream_get_line会返回NULL呢, 对应于php源码的php-src/main/streams/streams.c 文件 , 详见php-src;

/* If buf == NULL, the buffer will be allocated automatically and will be of an
 * appropriate length to hold the line, regardless of the line length, memory
 * permitting */
PHPAPI char *_php_stream_get_line(php_stream *stream, char *buf, size_t maxlen,
        size_t *returned_len)
{
    size_t avail = 0;
    size_t current_buf_size = 0;
    size_t total_copied = 0;
    int grow_mode = 0;
    char *bufstart = buf;

    if (buf == NULL) {
        grow_mode = 1;
    } else if (maxlen == 0) {
        return NULL;
    }

    /*
     * If the underlying stream operations block when no new data is readable,
     * we need to take extra precautions.
     *
     * If there is buffered data available, we check for a EOL. If it exists,
     * we pass the data immediately back to the caller. This saves a call
     * to the read implementation and will not block where blocking
     * is not necessary at all.
     *
     * If the stream buffer contains more data than the caller requested,
     * we can also avoid that costly step and simply return that data.
     */

    for (;;) {
        avail = stream->writepos - stream->readpos;

        if (avail > 0) {
            size_t cpysz = 0;
            char *readptr;
            const char *eol;
            int done = 0;

            readptr = (char*)stream->readbuf + stream->readpos;
            eol = php_stream_locate_eol(stream, NULL);

            if (eol) {
                cpysz = eol - readptr + 1;
                done = 1;
            } else {
                cpysz = avail;
            }

            if (grow_mode) {
                /* allow room for a NUL. If this realloc is really a realloc
                 * (ie: second time around), we get an extra byte. In most
                 * cases, with the default chunk size of 8K, we will only
                 * incur that overhead once.  When people have lines longer
                 * than 8K, we waste 1 byte per additional 8K or so.
                 * That seems acceptable to me, to avoid making this code
                 * hard to follow */
                bufstart = erealloc(bufstart, current_buf_size + cpysz + 1);
                current_buf_size += cpysz + 1;
                buf = bufstart + total_copied;
            } else {
                if (cpysz >= maxlen - 1) {
                    cpysz = maxlen - 1;
                    done = 1;
                }
            }

            memcpy(buf, readptr, cpysz);

            stream->position += cpysz;
            stream->readpos += cpysz;
            buf += cpysz;
            maxlen -= cpysz;
            total_copied += cpysz;

            if (done) {
                break;
            }
        } else if (stream->eof) {
            break;
        } else {
            /* XXX: Should be fine to always read chunk_size */
            size_t toread;

            if (grow_mode) {
                toread = stream->chunk_size;
            } else {
                toread = maxlen - 1;
                if (toread > stream->chunk_size) {
                    toread = stream->chunk_size;
                }
            }

            php_stream_fill_read_buffer(stream, toread);

            if (stream->writepos - stream->readpos == 0) {
                break;
            }
        }
    }

    if (total_copied == 0) {
        if (grow_mode) {
            assert(bufstart == NULL);
        }
        return NULL;
    }

    buf[0] = "";
    if (returned_len) {
        *returned_len = total_copied;
    }

    return bufstart;
}

从 php_stream_get_line方法中可以看出 只有 bufstart=NULL的时候才会返回NULL,bufstart=NULL说明并未在buf缓冲和stream中接收到任何数据,包括终止符。

1.3 解决方案

客户端设置合理的超时时间,有两种方式:

1.3.1 int_set
ini_set("default_socket_timeout", -1);
1.3.2 setOption
$redis->setOption(Redis::OPT_READ_TIMEOUT, -1);

注: -1均表示不超时,也可以将超时设置为自己希望的时间, 前面复现时就是设为为0.01ms

二、重新使用已经断开的连接

使用已经断开的连接也有可能导致 "read error on connection", 这里需要区分 "Connection closed" 和 "Connection lost"。

2.1 连接断开 2.1.1 Connection closed

测试脚本如下,客户端主动关闭连接,但是下文接着使用该断开的链接,然后抛出异常返回 connection closed

pconnect("127.0.0.1", 6390);
    if ($ret == false) {
        echo "Connect return false";
        exit;
    }

    $rds->close();
    
    var_dump($rds->get("aa"));
} catch (Exception $e) {
    var_dump ($e);
}

测试结果如下:

2.1.2 Connection lost

参考Work around PHP bug of liveness checking 编写测试脚本 test.php 如下,连接上redis之后,在执行命令前kill redis 进程:

pconnect("127.0.0.1", 6390);
    if ($ret == false) {
        echo "Connect return false";
        exit;
    }

    echo "Press any key to continue ...";
    fgetc(STDIN);
    var_dump($rds->get("aa"));
} catch (Exception $e) {
    var_dump ($e);
}

如果

执行步骤如下

终端执行 php test.php 脚本

另开一个终端 kill redis 进程

第一个终端任意输入、回车

此时会出现 "Connection lost"

2.1.3 read error on connection

连接上redis之后,不断执行命令的过程中,如果连接断开,会返回 read error on connection。测试脚本如下:

pconnect("127.0.0.1", 6390);
    if ($ret == false) {
        echo "Connect return false";
        exit;
    }

    while(1){
       $rds->get("aa");
    }
    
} catch (Exception $e) {
    var_dump ($e);
}

如果

执行步骤如下

终端执行 php test.php 脚本

另开一个终端 kill redis 进程

此时抛出异常:

或者新打开终端连接上redis服务端,执行client kill ,如下:

正在执行的php脚本同样会捕获该异常read error on connection。

2.2 php-fpm & pconnect

在cli 模式下, 通过php通过 pconnect 连接redis服务端,虽然业务代码,显示调用close, 但是实际上该连接并未断开,fpm 会维护到redis 的连接,下个请求再次执行pconnect 的时候并不会真正请求redis 建立连接。这样同样会带来一个问题,假如这个连接已经断开了,下个请求可能直接使用上个断开的连接,对此,phpredis 在其源码也有注释,详见php-src

因此php-fpm reuse 一个断开的连接可能导致此类错误。

此种情况最简单的解决方案就是改长链接为短链接了

三、小结

网上有很多关于 执行超时及其解决方案的分析,但是对于连接断开重新使用的分析较少,故此分析之,一方面用作记录,另一方面希望能够给面临同样问题的小伙伴一点帮助。

四、参考

[1] redis read error on connection和Redis server went away错误排查

[2] Work around PHP bug of liveness checking

[3] phpredis subscribe超时问题及解决

[4] php-src

[5] phpredis

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/37272.html

相关文章

  • 高并发中nginx较优的配置

    摘要:指令中的参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在时间内一次没被使用,它将被移除。 一、这里的优化主要是指对nginx的配置优化,一般来说nginx配置文件中对优化比较有作用的主要有以下几项: nginx进程数,建议按照cpu数目来指定,一般跟cpu核数相同或为它的倍数。 worker_processes 8; 为每...

    马永翠 评论0 收藏0
  • 高并发中nginx较优的配置

    摘要:指令中的参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在时间内一次没被使用,它将被移除。 一、这里的优化主要是指对nginx的配置优化,一般来说nginx配置文件中对优化比较有作用的主要有以下几项: nginx进程数,建议按照cpu数目来指定,一般跟cpu核数相同或为它的倍数。 worker_processes 8; 为每...

    peixn 评论0 收藏0
  • tornado 源码分析 之 异步io的实现方式

    摘要:前言本文将尝试详细的带大家一步步走完一个异步操作从而了解是如何实现异步的其实本文是对上一篇文的实践和复习主旨在于关注异步的实现所以会忽略掉代码中的一些异常处理文字较多凑合下吧接下来只会贴出部分源码帮助理解希望有耐心的同学打开源码一起跟踪一遍 前言 本文将尝试详细的带大家一步步走完一个异步操作,从而了解tornado是如何实现异步io的. 其实本文是对[上一篇文][1]的实践和复习 主...

    xiangzhihong 评论0 收藏0
  • Nginx 中 502 和 504 错误详解

    摘要:在使用时,经常会碰到和错误,下面以来分析下这两种常见错误的原因和解决方案。错误在和中分别有这样两个配置项和。这两项都是用来配置一个脚本的最大执行时间的。此外要注意的是的模块中的和两项。 在使用Nginx时,经常会碰到 502 Bad Gateway 和 504 Gateway Time-out 错误,下面以 Nginx+PHP-FPM 来分析下这两种常见错误的原因和解决方案。 1. ...

    Lionad-Morotar 评论0 收藏0
  • tornado 源码之 iostream.py

    摘要:对进行包装,采用注册回调方式实现非阻塞。通过接口注册各个事件回调中事件发生后,调用方法,对事件进行分发。 iostream.py A utility class to write to and read from a non-blocking socket. IOStream 对 socket 进行包装,采用注册回调方式实现非阻塞。 通过接口注册各个事件回调 _read_callb...

    JeOam 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<