G W:

Most likely your buffer pools do not have enough LRU queues defined to prevent the large number of concurrent access requests to the buffer cache from having to wait for each other in order to modify pages in the cache. Increase the "lrus" field in the BUFFERPOOL parameters in your ONCONFIG file:

BUFFERPOOL                size=2K,lrus=8,lru_min_dirty=50,lru_max_dirty=60,extendable=1,start_memory=600000,memory=auto

This is the setting in my tiny personal server that only has to deal with one or two active sessions. In most cases you should be setting something closer to the maximum value (512). You can monitor whether you have set it high enough be monitoring the Bufwaits Ratio (BR) metric. This is the calculation if you want to do it manually, or download the ratios.shr_ak package from my web site and install the ratios.sql stored procedure into sysmaster so you can run the newratios.ksh script which calculates BR and several other metrics that I use to get a quick view of the server's health:

BR = (bufwaits / (pagreads + bufwrites)) * 100

Ideally you want your BR under 6. If it exceeds 7 you will begin to notice slowness and paused sessions. If it passes 10 your phone will begin to ring with complaints. I'm guessing that your BR is over 10.0 now.

Download from www.askdbmgt.com/my-utilities.html

Art

I'm afraid is nothing with configuration.  Hung up happen 2 times since 4m (since upgrade)

Profile
dskreads   pagreads   bufreads   %cached dskwrits   pagwrits   bufwrits   %cached
128054408  435609255  9988961174 98.73   11422831   63399220   97369334   93.95

isamtot    open       start      read       write      rewrite    delete     commit     rollbk
10512212941 166858337  249984184  8487306818 20696625   3248052    2510590    2353998    153

gp_read    gp_write   gp_rewrt   gp_del     gp_alloc   gp_free    gp_curs
65181      2          99029      29         0          0          0

ovlock     ovuserthread ovbuff     usercpu  syscpu   numckpts   flushes
0          0            0          22465.79 6264.73  451        13849

bufwaits   lokwaits   lockreqs   deadlks    dltouts    ckpwaits   compress   seqscans
1753866    9246       11400184546 20         0          12918      2616365    2626144

ixda-RA    idx-RA     da-RA      logrec-RA  RA-pgsused lchwaits   logpgs-RA
130350202  13139462   30404429   1823       89697592   3681658    1203

G W:

Most likely your buffer pools do not have enough LRU queues defined to prevent the large number of concurrent access requests to the buffer cache from having to wait for each other in order to modify pages in the cache. Increase the "lrus" field in the BUFFERPOOL parameters in your ONCONFIG file:

BUFFERPOOL                size=2K,lrus=8,lru_min_dirty=50,lru_max_dirty=60,extendable=1,start_memory=600000,memory=auto

This is the setting in my tiny personal server that only has to deal with one or two active sessions. In most cases you should be setting something closer to the maximum value (512). You can monitor whether you have set it high enough be monitoring the Bufwaits Ratio (BR) metric. This is the calculation if you want to do it manually, or download the ratios.shr_ak package from my web site and install the ratios.sql stored procedure into sysmaster so you can run the newratios.ksh script which calculates BR and several other metrics that I use to get a quick view of the server's health:

BR = (bufwaits / (pagreads + bufwrites)) * 100

Ideally you want your BR under 6. If it exceeds 7 you will begin to notice slowness and paused sessions. If it passes 10 your phone will begin to ring with complaints. I'm guessing that your BR is over 10.0 now.

Download from www.askdbmgt.com/my-utilities.html

Art

Hi

please check
DT463494 Deadlocks may be observed after long waits on the hash and lru mutexes.
Newest version for 14.10.FC13 is 14.10.FC13W13