一、性能问题
概述
直观表现就是操作系统响应慢，包括但不限于如下场景：
1、操作界面（含浏览器、office插件界面及其调用的webbrowser界面和移动端浏览器、app）的任何按钮都可能会卡顿、甚至浏览器提示无响应；
2、打开报表慢，刷新报表慢。
分析这类性能问题，可按如下思路：
分析思路
1、确定是前端性能慢还是后端性能慢，一般通过浏览器F12和charles分析；
2、浏览器F12有脚本错误，根据脚本错误信息确定原因，考虑方向是产品或定制bug，网络拦截等原因。
3、前端慢的主要特征是网络中找不到等待很久才返回的请求，有如下方向排查：
1）前端请求数过多，在charles中可以看到有用户操作一次发送了大量请求，或者用户不操作也会频繁发送请求，一般是产品或定制bug，如果同版本不含扩展包的环境不能重现，则需要部署扩展包重现；
2）响应体数据量大导致的浏览器渲染慢，考虑是否可以调整报表设置从而减少单次请求返回的数据量，比如电子表格分组报表修改成分页显示；
3）如果修改报表设置无法减少单次请求返回的数据量，则经常是产品设计不合理，可以做数据量接近的资源重现并上报bug。
4、排除前端慢的可能后，分析后端。后端慢的主要特征是网络中请求数量不多，但是至少有一个等待很久才返回响应的请求，此时需要录制charles和cpu采样进行综合分析：
1）cpu采样能看到时间久的则可以确定是后端问题，需要区分是产品代码执行慢还是第三方代码（如jdbc驱动）等执行慢再确定优化方向；
2）cpu采样看到的时间和charles录制的时间相差较大，非websphere服务器可以查看线程cpu（smartbi/vision/monitor/listthreads.jsp）观察cpu占用率是否很高，websphere服务器查看建议直接通过操作系统自带工具或指令查看cpu占用率，以及在smartbi系统监控页面的监视tab查看已使用的堆内存是否也很高。
（1）cpu占用率高（一般持续大于80%），查看占用cpu比例高的线程是smartbi相关的线程还是jvm垃圾回收器的gc线程。
（a）cpu比例高的线程是smartbi相关的线程，一般是产品或定制bug（比如代码陷入死循环）；
（b）jvm垃圾回收器的gc线程占用cpu比例高，再去对比分析系统监控监视中查看已使用堆内存是否偏高，偏高的定义是已使用内存接近最大值：
堆内存使用高，可能是因为系统选项配置的某些单元格数、行数过多引起，或者jvm 的xmx内存配置参数过小不符合系统环境要求，或者在线用户数过多超过单节点支撑的并发数，此时需要优化配置或者增加节点；
堆内存使用不高，可能是gc算法不合理，考虑jvm参数中调整gc算法再重启测试。
（2）cpu占用率不高
（a）重录cpu采样：另外一个用户登录录制此用户会话的cpu采样，或者没有其他用户操作的时候录制全部会话的cpu采样，新录制的cpu采样如果时间较久，则又可以确定是后端问题；
（b）分析线程：在系统监控线程tab页刷新多次线程或者设置线程打印间隔时间为10s，持续观察线程文件中是否有同线程号且调用堆栈一样的线程在执行，并且线程中的某些方法是由前端请求引起的，此时可以直接根据线程中堆栈信息看调用的代码也可以大概猜测慢的原因；
（c）网络限速：录制charles，查看上传数据的时间和下载速度花费的时间，比如下载速度可以查看Response Speed和Response 的size大小，如果Response size有几MB，但是Response Speed只有几百KB/s，则一般是客户端的网络环境下载是有速度限制，需要客户自行排查限速原因，这类场景一般无法从产品或定制层面处理；
（d）网络拦截：线程中看不到同线程号且调用堆栈一样的线程在持续执行，录制的cpu采样时间明显小于实际等待网络请求等待的时间，则可能是网络、防火墙等层面存在拦截smartbi传输的加密数据等原因，访问url地址后拼接debug=true再操作对比，如果请求返回不再慢，则可以采用通用扩展包改成默认不传输加密数据。如果请求返回还是一样慢，则一般先建议客户方排查网络问题，如果排查不到网络问题且smartbi环境部署的协议是http时，可以考虑部署成https协议再对比测试。
二、宕机问题
概述
宕机的特点是宕机期间通过浏览器无法正常访问smartbi，一般分两大类，第一是java进程还在但是系统无法访问的宕机，另外一种是java进程已经消失的宕机（发生过宕机但是手动重启了应用服务器后能正常访问也是属于进程消失的宕机，因为没有保留宕机时刻的第一现场）。
因此，在分析宕机问题之前，首先最重要的就是要确认宕机的时候java进程是否还存在，这决定了后续的分析方向。
分析思路
通用思路
1、查看系统选项配置
v95以下可查看3个tab，数据集（查询设置）、 缓存和透视分析的配置，查看是否有部分数值配置的值过大，如果过大需要执行缓存的自动优化，数据集的内存数据库最大返回行数一般不建议修改，内存数据库最大返回单元格数和透视分析分析单元格上限一般参考缓存设置的最大单元格数
v97以上可查看2个tab，性能优化和高级选项，性能优化查看是否有部分数值配置的值过大，如果过大需要执行自动优化，高级选项建议把全部内容截图发回分析；
2、如果第1步自动优化的数值不符合客户场景，查看jvm参数是否有配置，有配置则要检查参数是否合理，尤其是xmx的值，无配置需要先配置一个合理的xmx值；
3、查看应用服务器路径下是否生成了内存溢出的相关文件。
java进程存在的跟踪思路
1、手动打印线程，尽量不要只打印一个线程，一般建议隔30s打印一次，打印3个左右更合适，也可以查看服务器自动打印的历史线程；
2、手动打印堆文件，也可以查看应用服务器路径下是否生成了内存溢出的相关文件；
3、分析线程和堆文件。
java进程不存在的跟踪思路
宕机后服务被手动杀死再重启的跟踪思路
1、导出系统日志，查看其中的日志、池信息、配置信息（如知识库最大连接数、jvm参数配置）和历史线程；
2、查看宕机当天的最大会话数分析报表的1分钟间隔数据，观察会话数是否很大，空闲内存是否经常很小（比如少于1000MB）；
3、查看应用服务器路径下是否生成了java进程pid文件和内存溢出相关文件；
进程自行消失后再重启的跟踪思路
1、导出系统日志，查看其中的日志、池信息、配置信息和历史线程；
2、查看应用服务器自带的日志信息；
3、查看应用服务器路径下是否生成了java进程pid文件和内存溢出相关文件；
4、查看操作系统日志，观察操作系统是否自动杀死了java进程。
