|
|
|
|
某EOS应用系统出现内存耗光问题的诊断报告
发布时间:2005-08-26 00:00:00 作者:cservice 出处:goComDevCenter 语言:中文 阅读次数:1075次 |
| 6月27日，下午。
针对系统出现的系统运行一段时间之后，出现数据库内存耗光的情况，与相关人等讨论解决方案。
讨论结果如下：
确定问题出现在应用服务器weblogic与数据库sqlserver之间。在之后的两三天内做以下一些测试，定位并解决问题。
1、 确认是否与当前sqlserver的“最小查询内存”的配置为1G有关；
2、 重装sqlserver数据库；
3、 换最新的sqlserver jdbc驱动；
4、 换应用服务器weblogic8.1；
讨论结束后，立即开时测试。为了加快测试速度，使用了测试工具LoadRunner进行测试。
第一次测试：将sqlserver的“最小查询内存”的配置改成2G，“最大内存”设置成256m。使用测试工具轰击测试，二十几分钟之后sqlserver数据库内存耗光。
第二次测试：换上最新的EOS升级包。问题依旧。
第三次测试：将sqlserver的“最小查询内存”的配置改成2048kb。测试三十分钟之后，数据库没有出现内存耗光现象。
第四次测试：保持sqlserver的“最小查询内存”的配置改成默认的1024kb，“最大内存”设置成512m，数据库连接池的初始化连接数改成150。在大约四十分钟之后，sqlsesrver内存耗光。
与此同时，公司的测试人员在测试环境下，将sqlserver的“最小查询内存”配置成1G，“最大内存”配置成50m，200个连接进行测试，却并没有出现sqlserver内存耗光现象。
6月28日。
检查昨天的测试结果，发现sqlserver的错误日志中记录了一个“无法为tempdb分配页”的错误信息。temdb是sqlserver的临时库，检查sqlserver的tempdb库，发现大小已经达到了3G多，而所处的磁盘剩余可用空间仅剩余8m多。
这绝对不是正常现象，怀疑是sqlserver有问题导致tempdb库没有正确释放临时数据。但将sqlserver重启之后发现tempdb库正常释放掉了临时数据，并恢复到初始大小8m。
那么接下来就需要重装一个sqlserver数据库在检验这个问题。
在同一台机器上安装了另一个sqlserver数据库实例。安装完成后，注意到sqlserver的“最小查询内存”默认的确是1024kb，至少说明之前的sqlserver配置是被修改过的。
将原sqlserver实例的数据导入到新装的 sqlserver实例中，再将EOS的数据库连接改到新安装的sqlserver实例，再重新开始测试。
配置sqlserver的“最小查询内存”的配置改成默认的1024kb，“最大内存”设置成512m，数据库连接池的初始化连接数改成150。还是在不到五十分钟测试中，新安装的sqlsesrver实例也出现了内存耗光现象。
此时也注意到新安装的sqlserver实例中的tempdb大小也同样增长到将近3G。
由此应该断定并不完全是原先的sqlserver配置有问题或者sqlserver损坏导致内存不正常耗光现象。
接下来需要换上新的sqlserver jdbc驱动来测试。
换上新的jdbc驱动，还是使用新安装的sqlserver数据库实例来测试。经过五十分钟的测试，此次数据库没有出现内存耗光现象。并注意到sqlserver的tempdb临时库大小始终保持在8m，没有变动。
换回原先的sqlserver数据库实例，并将“最大内存”改成256m，再经过五十分钟的测试，数据库同样没有出现内存耗光现象。tempdb临时库的大小也正常。
将测试时间加长到1小时30分，测试结果依然是正常。
再次将测试加长到3个小时，依然正常。
原来所使用的jdbc驱动是EOS自带的，版本比较旧，此次换上的驱动是微软最新发布的，估计是与版本有关。
6月29日。
换上新的jdbc驱动后，系统一直正常运行。
下午却发现了一个新的问题，有一个功能调用存储过程，发现返回参数没有被赋值，而换回旧的jdbc驱动，返回参数却能正常赋值。
经过测试，发现并不是每个存储过程返回参数都不能赋值，应该是与存储过程有关。
检查返回参数没有被赋值的存储过程，发现里面有返回查询结果集的处理。去掉该处的处理，存储过程返回参数果然能够正常赋值。
使用标准的java代码，不通过EOS提供的构件调用存储过程。结果是，使用新的jdbc驱动，只要存储过程中返回了结果集，返回参数就不能被赋值。这应该是因为sqlserver jdbc版本之间不兼容的问题造成的。
因为出现问题的存储中返回查询结果集的处理实际上是多余的，去掉了并没不会有影响，所以继续使用新的jdbc驱动没有问题。
6月30日。
昨日下班之前，再次开启了测试程序，定时为15小时。直至今日早上测试结束，数据库依然运行正常。
由此可以断定，数据库内存问题已经得到解决。
|
|
| 声明：本栏目转载文字、造型、样式、图形及程序如有来自网络，版权归原作者或首发媒体所有，欢迎任何个人访问或者转载，若有作者及出处有误，请来信说明，我们将及时更正。 |
|
