专栏首页云加头条CDB 的控制台的超时雪崩问题
原创

CDB 的控制台的超时雪崩问题

作者:蒋鹏

问题结论

由于web接入层在调用后方逻辑层接口,使用的调用方法concurrent_curl没有设置超时(默认200s),会由于后台单点故障,导致调用没返回而一直等待,引发雪崩,使web接入层的php也被占满未释放空闲,导致所有cdb的web控制台服务都不可访问。

问题场景

近日,测试同学 R 反馈整个测试环境,CDB的相关页面都不能访问了,实在找不到问题原因。表现如下:

1、三套cdb的测试环境都拉取不出页面,页面一直弹登录框,登录态校验失败。

2、做账户的登录态、用户信息校验等,校验接口大概率超时。

3、浏览器抓包,发现许多cgi请求一直处于pending状态。

问题分析过程

1、3套环境都这样,首先考虑是机器底层网络有问题?

-----通过与其他FT的测试环境运行情况,发现就只有CDB的环境这样,排除一种可能。

2、页面一直弹登录框,首先需要定位登录校验失败问题,难道是官网组件运行异常?

-----同样查看其他ft的环境,是否有登录的问题存在,发现不存在问题。那么排查CDB的环境是否连接鉴权的地址不正确?环境不通?

首先解决鉴权失败问题:

[2017-07-26 09:37:37,139][21563][ERROR][/data/release/websites/cdb.qcloud.com/module/helpers/common_helper.php:http_curl:162][curl_e
xec error|url=http://cgateway.qcloud.itd.com/interfaces/interface.php|request='{"regionId":"1","version":1,"componentName":"MC_CDB",
"eventId":1570119608,"seqId":"205b990c-4755-5fc4-5f9b-5977f2a2b680","spanId":"http:\\/\\/cdb.qcloud.com\\/cdb->http:\\/\\/cdb.qcloud
.com\\/cdb\\/getlist;1","interface":{"interfaceName":"qcloud.Qconfig.batchGetWhiteList","para":{"typeList":["CDB_CAM_USER_LIST"],"wh
iteList":["3227991405"]},"common":{"regionId":"1","appId":0,"uin":0,"ownerUin":0}}}'|timeout=6|error=Operation timed out after 6000
milliseconds with 0 bytes received]

*通过日志发现,鉴权相关接口出现超时, timeout=6|error=Operation timed out after 6000milliseconds with 0 bytes received

提取请求单独curl测试,发现请求一直不返回,那么我们往后端继续定位,发现被请求组件cgw的日志展示,鉴权的接口是正常处理,没有失败的情况。

mc:我发起请求正常 ——————————cgw:我处理请求也是正常,内部没有超时

这时候,问题的关键点就在mc到cgw之间了,他们直接的距离就是nginx+php,由于经验nginx的转发能力是很强大的,这里考虑php慢,结合定位cgw的日志,cgw逻辑耗时正常,这里考虑php的进程占用满了。

1、看php进程数量

2、查看/usr/local/services/php-fpm-5.6.30/etc/php-fpm.conf中max_children

3、该问题场景,两者数量相等,于是考虑php的进程占满。

尝试解决php问题,重启下php,刷新页面,出现下面情况:

页面可以正常刷新出来,多次刷新后,又陷入了大量超时失败,浏览器请求pending。

判断php重启不是根本办法,要定位出具体的是什么导致了线程急速耗费完。

于是我就去看ngnix 的请求处理日志了(要看nginx所有的请求日志):

 /usr/local/services/tnginx_1_0_0-1.0/log]# tail -f * -n 0

通过tail发现打印内容很久才会有一条,这里我们要知道一点:

nginx是在php处理返回后,返回内容给请求端时候才会打印请求的日志。

于是修改nginx的日志打印规则,看看请求具体耗用时间,设置规则参考nginx日志规则配置。通过在access_log中查询‘request_time 2’、‘request_time 1’等看看超过1s的请求处理。得到了如下的情况:

有请求耗时达到了200s,浏览器的请求也在200s后返回,这里需要从代码角度考虑,有哪些场景可能导致耗时很长:

1、代码中可能存在大的循环。

2、代码中出现阻塞,一直等待。

通过在代码中打桩,插入return语句,发现在如下的concurrent_curl函数前后打桩,浏览器分别会正常返回或者一直pending,所以考虑是这个函数的问题。

通过代码调用实现中,没有看到关于time_out的设置,而使用了默认的超时时间,并与研发对齐,的确是没有超时设置。初步定位到由于这里没有超时,而有一些php逻辑一直在等待后台返回,导致了web接入层机器的php进程耗用完。

这里又有问题了,什么情况导致concurrent_curl一直等待未返回,用同样上面方法了解,有一台逻辑层cgw组件机器,php也耗用满了,导致web接入层请求逻辑层cgw一直waiting,nginx没有返回。这样由于一台机器的问题,而影响到web接入层,从而扩散CDB控制台所有用户都不能使用。

补充问题1:nginx为何没有返回?

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SERVER_NAME $http_host;
fastcgi_ignore_client_abort on;
fastcgi_connect_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
}

nginx配置代理转发,cgi超时时间是10分钟,大于我们concurrent_curl的200s而没有出错。

补充问题2:在定位过程中,多次点击列表拉取按钮,每次会触发两个cgi访问,其中一个会pending,当点击到第六次后,两个cgi都会pending,场景必现。

第一次刷新
request A   返回200
request B   pengding
第二次刷新
request A   返回200
request B   pengding
第三次刷新
request A   返回200
request B   pengding
第四次刷新
request A   返回200
request B   pengding
第五次刷新
request A   返回200
request B   pengding
第六次刷新
request A   pengding
request B   pengding

这个主要是浏览器本身限制了单域名的连接个数,定位环境使用chrome,限制个数为6个连接。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 智能云上手指南:如何使用腾讯云开放的图片鉴黄能力?

    今天,腾讯云发布2017战略新品——智能云,对于普通开发者而言,现在可以通过腾讯云开发者实验室0门槛体验优图鉴黄等AI能力。

    云加社区
  • 轻松入门腾讯云存储系列一:对象存储COS的基本功能详解

    腾讯云是全球领先的云计算服务商之一,将腾讯集团在QQ、微信、QQ空间等业务中积累的海量互联网服务能力,开放给各行各业,并不断输出计算机视觉、智能语音、大数据分...

    云加社区
  • 云+社区外部运营团队招募开启!

    云+社区是一个开放型技术社区,同时也作为连接用户与腾讯云产品、服务、技术的平台。外部运营团成立的初衷是为对云计算感兴趣并热爱技术的你提供一个最适合的平台。如果你...

    云加社区
  • [讨论]为什么要使用docker和docker-compose

    docker是容器型虚拟化,不需要进行硬件虚拟、运行完整操作系统等额外的开销。所以提高了对系统资源的利用率

    宣言言言
  • CentOS 7.5 + PHP 5.6.36 + Nginx 1.14.0 配置笔记

    Nginx 配置文件主要分成四部分:main(全局设置)、server(主机设置)、upstream(上游服务器设置,主要为反向代理、负载均衡相关配置)和 lo...

    赵达
  • 教你编译PHP7 (nginx+mysql+php7)

    操作系统: CentOS Linux, 6.5 64位 服务器: 阿里云 空的操作系统,我们从0开始. 在开始前,请确保你的Linux已联网,已联网,已...

    lilugirl
  • 剑指OFFER之矩形覆盖(九度OJ1390)

    题目描述: 我们可以用2*1的小矩形横着或者竖着去覆盖更大的矩形。请问用n个2*1的小矩形无重叠地覆盖一个2*n的大矩形,总共有多少种方法? 输入: 输入可能包...

    用户1154259
  • Spring Boot构建RESTful API与单元测试

    首先,回顾并详细说明一下在快速入门中使用的 @Controller、 @RestController、 @RequestMapping注解。如果您对Spring...

    程序猿DD
  • xhprof使用说明

    if (mt_rand(1, 10000) == 1) { //采集请求的万分之一 //xhprof_enable(XHPROF_FLAGS_MEMOR...

    苦咖啡
  • [系列] - go-gin-api 路由中间件 - 日志记录(三)

    上篇文章分享了,规划项目目录和参数验证,其中参数验证使用的是 validator.v8 版本,现已更新到 validator.v9 版本,最新代码查看 gith...

    新亮

扫码关注云+社区

领取腾讯云代金券