--- title: 分布式银行核心系统物理机并发数阈值低问题定位与解决指导-官方技术文章-鲲鹏社区 description: 某金融科技公司（下文统称开发者）的分布式银行核心系统业务部署在物理机上，压测时延、tps远低于业务部署在虚拟机时的压测性能，且并发数达到10之后，性能已达瓶颈，提高并发数无法提供性能。希望PAE协助开发者定位物理机性能差的原因。本文提供问题定位过程与解决指导。 keywords: 分布式银行核,心系统物理机,并发数阈值低,问题定位与解,决指导,官方技术文章,鲲鹏社区,项目简介 url: https://www.hikunpeng.com/developer/techArticles/20250909-1?envFlag=1 section: (其他) --- # 分布式银行核心系统物理机并发数阈值低问题定位与解决指导-官方技术文章-鲲鹏社区 URL: https://www.hikunpeng.com/developer/techArticles/20250909-1?envFlag=1 描述: 某金融科技公司（下文统称开发者）的分布式银行核心系统业务部署在物理机上，压测时延、tps远低于业务部署在虚拟机时的压测性能，且并发数达到10之后，性能已达瓶颈，提高并发数无法提供性能。希望PAE协助开发者定位物理机性能差的原因。本文提供问题定位过程与解决指导。 关键词: 分布式银行核,心系统物理机,并发数阈值低,问题定位与解,决指导,官方技术文章,鲲鹏社区,项目简介 官方技术文章 [了解详情](https://www.hikunpeng.com/zh/developer/techArticles) 分布式银行核心系统物理机并发数阈值低问题定位与解决指导 分布式银行核心系统物理机并发数阈值低问题定位与解决指导 案例分享 发表于 2025/09/09 0 作者 | 雷庆 ## 1 项目简介 某金融科技公司（下文统称开发者）的分布式银行核心系统业务部署在物理机上，压测时延、tps远低于业务部署在虚拟机时的压测性能，且并发数达到10之后，性能已达瓶颈，提高并发数无法提供性能。希望PAE协助开发者定位物理机性能差的原因。 ## 2 基础环境信息 ### 2.1 软硬件配置 所有物理机硬件配置及OS相同，所有虚拟机规格、OS一致。表2-1 物理机配置 | 服务器 | TaiShan 200 2280 | | --- | ---| | CPU | 2*7260（64cores，2.6GHz） | | 内存 | 16*32GB | | 硬盘 | SATA SSD2（2*960GB）+SATA HDD（4*10TB） | | 网卡 | 4*GE+4*10GE | | 操作系统 | Kylin V10 SP3 | 表2-2 虚拟机配置 | CPU | 32C | | --- | ---| | 内存 | 64G | | 硬盘 | 120G | | 网卡 | 与宿主机10GE网卡桥接 | | 操作系统 | Kylin V10 SP3 | ### 2.2 设备组网 xx.xx.xx.193及xx.xx.xx.194为虚拟机，其余机器皆为物理机。 #### 2.2.1 物理机环境组网 压测端在xx.xx.xx.189，注册中心（xx.xx.xx.192:8118）和网关都部署在192，和v8应用分开部署，数据库和虚拟机环境共用。 #### 2.2.2 虚拟机环境组网 压测端部署在虚拟机193，网关和业务应用部署在同一台虚拟机194，193和194的宿主机为同一台物理机188，数据库与物理机环境共用，注册中心为xx.xx.xx.192:8228。 ## 3 业务流信息 Jmeter同时起50个VUser向网关HTTP请求，网关将请求转发到业务应用，业务应用读取请求进行业务处理后，调用数据库执行对应的sql语句。压测请求为读写混合（7:3），业务应用正常会以集群方式部署，网关转发请求时会保证负载均衡，此次问题定位业务应用以单机模式部署，注册中心在网关和业务应用启动时，记录地址、端口等信息，并定期进行健康检测，不影响压测。 ## 4 问题现象 开发者在调测压测脚本时，物理机环境tps远低于虚拟机环境，提高VUser数量tps差距更加明显。图4-1 物理机环境调测数据图4-2 虚拟机环境调测数据 ## 5 定位过程 通过对比物理机和虚拟机的OS参数、内核参数、jdk版本、jvm参数、活跃连接数等配置，尝试找出导致性能差异的关键因素。由于数据库为公用，且开发者反馈网关对压测性能影响不大，因而主要对xx.xx.xx.188（应用物理机）和xx.xx.xx.194（应用虚拟机）进行对比。 ### 5.1 JDK对比 刚开始，188使用的是openJDK1.8，而194使用的是毕昇JDK1.8，将188上的JDK替换成毕昇JDK1.8后，物理机环境压测性能明显提高，与虚拟机环境基本持平。图5-1 物理机-openJDK-tps 表5-1 毕昇JDK-tps对比 | 并发VUser数 | 虚拟机环境tps/s | 物理机环境tps/s | | --- | --- | ---| | 10 | 863.2 | 821.5 | | 20 | 1546.2 | 962.0 | | 30 | 2159.2 | 931.1 | | 50 | 2991.4 | 892.6 | 替换前10并发时物理机tps/s在100左右，10并发时物理机tps与虚拟机相差较小，并发数越高，差距越大，物理机vuser数在20左右tps达到瓶颈，提高并发数，性能不再提升。 ### 5.2 操作系统对比 #### 5.2.1 OS版本对比 操作都是kylin v10 SP2。图5-2 物理机（188） 图5-3 虚拟机（194） #### 5.2.2 内核参数&&ulimit -a对比 内核参数可通过命令cat /proc/cmdline查看，物理机和虚拟机内核参数无差异，ulimit -a中pending signals参数值，物理机比虚拟机大，调节该参数与虚拟机一致后tps无变化，回退调整。图5-4 物理机图5-5 虚拟机 #### 5.2.3 OS参数对比 操作系统参数可以通过sysctl -a > os参数.txt进行查看，分别导出物理机和虚拟机的OS参数后，用VScode等编辑器打开，可以较为直观的比较二者的差异。os参数对比同步.txt内容如下所示。https://blog.csdn.net/liangdsh/article/details/51243099net.ipv4.tcp_limit_output_bytes=1048576 用于限制TCP在大量数据时，Qdisc队列（如pfifo_fast）或设备队列中的数据量net.core.dev_weight = 512 定义了每个CPU（或称为“软中断”）在处理这些数据包时可以“领取”的最大数据包数量net.core.netdev_budget=1024 增加每次软中断处理的数据包数量net.core.netdev_max_backlog=8000 指定在接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数。net.core.optmem_max=524288 每个 socket（包括 TCP/IP 头部选项、路由信息等） 可以使用的最大选项缓冲区大小（以字节为单位）net.core.rmem_default=2097152 定义了 TCP/IP 套接字接收缓冲区的默认大小（以字节为单位）net.core.rmem_max=2097152 同上net.core.somaxconn=512 控制了处于SYN_RECV状态的连接的最大数量,限制socket侦听积压net.core.wmem_default=2097152 指定了socket缓冲区（send buffer）的默认大小（以字节为单位）。这个值影响TCP连接中数据的性能net.core.wmem_max=2097152 同上ulimit -apending signals，物理机2088097 虚拟机254060tcp相关os参数net.ipv4.tcp_thin_linear_timeouts 1/0, 启用该参数，低负载场景提高连接稳定性net.ipv4.tcp_invalid_ratelimit 2000/500, 限制已有连接为了响应无效TCP报文重复ack的速率，表示重复ACK的间隔，单位是毫秒物理机多出的参数net.netfilter.nf_conntrack_tcp_be_liberal = 0 这个参数控制TCP连接的宽松跟踪模式是否启用，0表示不启用net.netfilter.nf_conntrack_tcp_loose = 1 控制TCP连接的宽松跟踪。当设置为1时，允许conntrack模块在处理TCP连接时更加灵活net.netfilter.nf_conntrack_tcp_max_retrans = 3 TCP连接重新传输的最大次数，在达到这个次数后，如果还没有收到对方的确认，连接将被认为是失败的net.netfilter.nf_conntrack_tcp_timeout_close = 10 连接在CLOSE状态下的超时时间（以秒为单位）net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 TCP连接处于CLOSE_WAIT状态时的超时时间net.netfilter.nf_conntrack_tcp_timeout_established = 432000 TCP连接处于ESTABLISHED状态时的超时时间net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 TCP连接处于FIN_WAIT状态时的超时时间。FIN_WAIT，单向，等待确认net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 当TCP连接处于LAST_ACK状态时的超时时间，等待确认时长net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 TCP连接在达到最大重传次数后，等待对方确认的超时时间net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 TCP连接处于SYN_RCVD状态时的超时时间。SYN_RCVD状态表示已经收到对方的SYN包，并了SYN-ACK包，等待对方的ACK包net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 当TCP连接处于SYN_SENT状态时的超时时间。SYN_SENT状态表示已经了SYN包，等待对方的SYN-ACK包net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 当TCP连接处于TIME_WAIT状态时的超时时间。TIME_WAIT状态表示本地连接已经net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 TCP连接在数据包后，如果没有收到对方确认的超时时间，适用于所有TCP数据包net.netfilter.nf_conntrack_timestamp = 0 是否记录conntrack条目的时间戳。当设置为0时，不记录时间戳net.netfilter.nf_conntrack_udp_timeout = 30 UDP连接在没有活动时的默认超时时间net.netfilter.nf_conntrack_udp_timeout_stream = 180 被视为流的UDP连接的超时时间表5-2 调整前后tps/s | 并发数 | 调整前 | 调整后 | | --- | --- | ---| | 10 | 831.9 | 821.5 | | 20 | 924.9 | 962.0 | | 30 | 909.6 | 931.1 | | 50 | 823.0 | 892.6 | 调整OS参数后的tps对比调整前有小幅度的性能提升，但还是远落后于虚拟机，OS参数差异不是性能差距的根因。 ### 5.3 应用对比 开发者反馈部署在虚拟机和物理机上的应用版本一致，通过比对关键jar包的MD5值可以验证，应用版本确实一致。Md5值查看方式：md5sum xxx.jar。将虚拟机上的配置文件scp到物理机，再通过如下命令进行比较。diff 虚拟机应用配置文件 物理机应用配置文件对比结果显示：应用配置文件不存在差异。 ### 5.4 调用栈时延分析 向开发者了解到压测时的入口函数为xxx.xxx.xxx.util.RestUtils execute，借助arthas分析工具，通过其trace命令和jad命令，逐步分析其耗时较长的调用栈，并与虚拟机应用中相同的方法进行调用耗时对比，若发现明显差异可让开发者排查对应方法的代码是否存在可优化点。最终未发现明显耗时差异较大的方法。 ### 5.5 资源占用分析 通过iostat、free和top等命令，发现压测时内存磁盘读写并无瓶颈，虚拟机和物理机上资源使用率都很低。但是top命令对比可以发现几个明显的差异点：1. 虚拟机比物理机多起了一个业务相关应用bootstrap。2. 物理机主业务进程占用CPU资源在5个左右，虚拟机在20个左右。针对第一个差异点，询问开发者，开发者反馈不影响压测性能，物理机环境也有bootstrap应用，只是不跟业务应用在同一台虚拟机。针对第二个差异点，通过pidstat -p {业务应用pid} -t 1 5 > thread.txt命令对比物理机和虚拟机主业务进程下的线程差异（当时未想到添加-u参数对比线程cpu资源使用情况，可以尝试一下），发现物理机多出很多XNIO-task和XNIO-I/O线程，查询资料得知与undertow默认配置有关，XNIO-I/O线程数默认为CPU核数，XNIO-task默认为8*CPU核数，调整配置文件使这两个线程配置与虚拟机一致后压测，性能无明显变化。于是对网络进行排查，通过sar -n EDEV 1命令发现无丢包错包，通过sar -n DEV 1命令发现网卡利用率都在2%以下，随后，通过netstat -na|grep ESTAB > netstat.txt命令分别对比压测，不压测和刚压测时物理机和虚拟机的活跃连接，发现压测时虚拟机比物理机多出大量活跃连接。于是通过netstat的-p参数显示pid发现，多出来的连接正是由bootstrap产生的。这与开发者说的第一条差异点不影响压测性能相矛盾。于是又在虚拟机上找到bootstrap相关的应用目录，并将其copy到物理机上，在物理机上启动它，并相应的修改jmeter的压测脚本和bootstrap的配置文件，尝试修正组网，随后重新进行测试。最终结果，50并发下物理机压测的tps达到了4000+，优于虚拟机（3000左右）。 ## 6 总结思考 1. 进行问题定位前，要先明确组网和压测时的业务流，如有不清楚的地方应及时与开发者沟通。2. 类似这种物理机与虚拟机性能存在明显差异的问题，在定位时，可以多将两套环境的资源使用情况，参数配置进行对比，寻找导致性能差异的关键gap。 本页内容