DB comes down w/ BUFFERS > 350000 ... UR down to 95%

Hello all, Our DB has noticeably gotten slower over the past few months [since Art last gave me a "hey your DB is purring along fine"]. I checked, and our Read Utilization is down around 95%, which is rather low -- the last check I did it was closer to 99.97%. In reviewing the newsgroup, it seems that our BUFFERS may need some tuning, as our DB is now closer in size to 12GB -- rather than 8GB previously. We're doing more, so I assume our "working set" is greater. Granted, we probably have some I/O issues, we're in the process of solving, but in the meantime I can't seem to get the BUFFERS above 350000. I've set SHMTOT to 0, and SHMADD and SHMVIRTSIZE are 50502. LOCKS is 700000. As below: LOCKS 700000 # Maximum number of locks BUFFERS 350000 # Maximum number of shared buffers NUMAIOVPS 20 # Number of IO vps PHYSBUFF 48 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 10 # Maximum number of logical log files CLEANERS 100 # Number of buffer cleaner processes SHMBASE 0x10000000L # Shared memory base address#SHMVIRTSIZE 16384 # initial virtual shared memory segment size SHMVIRTSIZE 50502 # initial virtual shared memorysegment size SHMADD 50502 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 400 # Check point interval (in sec) LRUS 80 # Number of LRU queues LRU_MAX_DIRTY 30 # LRU percent dirty begin cleaninglimit LRU_MIN_DIRTY 20 # LRU percent dirty end cleaning limit#LRU_MAX_DIRTY 5 # LRU percent dirty begin cleaning limit #LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit LTXHWM 50 # Long transaction high water markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 300 # Transaction timeout (in sec) LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 300 # Transaction timeout (in sec) STACKSIZE 32 # Stack size (Kbytes) This is a dual athlon 1900 box, running 7.31.UD2, and RH7.3. We've got 3.5GB of RAM on the machine. I've setup the shmmax and shmall to be ~640MB, or 671088640. This doesn't help much. Anytime I try and go over 350,000 BUFFER's, it quits immediately with: 23:29:09 Exception Recursion while handling: MT_EX_OS, Context: mem 23:29:09 PANIC: Attempting to bring system down 23:29:09 mt_shm_remove: WARNING: may not have removed all/correctsegments Any ideas why?

Hello, This looks like bug 161674 "LINUX 32-BIT SERVER SILENTLY DIES DURING INITIALIZATION IF 'BUFFERS' ARE 260000 OR MORE. MAY BE RELATED TO '__PAGE_OFFSET' IN LINUX KERNEL" Fixed in 7.31.UD7. Regards Guy Anthony Presley wrote: > Hello all, > > Our DB has noticeably gotten slower over the past few months [since > Art last gave me a "hey your DB is purring along fine"]. I checked, > and our Read Utilization is down around 95%, which is rather low -- > the last check I did it was closer to 99.97%. > > In reviewing the newsgroup, it seems that our BUFFERS may need some > tuning, as our DB is now closer in size to 12GB -- rather than 8GB > previously. We're doing more, so I assume our "working set" is > greater. Granted, we probably have some I/O issues, we're in the > process of solving, but in the meantime I can't seem to get the > BUFFERS above 350000.> > I've set SHMTOT to 0, and SHMADD and SHMVIRTSIZE are 50502. LOCKS is > 700000. As below: > > LOCKS 700000 # Maximum number of locks > BUFFERS 350000 # Maximum number of shared buffers > NUMAIOVPS 20 # Number of IO vps > PHYSBUFF 48 # Physical log buffer size (Kbytes) > LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 10 # Maximum number of logical log files > CLEANERS 100 # Number of buffer cleaner processes > SHMBASE 0x10000000L # Shared memory base address> #SHMVIRTSIZE 16384 # initial virtual shared memory > segment size > SHMVIRTSIZE 50502 # initial virtual shared memory> segment size > SHMADD 50502 # Size of new shared memory segments > (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). > 0=>unlimited > CKPTINTVL 400 # Check point interval (in sec) > LRUS 80 # Number of LRU queues > LRU_MAX_DIRTY 30 # LRU percent dirty begin cleaning> limit > LRU_MIN_DIRTY 20 # LRU percent dirty end cleaning limit> #LRU_MAX_DIRTY 5 # LRU percent dirty begin cleaning > limit > #LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit > LTXHWM 50 # Long transaction high water mark> percentage > LTXEHWM 60 # Long transaction high water mark > (exclusive) > TXTIMEOUT 300 # Transaction timeout (in sec) > LTXEHWM 60 # Long transaction high water mark > (exclusive) > TXTIMEOUT 300 # Transaction timeout (in sec) > STACKSIZE 32 # Stack size (Kbytes)> > This is a dual athlon 1900 box, running 7.31.UD2, and RH7.3. We've > got 3.5GB of RAM on the machine. I've setup the shmmax and shmall to > be ~640MB, or 671088640. This doesn't help much. Anytime I try and > go over 350,000 BUFFER's, it quits immediately with: > > 23:29:09 Exception Recursion while handling: MT_EX_OS, Context: mem > 23:29:09 PANIC: Attempting to bring system down > 23:29:09 mt_shm_remove: WARNING: may not have removed all/correct> segments > > Any ideas why?

"Anthony Presley" <anthony@zoraptera.com> wrote in message news:a55ad738.0411292101.1bb665a8@posting.google.com... <lots of diagnostics> OS and IDS version?

"Neil Truby" <neil.truby@ardenta.com> wrote in message news:<312rnsF357p2eU1@uni-berlin.de>... > "Anthony Presley" <anthony@zoraptera.com> wrote in message > news:a55ad738.0411292101.1bb665a8@posting.google.com... > > <lots of diagnostics> > > OS and IDS version? As mentioned above: This is a dual athlon 1900 box, running 7.31.UD2, and RH7.3. We've got 3.5GB of RAM on the machine. --Anthony