Heim  >  Artikel  >  Datenbank  >  IBM小机+ORACLE数据库迅猛提升事物数TPS的方法总结

IBM小机+ORACLE数据库迅猛提升事物数TPS的方法总结

WBOY
WBOYOriginal
2016-06-07 17:41:181334Durchsuche

IBM小机+ORACLE数据库迅猛提升事物数TPS的方法总结:近期一直在搞业务压测,提升系统的事务处理能力。事务处理量从刚开始的三千到如今的接近一万,也积累了一些

      IBM小机+ORACLE数据库迅猛提升事物数TPS的方法总结:近期一直在搞业务压测,提升系统的事务处理能力。事务处理量从刚开始的三千到如今的接近一万,也积累了一些优化方法,分享给各位。首先当然需要你的系统是处理大并发事务的,如果你的系统每秒TPS才一两百,香港服务器,可能事务优化并不是主要的目的。这里一共包含两个部分的优化手段,第一部分是常规的优化手段,第二部分是稍微“邪门”点的优化手段。

大并发事务常规的优化手段:

1)REDO LOG 盘优化:如果是放在存储,可以多拿出几块盘来做LOG 盘,最基本的常识盘要做成RAID 10,不能放RAID 5。根据你盘的情况,可以用6-12块盘不等。这些 盘专门提供给REDO LOG用,剩余的空间也不能提供给其他盘用,以免影响LOG 盘的IO。由于存储一般都带有CACHE,CACHE的大小根据高低中端的不同,网站空间,存储型号的不同而不同,存储的CACHE可以说是存储的灵魂,对于写缓冲的效果非常明显,极大的降低写LOG盘的时间。

2)数据盘的IO要根据你系统的情况来,根据操作系统工具topas -D或iostat -DlRa 1 来看数据盘存不存在瓶颈,如果busy比较大,那么需要继续添加硬盘来提升IOPS。事务型的交易系统数据盘的繁忙主要是写脏数据造成的(可能你的情况跟我不一样),一般对IOPS要求不高。这个要根据系统情况来定。IOPS不够,可以考虑用SSD来提升IOPS,但是存储对SSD的支持不太好,最好让SSD的IO可以打散在存储的多个光纤环路中。

3)ORACLE 的GROUP COMMIT是自动、默认的行为,这块其实不用作优化也没法做优化。

4)对关键业务表设置了CACHE属性,保证事务的数据都在内存里。这一块的优化也非常重要,优化效果也非常明显。ORACLE里可以设置CACHE表。

 

当时压测是基于P740的一个小机+V7000的一个中端存储,做完以上优化,TPS可以达到6000。

非常规手段的优化:

1)由于P740只有物理16core cpu,CPU使用率到了65%,LOAD 接近40。为了LGWR可以任意时刻获取CUP资源,设置了_high_priority_processes 参数,网站空间,保证LGWR可以随时获得CPU资源,不用排队。

2)操作系统级别设置dscrctl -n -b -s 1 内存预读,效果非常明显,立即可以提升1000+的TPS

3)如果你是万兆网卡,chdev -l hba0 -a cdli_queues=4 -P,加大网卡处理队列,效果也非常明显,可以提升1500+的TPS。事物数超大的系统,网卡往往是瓶颈,优化非常必要。及时你的3个千M网卡处理量还完全没到瓶颈,可是使用万兆网卡做了这个优化,还是非常的能看到立竿见影的下效果。

4)ORACLE的REDO LOG 块大小设置为4K.11GR2的版本可以指定REDO LOG的块大小,一般是磁盘的扇区大小512字节。在我的版本11.2.0.3下修改会报错,说修改值与实际扇区大小不匹配。通过修改隐含参数_disk_sector_size_override为true,可以强制改成功。修改的办法是在alter database add log file xxxx blocksize 4096。如果拿PL/SQL压测,采取commit write immediate wait方式提交,优化前后的差距接近4倍,非常惊人。但是拿我们的业务压测,只是提升了1500+的TPS,也非常的不错了。

 经过上面4步的优化,TPS可以接近1W了。在此分享,希望对大家有帮助,很多地方说的不详细,有需要,可以联系我,进一步探讨。

 P740,16core 3.55GHZ的内存,32G CPU,3块千M网卡BOND。

V7000 80G 的CACHE。12块LOG 盘。足够多的数据盘。

本文出自 “魏兴华的DBA生活” 博客,请务必保留此出处

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn