Re: Performance Issues

I see several problems. Read all the way through. yener@my-deja.com wrote: > > We identified this performance issue much. However, we cannot find any > cause that effect performance except the application itself is a > sequential process. > > We are using raw devices. The current amount of data in the system is > approxiametly 100 GB and every day it grows. We cannot do fragmentation > for some of the big tables which we think that effect performance. > Because they are big tables and will not fit in 2Gb when we export You can refragment without exporting them and you can use my dbexport replacement, myexport, to beat the 2GB file limitation. > them. Also during fragmentation, the system will not be used by users. That's a different story. > Although, I said that it's a batch proccessing system, users use the > system very often by entering transactions. It's a credit card system. > The database is buffered logged. We need this type of logging > mechanism. Because the application itself needs it. > > Please note that the information you want is below. > > outout of onstat -g iof > ======================== Let me single out I/O bottlenecks: > AIO global files: > gfd pathname totalops dskread dskwrite io/s > 7 s04_01 176530154 174971190 1558964 54.4 > 10 s03_04 217330658 214360687 2969971 67.0 > 15 s04_03 98974098 98198270 775828 30.5 > 24 s05_04 120234811 118613886 1620925 37.1 You are having the engine log lots and lots to /tmp, is that SPL trace? Can you clean it up, it is using server resources. > onstat -d > ============> > Informix Dynamic Server Version 7.31.UC3 -- On-Line -- Up 46 days > 23:42:33 -- > 1487216 Kbytes [SNIP] > onstat -p > ==========> > Informix Dynamic Server Version 7.31.UC3 -- On-Line -- Up 46 days > 23:46:32 -- > 1487216 Kbytes > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 4099221774 52416852 1193373999 0.00 124353583 72812631 1126064356 > 88.96 Write cache % could be better. Perhaps more buffers or longer checkpoints. > isamtot open start read write rewrite delete commit > rollbk > 1308854363 2384276789 438304504 1523258070 154776168 129503437 8806300 > 40298909 > 380197 > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs > 0 0 0 0 0 0 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 2022136.09 371168.17 8865 18274 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 181782400 0 3410544615 0 0 18609 9641171 > 11532690 This bufwaits ratio is HUGE, over 15%. Anything over 7% is slowing you down and over 10% is performance hell! BR = (181782400 / (52416852 + 1126064356)) * 100 = 15.42% > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 1514507127 3367590 1986430125 3493159557 21993058 [SNIP] > > > CLEANERS 32 # Number of buffer cleaner processes More cleaners unless your checkpoints are very low. > > > SHMBASE 0xa000000 # Shared memory base address > > > SHMVIRTSIZE 128000 # initial virtual shared memory> segment > > > size > > > SHMADD 32000 # Size of new shared memory segments > > > (Kbytes) > > > SHMTOTAL 0 # Total shared memory (Kbytes). > > > 0=>unlimited > > > CKPTINTVL 300 # Check point interval (in sec) > > > LRUS 127 # Number of LRU queues Wow, a BR of 15% with 127 LRUS! Try playing with the LRUPOLICY parameter values I posted yesterday. [SNIP] Art S. Kagel > > > ========================================================== > > > > > > Any recommandation will be helpful for us in order to improve > > > performance of the system. > > > > > > We are also think to move this E5500 to an E10000 system not to > suffer > > > from performance. However, we don't know > > > how much it will help us if we move it to an E10000 running with 6 > CPUs > > > and 8MB of RAM. Do you have any idea? > > > > > > And how should we configure system if we move it to E10000. What > should > > > configuration parameters be? > > > > > > Thanks in advance. > > > > > > Yener > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.