1、高并发下nginx报错
现象：在7月22号下午3点整时候，我们系统定时发送了关于报名推送，吸引了大量用户访问app，系统访问量急剧增长，qps大概在3000/s，在15:00:10至15:00:25这15秒内nginx出现了不少Resource temporarily unavailable的报错
原因：项目默认的fpm配置文件api_fpm.conf中没有设置backlog值
解决方案：在fpm.conf中加上listen.backlog = 2048后没出现Resource temporarily unavailable这个问题。backlog的定义是已连接但未进行accept处理的socket队列大小，具体解释可以参考文章。如下图
backlog设置多大跟fpm的处理能力有关，如果backlog太大了，导致fpm处理不过来，nginx那边等待超时，断开连接，报504 gateway timeout错。同时fpm处理完准备write 数据给nginx时，发现TCP连接断开了，报“Broken pipe”。如果backlog太小的话，nginx根本进入不了fpm的accept queue，报“502 Bad Gateway”错
2、支付延迟
现象：8月11号下午3点半后，部分用户支付后，没有马上在报名信息中看到支付成功的提醒，而是过了几分钟才看到支付成功
原因：第三方支付平台在用户支付成功后，通知支付中心，支付中心收到通知后更改支付订单状态为已支付，并发hydra事件通知各个业务项目订单已支付。但由于beanstalk队列中集成了错误日志收集工具sentry用于统计打点，而sentry此时的性能是不够好的，导致队列的消费worker性能变低，支付的消费队列堵塞，支付出现延迟情况sentry在付费当天的性能表现如下图，可以看到一半的错误收集接口响应时间都是大于1s的
解决方案：
从beanstalk队列中去除sentry打点的功能
只在test和online环境开启错误日志收集功能，并且重复的错误信息不发给sentry（一个异常在服务和网关中都会上报，并且会记录多条）
在sentry的client sdk中，curl_method方式从sync（同步）变为exec（后台运行），这样sdk就能立刻返回，从而不影响业务接口。
按照sentry官方文档https://docs.sentry.io/server/performance/ 进行了性能优化，包括以下几点
1.将sentry使用的redis连接方式修改为长连接
2.增加uWSGI（web server)的工作进程数量，同时修改listen为2048（socket监听队列大小，可以提高并发）
3.增加sentry的异步队列woker数量
4.自动删除7天前的数据
为方便查看sentry，将url中参数部分去掉，这样同种类型的错误会自动归类
网友评论