业务接入瓶颈分析处理

摘要: ulimit

背景描述

最近接到业务方的反馈，接入层的用户连接数一直上不去，怀疑是不是有某方面的瓶颈，针对反馈做了一番查看。

业务结构

client -> conn_svr -> [rpc server] -> cache -> DB

整个服务的访问过程如上所示，客户端与接入层保持长链接，定时发送心跳检测，接入层到后端的功能模块通过RPC通信，通过dao层(数据模块)操作数据库。

业务数据

之前连接情况



排查过程

网络瓶颈排查

查看连接数的同时，也看了流量的监控，发现流量也是跟建立连接的情况相同，到达某个时间段时，无法再上升，但是，机器本身购买的外网带宽情况是没有限制，远远没有达到流量的限制。

open files

文件最大打开数，这个值和瓶颈数非常的接近，试着调整了这个参数，观察了周末的连接情况，发现，最大的连接数已加突破了7w以上，而且，整个连接的趋势图是一个平滑的过程，并不会像之前一样被拦腰截断。

# ulimit  -a | grep open
open files                      (-n) 65535

之后连接情况



原理描述

debian系统默认设置的open files的最大值为65535，在这个限制中对应了两种类型

-S soft limit，软限制，用户可以上调软限制到硬限制

-H ard limit, 硬限制，非 root 用户不能修改

永久性的修改这个值，通过ulimit修改只会对当前的session有效，并不会整体生效。
需要修改/etc/security/limits.conf文件

root soft nofile 100000
root hard nofile 100000

参考链接