迁移至WebSphere+DB2中遇到的问题

本文记录了一个从weblogic+oracle迁移到websphere+db2的应用案例。通过调整索引及数据池、线程池大小,成功解决了高并发下数据库死锁问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

工作中需要把一个原来在weblogic+oracle的程序迁移到websphere+db2环境下。折腾了好久,在这里简单做个总结吧:
因为应用是用spring+hibernate写的,迁移的过程中没遇到任何障碍。问题发生在做性能测试的时候,发现原来在weblogic+oracle可以承受1000+并发用户的程序,现在竟然有2个并发用户也会出错!
然后就是痛苦的调试过程。出现了问题后查日志很快发现原因是数据库死锁,可是无论如何调节db2相关的一些参数,都没有什么改进。网上也有说此问题可能和db2默认的事务级别较高有关,但调整事务级别后仍然死锁。
解决问题的第一个转折出现在数据库的索引上,一开始我们按oracle的习惯,在数据量很小的时候加不加索引结果都是相似的,所以在db2上也没有加索引。不过事实证明这是错误的,在db2上增加了使用到的索引后,问题得到了显著改善,在并发用户达到100的时候,出现死锁的几率也不大。但问题仍然没有完全解决,当并发用户上升到200时,系统仍然很容易死锁掉。
后来猜测,原因是db2不能承受很高的绝对并发,那解决问题的思路就是想办法把db2的绝对并发给降下来。这样,调整了一下websphere的数据池和线程池,将最大数都降低到分别为8和10。调整后再测试,可以轻松的上500+的并发用户了,而且性能比刚才还有所提高。

这件事中得到的最大的教训就是,想要让系统承受更高的并发用户量,解决方法不一定要增加数据池和线程池的大小。有时候降低它们的值反而会得到更好的结果,具体的值应该设置为多少还是需要经过性能测试才能确定。

至于db2为什么只能承受这么低的绝对并发,还没有找到解决的办法,可能还是设置上的一些原因吧。
内容概要:该研究通过在黑龙江省某示范村进行24小时实地测试,比较了燃煤炉具自动/手动进料生物质炉具的污染物排放特征。结果显示,生物质炉具相比燃煤炉具显著降低了PM2.5、CO和SO2的排放(自动进料分别降低41.2%、54.3%、40.0%;手动进料降低35.3%、22.1%、20.0%),但NOx排放未降低甚至有所增加。研究还发现,经济性和便利性是影响生物质炉具推广的重要因素。该研究不仅提供了实际排放数据支持,还通过Python代码详细复现了排放特征比较、减排效果计算和结果可视化,进一步探讨了燃料性质、动态排放特征、碳平衡计算以及政策建议。 适合人群:从事环境科学研究的学者、政府环保部门工作人员、能源政策制定者、关注农村能源转型的社会人士。 使用场景及目标:①评估生物质炉具在农村地区的推广潜力;②为政策制定者提供科学依据,优化补贴政策;③帮助研究人员深入了解生物质炉具的排放特征和技术改进方向;④为企业研发更高效的生物质炉具提供参考。 其他说明:该研究通过大量数据分析和模拟,揭示了生物质炉具在实际应用中的优点和挑战,特别是NOx排放增加的问题。研究还提出了多项具体的技术改进方向和政策建议,如优化进料方式、提高热效率、建设本地颗粒厂等,为生物质炉具的广泛推广提供了可行路径。此外,研究还开发了一个智能政策建议生成系统,可以根据不同地区的特征定制化生成政策建议,为农村能源转型提供了有力支持。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值