不知大家工作中是否遇到过这样的场景：报表系统的卡顿让使用者的体验极差，而系统运维者又没有足够的线索排查......
（几分钟后......）
（然后就没有然后了）
久而久之，一次次诸如此类的问题难免会使双方关系变得紧张起来。分析矛盾时往往多站在对方的立场上看才能更加客观公正地定性问题：从报表使用者的角度来看，希望报表系统有个良好的用户体验绝对是无可非议的，那是否这场矛盾的过失全在于系统运维者这边呢？首先我们要弄清两个问题：
>>什么是卡顿？
- 卡顿表现为在感知较为明显的时间里，系统没有反应、不可交互，与宕机的区别在于影响时长、是否需强制重启等
- 通常过一段时间后即可自动恢复正常，但频繁地卡顿会给用户带来非常差的体验，因此卡顿问题应该和系统宕机同样受到重视
>>为什么不重视卡顿？
122
现在一般遇到宕机问题，较为有效的方式是在重启前导出系统的dump文件进行分析定位，理论上同样可以应用到卡顿问题的处理上。然而相比宕机而言，卡顿的发生频率要高出许多，系统运维人员没有足够的精力对所有卡顿情况都做如此精细的排查。退一步讲，咱不差钱，多招些人来看，那么还是有问题——导出dump期间系统是不可用的，就算人力跟得上，系统不可用的影响反而超过了卡顿带来的影响，得不偿失。
一般遇到卡顿问题时大家第一反应是啥？“网络不好”肯定是名列前茅的答案。不排除确实有相当比例情况肯恶搞收到网络环境影响导致前端加载的卡顿，但其实这样一个非人力可控的理由会掩盖很多问题，网络背的锅太多了。那为啥传统卡顿分析还是停留在网络环境、前端加载等浅层次分析上呢？因为缺乏支撑深入分析的数据，问题又回到了前一个导出dump的矛盾上。
上文说的“卡顿表现为在感知较为明显的时间里，系统没有反应、不可交互”，其实这个定义也有点模糊，“感知较为明显”存在感性成分较多。同一个访问需求，新入职的小白可能觉得20s内加载完毕就在可接受范围内了，但公司领导可能等待超过10s就想找信息部门谈话了。再加上系统的自身硬件条件的不同......有太多的干扰因素，导致系统运维者无法准确判断众多卡顿的严重程度，优先级的缺失让高效处理更加困难。
这么一分析，是不是觉得系统运维人员也确实有自己的苦衷呢，那是不是遇到卡顿问题就只能束手无策？先别急着砸电脑，针对以上卡顿问题及解决卡顿的痛点，云端运维正式推出“内存负载评分”功能！
>>内存负载评分如何解决以上问题 123
依托云端运维强大的数据分析处理能力，内存复杂评分功能根据GC日志自动关联模板执行情况，全部过程由云端运维分析，无需人力投入，且不影响系统正常使用
基于当前系统内存占用情况，辅以晋升量数据，综合考量系统内存负载，并且联动展示jvm内存、cpu利用率、存活会话数、系统在线人数、加载模版等，为后续分析、优化提供方向
同一报表系统内根据该时间点系统各参数对卡顿点评分，避免人为因素对衡量准确性的影响；不同系统根据其硬件配置和实时内存情况确定评分标准，具体系统具体分析，避免系统差异带来衡量标准的死板、不合理。
>>新功能请多指教
- 功能初上线，需2020-06-01后上传的云端运维报告才会有分析系统卡顿情况的功能模块（若是之前上传的可重新上传一下哦）~
- 如在过程中对内存负载评分有任何建议、意见，欢迎通过云端运维报告右上角的【功能反馈】链接提交，您的反馈我们都会认真对待哦~
编辑于 2020-6-12 10:40
| 
戏精 啊
