最近在进行性能压测, 想验证一下产品的极限性能, 在使用openpower 2路22核(SMT4)176线程 512G内存的服务器上面进行性能压测
压测进行到1000并发或者是2000并发时性能有一定的衰减, 有开发确认, 数据库事务仅是比较短促的OLTP的保存操作, 耗时都比较短 ,
所以在这种情况下, 将数据库连接池的 大小 从2000逐步递减到 350 左右, 性能压测有了一定提高. 并发相应时间从7s 变成了3s 左右, 并且性能比较稳定了.
初步怀疑问题原因在于 较高连接数时 操作系统进行 线程调度时的损耗会比较大,如果设置超多的连接池数据, 并且要求数据库服务器也提高max-connections 数目, 会导致
应用后端的 jvm 内的 connection pool 出现大量的 线程切换, 影响性能, 在数据库端, 如果数据库保持较多的关于客户端的db connection 连接, 也需要进行数据库服务器层面的线程切换.
并且前端时间出现过 jvm 的crash 现象, 怀疑也是在Openpower上面的 openjdk的 jvm 到达 三四千线程之后 容易出现稳定性问题,
在这里一直有一个不太明白的事项:
springboot 里面有两个连接池 一个是为前端http服务的 tomcat http连接池, 这个连接池数量一样可能会要求比较高一些.
虽然数据库事务比较短促, 但是可能需要客户端与应用服务器保持长连接, 应用服务器也需要较长时间的分析客户请求, 访问数据库, 处理数据库返回数据, 打包传递给客户端等步骤, 这些步骤可能需要较长的时间来进行处理.
有时为了安全客户端和应用服务器端还会保持一个keepalive 的通信机制, 定期校验更换token 以保证安全.
刚才看了下 我这边 登录服务器 就产生了 7个tcp连接
可以明显看到 是一个chrome 的进程在处理相关业务
然后在服务器端可以看到有多个连接
然后一段时间不报错就会立马降为 1个 连接 时间大约为1 min
所以怀疑用户并发时可能会占用较多的http连接池.
看到这么一个数据
148 11840 okhttp3.internal.connection.RealConnection
怀疑跟这个数据有点靠近
感觉 http 连接池 比较轻量 也不会占用太多的资源
但是数据库连接池比较 狠一些 数据库需要做相关的 保持状态以及事务处理 所以不能太多
但是发现数据库连接池的大小可能大于实际的物理连接
[root@CentOS8 ~]# echo "当前数据库连接池大小为:" $(jmap -histo `jps |grep caf |awk '{print $1}'` |grep PoolEntry$ |awk '{print $2}') 当前数据库连接池大小为: 89 [root@CentOS8 ~]# lsof -i:5236 |grep 29490 |wc -l 23
这一块理解的不太清楚
只是怀疑这个http 的连接数是 okhttp的 后面再给tomcat 进行处理.
但是tomcat的连接数多少可能需要通过http-nio 才分析.
比较忙 改天再整理