性能分析之大屏可视化平台瓶颈分析

Posted 2021-12-07 高楼（Zee）

1.  背景

大屏展示的可视化平台以交互性图像显示技术为核心，结合各业务流程、指标体系的信息化建设成果，实现了对生产与经营信息全方位集中监控和多角度的全景式信息展示，为创建高效企业管控提供了载体。

本可视化平台采用开放式框架设计，充分汲取了目前成熟的技术成果，建立了以数据服务、设计工具、播放控制、交互管理、主题场景应用为核心的平台体系，为大屏系统、桌面系统和移动终端搭建了统一的可视化部署应用。

2. 运行环境

2.1.  硬件环境

服务器类型	机器名	配置说明
应用服务器	WIN-8PEK4VLQU8R	CPU: Inter Xeon(R) E7- 4830@ 2.13GHz_ HTT/CMP单元8 /8 内存:32G 硬盘:300G

2.2. 网络环境

网络类型	宽带	设备
局域网	1000M	企业级千兆交换机

2.3. 系统架构

3. 性能监控

3.1.  监控设计

通过Spotlighton window收集应用服务器window性能数据，采样周期7x24小时不间断，系统监控期间正常运行，如下图。

4. 告警分析

通过对告警日志（即Alarmlog）整理，我们抽样的时间段为2014/5/309:41:00~2014/6/6 9:39:00，这其中共产生9563条告警日志。通过简单按严重程序排序，我们可以发现其中存在许多的严重级别的告警，如下图。

为了分析严重级别告警的类别，我们导出了相关日志并对最严重级进行了筛选整理，结果发现9563条告警中，严重级别的告警存在195条记录。

最后，通过对严重级别告警日志归纳整理，我们得出了主要以下两个方面问题：

1. Pagereads/sec过高且频繁（告警174次）

2. 单线程CPU Usage达到100%（告警21次）

截图如下：

5. 问题分析

5.1.  Page reads/sec过高且频繁

操作系统会利用磁盘较好的方式提高系统可用内存量或者提高内存的使用效率Pages Read直接反应了操作系统进行页交换的频度，其为解析硬页错误而读取磁盘的次数，小数值表示是缓存读为主。

我们从Spotlight中随机选择12：35的告警记录查看其内存使用情况，如下是此时操作系统整体运行图：

我们可以从图上看出，大量的内存页从硬盘的文件里(Pagefile)调入了内存，且数值高达760pages/s，这说明在处理器在大量的请求内存中该部分内存，由于该部分内存从内存中删除暂存在硬盘的Pagefile里面，所以这个时候Windows内存管理器把大量对应的内存页重新从硬盘调入内存中。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个PageFault，由于大量的处理器请求该部分内存，这时候就会产生大量的PageFaults。

接下来我们查看此时间点操作系统的PageFaults情况，如下图：

我们可以看见Hardfaults和Soft faults都超过5000，Hardfaults（硬错误）该页必须从硬盘上重新读取时，而如果该页在内存的其他位置，该错误被称为Softfaults（软错误）。许多处理器可以在有大量软错误的情况下继续操作，但是硬错误可以导致明显的拖延。此数值将一直很高则说明此时服务器没有分配足够的内存处理其工作负荷，分析代码之后可以建议内存使用方案。因为物理内存还有大量的空闲可用，而此时softfaults和hard faults又如此之高，说明应用对内存的使用非常不合理。

然后我们可以看看操作系统Pages的相关情况，如下图：

Pages Input 是以解析硬页面错误从磁盘读取的页数，而PagesOutput指为了释放物理内存空间而将页面写入磁盘的页数，从图上我们可以看出橙色的PagesOutput几乎为0，此时Pages Input高达5000，这说明服务器在此时有大量的换页的需求，已达到每秒读取将近20M的硬盘数据流量。

此时我们来看看，此时的操作系统的CacheFaults情况，如下图：

Cache Faults/sec 指在文件系统缓存中找不到要寻找的页而需要从内存(软错误)的其他地方或从磁盘(硬错误)的其他上检索时出现的错误的速度。从上图我们可以看出此时的软、硬错误都很高，都已经超过了5000。

正常情况下，CPU要读取一个数据时，首先从Cache中查找，如果找到就立即读取并送给CPU处理；如果没有找到，就从速度相对慢的内存或更慢的硬盘中读取并送给CPU处理。而此时我们可以看出大量的数据从内存和硬盘读取，这大大增加了IO的时间，也使CPU处理数据时需要等待，从而造成整个服务器数据处理的时延。

其表现就是整体CPU使用率不高，但由于内存策略使用的不合理导致大量出现softfaults和hard faults的出现。

接下来我们来分析下后台应用处理的系统业务的日志，通过查看visuBusiness.log，我们可以看出此时后台在Cache对象本身的执行大量的Get和Put操作，这说明此时后台执行着大量的数据查询操作。

接下来我们来分析下定时推送.log，通过数据统计我们得出在12：35共计执行了将尽1100个展示数据集推送任务，如下图

在可视化系统里面，所有数据集在服务端会形成一个与客户端、连接会话相关联一个全局会话，后台服务会批量注册所有数据集的定时任务。当大量的数据请求过来后，CPU大量从Cache里读取数据，由于部分数据不存在，需要从内存或虚拟内存(软错误)或磁盘(硬错误)上检索，此时就会造成大量的CacheFaults、soft faults、hard faults，从而造成数据读取时延。其中cache中不存在的数据会从数据库重新查询数据，查询完的数据再放至内存进行数据计算，并将此部分数据同步更新至Cache。

当CPU请求内存中数据的时候，存在硬盘的Pagefile里面，所以这个时候Windows内存管理器把大量对应的内存页从硬盘调入内存中。当处理器向内存指定的位置请求一页出现错误时，这就构成一个Page Fault，由于大量的处理器请求数据，这时候就会产生大量的PageFaults，这样就会导致整个服务器数据处理的等待时延。

5.1.1小结

应用对内存使用的不合理，造成大量的Page Faults和Cache Faults，引起服务器处理时延。

5.2. 单线程CPU Usage达到100%

通过查看系统配置，我们可以明确应用服务器CPU启用了超线程技术，总计64个逻辑核心。

我们从Spotlight中随机选择查看13：10的告警记录查看其CPU使用情况，如下图：

我们可以看见单个CPU在此时的CPU Usage为100%，且不是个别独立的现象，而是连续的出现。

接下来我们查看此刻Total CPU Utilization情况，发现其平均均值比较低，基本都没上10%，如下图：

应用不能利用所有CPU从以上图中完全可以得到结论。接着查看Total ProcessorQueue Length情况，发现 Queue Length最高不过1，不存在处理器阻塞情况，如下图：

接下来我们查看了处理器Context Switching情况，发现在此时的Context Switch值近9500，这说明后台应用线程竞争很激烈。

对于高并发程序来说，如果存在大量的CS，无疑是性能极大的打击，锁竞争最明显的现象就是增加线程上下文切换，而且这些开销都是与应用需求无关的系统开销。锁竞争导致的串行化现象对加速比指标有非常重大的影响，不论CPU核有多少，最终只有一个核在运行，加速比只有1，多核的性能只相当于单核的性能。

所以这里可以在分析业务逻辑后建议开发使用多线程异步处理的方式。

接下来，我们对后台Transmission日志进行分析，我们统计了13：10时刻的活跃线程的个数的大约为64个，如下图

通过分析threaddump，看到有互斥锁的存在，同时通过应用日志分析发现在线程New I/O server worker #2-5线程处理持有时间近20秒，持有的锁时间过长，那么相对地，锁的竞争程序也就越激烈。

该应用日志具体内容截图如下：

5.2.1小结

后台应用线程执行推送任务的时候个别线程占用锁时间过长，出现激烈的锁竞争，造成上下文切换的开销大，在切换周期内单个CPU使用率高 。

6.  瓶颈分析

1. 后台应用单时间点定时推送的数据集时在内存使用策略上不合理，导致大量空闲内存没有使用到，同时又产生了大量的faults。

2. 后台应用锁竞争激烈，线程占用锁时间过长。

3. 第一个问题的处理可以缓解第二个问题，但是切换的问题仍然需要解决。

7. 优化建议

1. 后台应用单时间点定时推送数据集时充分利用内存资源；

2. 后台程序优化，采用多线程异步处理的方式。