运维问题分析01(12.18)

由于系统已经进入运维期间，因此前面的技术问题分析和诊断类文章修改标题为运维问题分析和诊断，对于前面分析过了OSB封装完的服务调用偶尔出现报文截断问题，暂时还没有排查出具体的结果。今天重点谈下OSB集群出现的集群节点警告，连接超时和内存溢出等问题分析诊断。

在上篇文章实际上我就谈到了，对于OSB集群在一个节点出现连接超时和内存溢出的时候，会迅速的波及到集群的其它节点，从而导致整个集群全部响应缓慢，最终还会导致整个Admin节点挂死的情况。当然如果是个别OSB集群节点出现内存溢出，集群管理器会自动对该集群节点进行重启操作而使整个集群又恢复到正常状态。

即你可能监控到OSB集群中有个别节点又惊叹号告警，但是过一段时间后所有集群几点全部恢复正常，在整个过程中你并不需要进行人为干预，集群管理器会自动进行集群状态的监测和调整，以使整个集群恢复到正常状态。

在前面的OSB集群高可用性分析中，我们就谈到集群最容易出现的问题就是内存溢出和管道破裂，使所有集群节点都出问题，从而影响到所有服务调用。导致这个问题最主要的一个原因就是出现大数据量大报文调用，同时这个调用耗时周期很长，导致报文数据读入内存后内存快速增长而无法释放，最终导致内存溢出。在前面出现过的OSB集群响应缓慢问题中，基本排除到的均是这个原因导致。

最近集群再次出现连接被占用满导致的连接超时或内存溢出问题，整体排除思路仍然是：

首先要确定具体的出现性能问题的时间区间，即究竟是在哪个时间段出现性能问题，然后再这个时间段超前推10到20分钟作为最终的问题排查时间段。时间段确认后，我们就需要进一步查看在这个时间段调用的服务详细实例日志进行分析。当前大并发服务调用情况下，基本30分钟的时间间隔也会导致出现10万次以上的服务调用，要对这些日志进行分析实际上也是比较麻烦的事情，包括10万条记录导出到Excel也需要分批次导出才行。

时间段确定后，开始分析在该时间段是否有大数据量服务调用。比如超10M或5M的大报文调用。如果有，那么进一步分析是否由于这些大报文调用导致OSB Server出现内存溢出。一个10M或20M的报文，即使没有并发，只有几次调用，如果服务调用耗时长，那么内存就无法快速释放，也会导致节点出现内存溢出。要知道，一般的报文量都在1到2k左右，1个10M的报文调用相对于10000次常规服务调用的数据量，影响还是很大。

对于大报文调用，前面也有文章专门说过，我们通过拦截器来实现了对于大报文调用的直接断流，即只有拦截到大报文输入或返回，都直接关闭连接返回异常，以快速的是否内存资源。因此，对于出现错误异常的时候，我们还需要进一步查看错误异常日志，看下是否存在大报文调用被拒绝的情况。

其次，进一步排查是否存在中等报文大并发调用，比如1M左右的报文，如果分钟级并发量在100以上，同时耗时超过5s以上，那么对整个平台的性能影响也很大。初步测算可以看到秒级并发在30次，那么5秒就达到150M的数据量，这种数据量JVM内存往往无法支撑。

如果在这个时间段根本没有出现大数据量的服务消费和调用，那么就需要进一步排查服务调用并发量和运行时长，即虽然有些服务调用数据量不大，但是服务并发量大同时运行时间长，这类服务带来的问题就是连接资源无法快速的释放，也导致内存资源无法快速释放一直堆积，最终内存溢出。

比如虽然一个服务报文量在1-2K左右，但是该服务耗时如果超过100S甚至更长，那么就会导致在100S内的所有服务请求传输的数据都积压在内存里面无法释放，从而导致最终内存溢出。同时这种场景下由于连接无法释放，连接池资源本身有限，还会导致大量请求出现连接等待的情况，即出现服务调用请求的时候连接池资源被耗尽，新请求无法得到可用连接而出现连接超时。

在最近的一次性能问题分析和排查中，我们基本也是沿用上面的思路进行问题分析和诊断，但是奇怪的是没有出现批量的大数据量调用，也没有出现批量的长耗时调用，这就导致我们很难去快速定位和分析，究竟什么原因导致了OSB集群节点连接超时或内存溢出，或者究竟是哪个服务引起的OSB集群节点资源内存溢出。

因此，对于当前出现OSB集群节点连接超时或内存溢出问题的时候，如果快速的定位到具体的根源原因才是关键，只有这样，才可能有针对性的制定管控措施。比如前期我们发现了大数据量报文调用容易导致内存溢出，我们就可以在拦截器上增加相应的控制。当前在增加了相应控制后进一步出现的这个问题，具体根源在哪里，还需要进一步分析，否则很难知道如何去管控和改进。