一则Oracle数据库内存管理参数设置不当的案例
原文:
自从Oracle 10g引入自动化管理内存参数特性以来,之前极度困扰DBA的sga pga参数设置问题似乎逐渐被人淡忘。 是的,理论上只要分配系统的80%左右的内存给DB,剩下的留给OS及其它应用,这是个非常不错的实践原则,也被实践所认可。 但是,计算机世界经常告诉我们的启示就是,这种自动化的智能性在某些极限的场景下常常为人误用。。。
IOT优化项目中,之前的测试环境:
32G物理内存,分给PGA 1.5G,sga_max_size=sga_target=18.8G。
从理论上讲, SGA应该是32 * 80% * 80% = 20.48G; PGA应该是32 * 80% * 20% = 5.12G
也就是说对于常见的OLTP应用,该系统的SGA值设置基本合理,PGA应该适度调大。
在测试期间发现,200个并发做select/insert操作时(读写比9:1) TPS稳定,server side表现尚且合理。
如果提高到500个并发时TPS会骤降, server side 挂掉, load 会在一分钟内达到200以上!
对于一个4CPU,32G内存的box来说,结果只能说极其的惨不忍睹。 于是在重现场景时实时监测一下系统资源,发现load骤升时cpu/io资源均表现合理,而memory达到瓶颈,需要tuning。
于是在DBA的帮助下,将PGA调大到4G,sga_max_size降为16G,sga_target降为12G,重新跑测试,一切正常。
结论1:不要迷信公式,掌握原理后,根据现象及产生的深度原因来tuning,才能正中要害
结论2:对于内网测试环境,由于测试场景众多,建议最好不要将sga_max_size和sga_target设为同一值, 生产系统自当别论:)