性能分析之大屏可视化平台瓶颈分析（window版）

1、性能分析之屏可视化平台瓶颈分析版）背景运环境硬件环境服务器类型机器名配置说明应服务器WIN-8PEK4VLQU8RCPU: Inter Xeon(R) E7- 4830 2.13GHz_ HTT/CMP单元8 /8 内存:32G硬盘:300G络类型络类型宽带设备局域1000M企业级千兆交换机性能监控监控设计通过Spotlighton window收集应服务器window性能数据，采样周期7x24时不间断，系统监控期间正常运，如下图。告警分析通过对告警志（即Alarmlog）整理，我们抽样的时间段为2014/5/309:41:002014/6/6 9:39:00，这其中共产9563条告警志。通过

2、简单按严重程序排序，我们可以发现其中存在许多的严重级别的告警，如下图。9563条告警中，严重级别的告警存在195条 记录。最后，通过对严重级别告警志归纳整理，我们得出了主要以下两个问题：Pagereads/sec过且频繁（告警174次）单线程CPU Usage达到100%（告警21次） 截图如下：问题分析Page过且频繁操作系统会利磁盘较好的式提系统可内存量或者提内存的使效率Pages Read直接反应了操作系统进页交换的频度，其为解析硬页错误读取磁盘的次数，数值表是缓存读为主。我们从Spotlight中随机选择12：35的告警记录查看其内存使情况，如下是此时操作系统整体运图：我们可以从图上看

3、出，量的内存页从硬盘的件(Pagefile)调了内存，且数值达760pages/s，这说明在处理器在量的请求内存 中该部分内存，由于该部分内存从内存中删除暂存在硬盘的Pagefile，所以这个时候Windows内存管理器把量对应的内存页重新从 ）出现错误时，这就构成个PageFault，由于量的处理器请 求该部分内存，这时候就会产量的PageFaults。接下来我们查看此时间点操作系统的PageFaults情况，如下图：我们可以看见Hardfaults和Soft faults都超过5000，Hardfaults（硬错误）该页必须从硬盘上重新读取时，如果该页在内存的其他位置，该错误被称为Soft

4、faults（软错误）。许多处理器可以在有量软错误的情况下继续操作，但是硬错误可以导致明显的拖延。此数值将直很则说明此时服务器没有分配够的内存处理其作负荷，分析代码之后可以建议内存使案。因为物理内存还有量的空闲可，此时softfaults和hard faults如此之，说明应对内存的使常不合理。然后我们可以看看操作系统Pages的相关情况，如下图：Pages Input 是以解析硬页错误从磁盘读取的页数，PagesOutput指为了释放物理内存空间将页写磁盘的页数，从图上我们可以看出橙的PagesOutput乎为0，此时Pages Input达5000，这说明服务器在此时有量的换页的需求，已达

5、到每秒读取将近20M 的硬盘数据流量。此时我们来看看，此时的操作系统的CacheFaults情况，如下图：Cache Faults/sec 指在件系统缓存中找不到要寻找的页需要从内存(软错误)的其他地或从磁盘(硬错误)的其他上检索时出现的错误的速度。从上图我们可以看出此时的软、硬错误都很，都已经超过了5000。CPU处理；如果没有找到，就从速度相对慢的内 IO的时间，也使CPU处理数据 时需要等待，从造成整个服务器数据处理的时延。其表现就是整体CPU使率不，但由于内存策略使的不合理导致量出现softfaults和hard faults的出现。我们可以看出此时后台在Cache对象本的执量的 Ge

6、t和Put操作，这说明此时后台执着量的数据查询操作。接下来我们来分析下定时推送.log，通过数据统计我们得出在12：35共计执了将尽1100个展数据集推送任务，如下图在可视化系统，所有数据集在服务端会形成个与客户端、连接会话相关联个全局会话，后台服务会批量注册所有数据集的定时任 faults、hardfaults，从造成数据读取时延。其中cache中不存在的数据会从数据库重新查询数据，查询完的数据再放内存进数据计算，并将此部分数据同步更新Cache。Windows内存管理器把量对应的内存页从硬盘调内存中。当 处理器向内存指定的位置请求页出现错误时，这就构成个PageFault，由于量的处理器请

7、求数据，这时候就会产量的PageFaults，这样就会导致整个服务器数据处理的等待时延。结应对内存使的不合理，造成量的Page Faults和Cache Faults，引起服务器处理时延。单线程 CPU 100%CPU启了超线程技术，总计64个逻辑核。 我们从Spotlight中随机选择查看13：10的告警记录查看其CPU使情况，如下图：我们可以看见单个CPU在此时的CPU Usage为100%，且不是个别独的现象，是连续的出现。接下来我们查看此刻Total CPU Utilization情况，发现其平均均值较低，基本都没上10%，如下图：应不能利所有CPU从以上图中完全可以得到结论。接着查看

8、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 秒，持有的锁时间过长，那么相对地，锁的竞争程序也就越激烈。该应志具体内容截图如下：结后台应线程执推送任务的时候个别线程占锁时间过长，出现激烈的锁竞争，造成上下切换的开销，在切换周期内单个CPU使率 。瓶颈分析后台应单时间点定时推