《BS系统疑难问题分析与调优常见方法介绍》

BS系统疑难问题分析与调优常见方法介绍应用系统部署实施之后可能会出现一些部分功能模块不可用、系统运行缓慢、系统崩溃等莫名奇妙的问题，这些问题现象多种多样，导致问题的原因也并不相同，解决起来更是千差万别。

分析与调优的方法并不能一概而论，但也并不是毫无规律可言，掌握一些要领、思路、常用的排查手段及常见的问题解决办法有助于缩短问题解决的周期。

本文将以专题介绍及案例分析的方式对这些思路和方法做一些总结，希望能够帮助各个项目有效的排查并解决这些问题。

疑难问题分析与系统调优是件十分复杂的事情，生产环境的复杂多样决定了不可能有人能够有百分之百的把握解决所有的问题，无论是从经验、技术还是逻辑的角度来说都是这样。

因此这项工作对人员的要求就较高，为了能够帮助不太熟悉这项工作的人员尽快进入角色，以往的经验总结就显得非常重要。

因此本文永远都不会完结，仅做一个抛砖引玉，希望在以后的工作中，能够得到不断的完善。

1.要领敏锐的头脑，缜密的思维，细致的工作，广泛的联想能够帮助更好的适应这项工作。

敏锐的头脑：强调能够快速的到记忆或文档中找到匹配或近似匹配当前问题的问题。

这一点尤为重要，如果在记忆中或文档中找不到痕迹，则此问题就是一个全新的问题，而一个全新的问题对于任何人来说都是一件棘手的事情。

缜密的思维：在当前人类认知的世界中，任何事情都是有因才有果，也就是所谓的符合逻辑。

任何奇怪的现象，包括违背常识的事情，都有着其内在的原因。

因此即便是遇到严重违背常理的事情也不要慌乱，此时就需要用以往的一些经验及其他渠道，如网络、他人等查找可能的原因，然后逐一的按照逻辑进行排查。

细致的工作：这能帮助你搜集到用以定位问题的关键点，用以支持判断逻辑的证据，用以触发联想的触点，也能保证已有的环境不会被破坏或改变。

广泛的联想：基于已有的事情广泛的联想、寻找相关的事情，常常非常有助于事情的解决，也有助于将单个的、破碎的事情片段联系在一起形成一系列环环相扣的链条。

2.总体思路处理问题的总体思路如下：根据问题汇报、粗略的问题描述或一些已有的手段清晰、明确的定义问题；基于问题定义进行分析，寻找可能引发问题的原因；在某种环境下模拟、重现问题进一步确定问题原因；对于分析出的问题进行修改；对问题修改的结果进行验证。

问题定义：这个步骤十分关键，因为问题的汇报和粗略的问题描述往往并不准确，有时甚至是错误的。

因此不能过分的相信这些汇报和描述，因为不准确的问题描述会将你引上歧路，大大延缓问题的解决时间。

所以除了了解已有的问题描述外，还需要做一些相关的试验用以确定已有描述的准确性。

问题分析：基于问题定义进行分析，寻找可能引发问题的原因。

这个步骤找到的有可能不是根本原因，而且由于事情的复杂性，有可能会造成误判。

这种情况不可能避免，因此下最终的结论时要慎重。

在一些复杂的问题中可能需要与其他几个步骤一起进行迭代，才能判定问题的成因。

问题重现：重现问题有助于进一步确定问题的成因，也有助于将来问题解决后的回归测试。

是在生产环境还是测试环境下重现问题，有很多因素，但其中最重要的一个因素是这个过程是否会不可逆的改变现有的生产环境。

问题修改：对分析出的问题进行修改。

问题验证：基于修改的结果进行回归测试，验证问题是否解决。

一般来讲在条件允许的情况下，尽可能的先在测试环境下进行验证，确认无误后再在生产环境下进行验证。

切忌过分的相信自己的能力。

3.专题3.1.客户端技术在B/S系统中，传统web客户端组件及其各种变种，主要承担了界面展现及请求发送与接收的工作。

传统的web客户端组件包括：HTML，各种Script，XML，CSS等。

变种主要指随着Web2.0而新兴起的一些技术：Flash，基于脚本的RIA，各种类型的自定义控件。

这些组件或技术负责前台页面的展现，而与后台的通信一般通过HTTP协议来进行。

3.1.1.常见问题3.1.1.1.脚本性能问题描述：脚本性能问题主要在基于脚本的RIA解决方案中体现比较明显，这种解决方案为了达到良好的交互效果，大量的使用了脚本语言对页面进行渲染，由于脚本的复杂性，及浏览器的对脚本优化还不到位，经常会有一些性能问题。

解决方案：1.在满足兼容性的前提条件下，尽量升级客户端到较新版本的浏览器。

新版本的浏览器一般内部会做优化，加快HTML和脚本的解析速度。

2.换用较新版本的RIA解决方案或较快的其他RIA解决方案。

新版本的同类型RIA解决方案一般在性能方面都会有所提升。

如果最新版本的依然无法满足渲染速度的要求，只能考虑更换其他RIA解决方案。

3.更换客户机硬件配置。

RIA技术的理念是充分的利用客户机的资源进行渲染，在维持服务器压力不变、甚至降低服务器压力的情况下，给用户带来更好的交互体验。

这里的一个前提是客户机的硬件配置不错，因此如果客户机硬件配置较低，则需要考虑升级客户机硬件或者放弃使用RIA技术。

3.1.1.2.同步调用问题描述：在浏览器进行同步调用时，直到所有的同步调用都完成，页面才会展现出来。

如果其中的某个请求的响应速度较慢，则会拖累整个页面进入一种空白、假死的状态，用户体验十分不好。

解决方案：1.请求的响应较慢一般是由于中间件或数据库处理的慢而造成的，所以根本的解决办法是调整中间件、数据库或者算法，后台处理的速度上来了，前台的页面出来的也自然就快了。

2.在某些情况下，调整中间件、数据库或者算法实施成本都太高，为了快速的改善用户体验，一个重要的方案就是异步请求，将较慢的请求改成异步形式的，就可以避免一条臭鱼坏了一锅汤的结果了。

3.1.1.3.带宽占用问题描述：有些应用，特别是采用了RIA技术的应用，经常会向中间件请求大量的资源，严重的占用了网络带宽资源，无形中同时对网络和中间件资源都造成了巨大的浪费，加重了他们的负担。

解决方案：1.在客户端缓存基本不变的静态文件，减少文件的下载次数。

2.对脚本文件进行语法压缩，减小脚本文件的大小。

3.对HTTP响应开启GZIP压缩，对于文本型的资源能够有效的缩减传输的流量。

3.1.2.常用工具3.1.2.1.HttpWatchPro此工具可以将客户端发出的Http请求细节捕获出来，并记录每个请求的时间，使用这个工具可以清楚的定位究竟客户机请求了些什么资源，以及哪些资源的请求耗时最长。

3.2.中间件技术中间件即BS系统中的应用服务器，我们生产环境下最常用的就是WebLogic 系列。

中间件是Web应用程序的容器，负责接收客户端请求，进行业务逻辑处理，并最终与数据库交互完成整个过程。

因此其地位十分重要，有很多种类型的问题发生在这个层面。

3.2.1.常见问题3.2.1.1.内存配置问题描述：中间件的控制台经常出现OutOfMemory错误，则很有可能是因为部署实施时没有修改JVM的默认内存配置参数，造成可用内存过少所致。

解决方案：1.通过简单的修改JVM内存参数即可，但要注意，修改完后要进行验证，确认参数是否起作用，不要想当然。

3.2.1.2.内存溢出问题描述：如果内存参数已经修改成功，而中间件的控制台还是经常出现OutOfMemory错误，则很有可能是由于代码编写的不好，消耗内存过大所致。

解决方案：1.通过使用合适的JVM内存监控、分析工具，捕获到发生内存溢出的程序，进而修改代码解决问题。

3.2.1.3.内存泄露问题描述：如果中间件重启后的一段时间没有问题，但运行几天或更长的时间后却出现OutOfMemory错误，则很有可能是出现了内存泄露。

内存泄露和内存溢出是有很大区别的。

内存溢出通常是由于代码写的不好，程序运行消耗大量的内存，很有可能程序还没有执行完成就发生了错误，即OutOfMemory错误。

而内存泄露一般是程序执行已经完成，但是使用到的内存资源却无法释放，随着程序的不断运行，这部分不能释放的内存资源越来越多，直至最后发生内存溢出错误。

解决方案：1.内存泄露程度和排查的难易的程度成反比，即内存泄露越严重排查起来越简单，内存泄露越轻微排查起来越困难。

通过使用合适的JVM内存监控、分析工具，可以逐渐找到发生内存泄露的程序，进而修改代码解决问题。

3.2.1.4.线程配置问题描述：中间件是以线程的方式处理客户端请求的，因此线程是否够用并能有效的工作就决定了客户端的每个请求能否顺利完成。

如果线程数配置过少，客户端的请求就不能得到及时的响应，如果配置过大，又造成资源的浪费。

解决方案：1.通过修改中间件的线程相关配置可以逐渐找到适合生产系统的线程数量。

3.2.1.5.连接池配置问题描述：在业务应用程序中，不可避免的要进行数据库相关的操作，为了保证数据库连接的高效和稳定，在生产环境中一般都使用中间件自带的连接池。

数据库连接消耗数据库主机的资源，所以连接池配置过大，造成资源的浪费，配置过小，又无法满足业务应用的需要。

解决方案：1.通过修改中间件的连接池相关配置可以逐渐找到适合生产系统的连接池数量。

3.2.1.6.问题程序问题描述：这里所谓的问题程序指在JAVA程序代码中使用循环次数很多，且循环体中又带有大量操作的循环程序，这种程序是最常见的一种问题程序。

这种程序大量占用中间件的资源，可能也会大量的占用数据库资源，而且通常来讲执行速度较慢，一般都会造成比较坏的影响。

解决方案：1.通过监控工具找到这些问题程序，修改代码解决问题。

3.2.2.常用工具3.2.2.1.WebLogic控制台性能监控此工具可以方便的监控WebLogic内存及线程资源的使用情况。

内存监控包括总量及当前已用量两个值及当前已用量变化的曲线。

通过内存总量可以验证内存参数配置是否起作用。

通过总量及当前已用量可以得出剩余的内存量，对这个参数进行一段时间的采集即可判断出是否存在内存泄露。

通过当前已用量的变化曲线可以用以预估系统是否存在消耗内存资源过大的程序，通常表现为一条很陡的曲线。

通过这条曲线还可以发现所谓的问题程序，问题程序一般会表现为一条剧烈起伏的折线。

线程监控包括空闲线程数和队列长度值。

如果空闲线程数经常很小，且队列长度经常有较大的值，可能的一个原因就是线程配置的不太合适了。

3.2.2.2.WebLogic执行线程监控此工具配合上面的工具一起使用，可以详细的了解当前中间件上运行着哪些线程。

配合上面的工具可以对内存溢出、问题程序进行排查。

3.2.2.3.WebLogic连接池监控此工具可以方便的监控WebLogic连接池的使用情况。

通过对连接池运行情况的监控，可以检查连接池的最大最小连接数量配置的是否合适。

由于中间件集群的存在，连接到数据库的总连接数等于每个集群节点的连接总数*集群节点的数量。

而且由于生产环境下数据库服务器的性能有高有低，各个业务系统也不完全相同。

因此不可能将所有连接池的最小连接数都配置为一个非常大的值。