Utilizing shared memory on HPUX 10.20

Hi All, I am having trouble getting IDS 7.31.UC2 to use more than 1078 Mb's of shared memory on a HP9000 T500 running HPUX 10.20 despite the fact that the machine has 1500 Mb's of RAM and vmstat / glance reports > 130 Mb's of free memory. I started out trying to increase BUFFERS because the read cache was hovering on 92% and buffwaits percentage up to 20% Well that was my plan and it sounded like the next logical step. Problem is when I increased BUFFERS from 215,625 to 231,250 the engine failed to initialize with the following error: 20:35:30 Could not create single shared memory segment with residentand non-resident partitions. Proceeding to create 2 shared memory segments instead. 20:36:21 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 20:36:21 Assert Failed: kaiothread() ERROR 20:36:21 Informix Dynamic Server Version 7.31.UC2 20:36:21 Who: Session(0, @, 0, 0) Thread(172, kaio, 0, 13) File: kaio.c Line: 2121 OK I understand why the engine needs to create two shared memory segments, this is normal. But I don't know how to solve the assert failed. Informix have suggested that I disable KAIO but last time I tried the performance degraded significantly, so I am not keen to disable it again. Now Informix are suggesting SHMEM_MAGIC but I can't see how that will help when the machine only has 1.5 Gb of RAM. I have applied all of the HPUX patches recommend in the release notes. Kernel parameter SHMMAX = 1.5 Gb and onconfig SHMTOTAL=0 Onstat -g seg shows: Informix Dynamic Server Version 7.31.UC2 -- On-Line -- Up 1 days 17:31:26 -- 1094312 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 1541 1381451778 80000000 640016384 10376 V 37265 40862 61700 1381451777 c0cc4000 480559104 8248 R 58656 6 6 1381451779 dd710000 1130496 628 M 138 0 7 1381451780 dd824000 1130496 628 M 133 5 8 1381451781 dd938000 1130496 628 M 131 7 9 1381451782 dda4c000 1130496 628 M 131 7 10 1381451783 ddb60000 1130496 628 M 131 7 11 1381451784 ddc74000 1130496 628 M 131 7 12 1381451785 ddd88000 1130496 628 M 131 7 13 1381451786 dde9c000 1130496 628 M 131 7 14 1381451787 ddfb0000 1130496 628 M 131 7 Total: - - 1130749952 - - 97109 40922 OK I know the virtual segment has a lot of free memory, but at peak times it's comes close to dynamically adding another segment, which will also fail with the same error due to memory pressure. vmstat shows: procs memory page faults cpu r b w avm free re at pi po fr de sr in sy cs us sy id 33 0 0 10179 32583 8 2 0 0 0 0 0 3804 9391 5580 15 29 55 I coming to the conclusion that I am hitting a the limitation with KAIO in HP 10.20. Or am I missing something else? Would adding more memory to this machine help? If I add more physical memory, will I be able to allocate it to shared memory and still keep KAIOON? I can't see how considering the machine still has > 130Mb's of free memory? OK, here is my onconfig, running unbuffered logging, the machine has 10 CPU and is a dedicated database server with only 1 instance of Informix. Please feel free to offer any suggestions, especially if you see something wrong or stupid with my onconfig. Thanks and regards Matthew Byrne., onconfig: ROOTNAME mprootdbs ROOTPATH /opt/informix/dev/mprootdbs.ln ROOTOFFSET 0 ROOTSIZE 20000 MIRROR 1 MIRRORPATH /opt/informix/dev/mprootdbsm.ln MIRROROFFSET 0 PHYSDBS mpplogdbs PHYSFILE 40000 LOGFILES 30 LOGSIZE 50000 MSGPATH /opt/informix/logs/tpramimsp.mlog CONSOLE /opt/informix/logs/tpramimsp.clog ALARMPROGRAM /opt/informix/current/etc/no_log.sh SYSALARMPROGRAM /opt/informix/current/etc/evidence.sh TBLSPACE_STATS 1 WSTATS 1 TAPEDEV /dev/rmt/c1t5d0BEST TAPEBLK 1024 TAPESIZE 70000000 LTAPEDEV /dev/rmt/c2t5d0BEST LTAPEBLK 1024 LTAPESIZE 70000000 SERVERNUM 1 DBSERVERNAME tpramimsp_shm DBSERVERALIASES tpramimsp NETTYPE soctcp,9,100,NET NETTYPE ipcshm,9,100,CPU DEADLOCK_TIMEOUT 60 RESIDENT 0 MULTIPROCESSOR 1 NUMCPUVPS 9 SINGLE_CPU_VP 0 NOAGE 1 AFF_SPROC 1 AFF_NPROCS 9 LOCKS 200000 BUFFERS 215625 NUMAIOVPS 2 PHYSBUFF 8 LOGBUFF 8LOGSMAX 40 CLEANERS 127 SHMBASE 0x0 SHMVIRTSIZE 625000 SHMADD 32768 SHMTOTAL 0 CKPTINTVL 1200 LRUS 127 LRU_MAX_DIRTY 1 LRU_MIN_DIRTY 0 LTXHWM 50 LTXEHWM 60 TXTIMEOUT 0x12c STACKSIZE 32 DD_HASHSIZE 91 OFF_RECVRY_THREADS 10 ON_RECVRY_THREADS 1 DRAUTO 0 DRINTERVAL 90 DRTIMEOUT 90 DRLOSTFOUND /opt/informix/current/etc/dr.lostfound.12 CDR_LOGBUFFERS 128 CDR_EVALTHREADS 1,2 CDR_DSLOCKWAIT -1 CDR_QUEUEMEM 500 BAR_ACT_LOG /tmp/bar_act.log BAR_MAX_BACKUP 0 BAR_RETRY 1 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 ISM_DATA_POOL ISMData ISM_LOG_POOL ISMLogs RA_PAGES 6 RA_THRESHOLD 3 DBSPACETEMP mptmpdbs1,mptmpdbs2,mptmpdbs3 DUMPDIR /tmp DUMPSHMEM 0 DUMPGCORE 0 DUMPCORE 0 DUMPCNT 1 FILLFACTOR 90 USEOSTIME 1 MAX_PDQPRIORITY 100 DS_MAX_QUERIES 2 DS_TOTAL_MEMORY 8000 DS_MAX_SCANS 100 DATASKIP OFF OPTCOMPIND 0 ONDBSPACEDOWN 0LBU_PRESERVE 0 OPCACHEMAX 0 HETERO_COMMIT 0 OPT_GOAL -1 DIRECTIVES 1 RESTARTABLE_RESTORE offCDR_LOGDELTA 30 CDR_NUMCONNECT 16 CDR_NIFRETRY 300 CDR_NIFCOMPRESS 0 Sent via Deja.com http://www.deja.com/ Before you buy.

Matthew, Can't speak for the Informix side of things as I'm just a lowly UNIX admin :-) but it seems you're asking to attach more shared memory than what you have available ie more RAM should allow more shared memory. errno 12 means "not enough core" from /usr/include/sys/errno.h. There might be something to using a SHMEM_MAGIC executable type (compile EXEC_MAGIC and chatr -M to SHMEM_MAGIC). This would combine text and data into quadrant 1, with shared memory allowed in quadrant 2 (in addition to quadrant 3 and most of quad 4). You've indicated the total amount of shared memory, but not of other shared VM objects such as memory mapped files and shared libraries. These too count towards the 1.75-2/75 Gbyte limit, and can also lend to fragmentation of what needs to be contiguous for shared memory. FYI shmmax limits largest single segment size - which at 32-bits will be no larger than 1 Gbyte (shmem segs must be contiguous and cannot cross quadrant boundries). Regards, Eric Stahl mattb5@ozemail.com.au wrote: >I am having trouble getting IDS 7.31.UC2 to use more than 1078 Mb's of >shared memory on a HP9000 T500 running HPUX 10.20 despite the fact that >the machine has 1500 Mb's of RAM and vmstat / glance reports > 130 Mb's >of free memory. > >I started out trying to increase BUFFERS because the read cache was >hovering on 92% and buffwaits percentage up to 20% Well that was my >plan and it sounded like the next logical step. Problem is when I >increased BUFFERS from 215,625 to 231,250 the engine failed to >initialize with the following error: > >20:35:30 Could not create single shared memory segment with resident>and non-resident partitions. Proceeding to create 2 shared memory >segments instead. >20:36:21 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 >20:36:21 Assert Failed: kaiothread() ERROR >20:36:21 Informix Dynamic Server Version 7.31.UC2 >20:36:21 Who: Session(0, @, 0, 0) > Thread(172, kaio, 0, 13) > File: kaio.c Line: 2121> >OK I understand why the engine needs to create two shared memory >segments, this is normal. But I don't know how to solve the assert >failed. Informix have suggested that I disable KAIO but last time I >tried the performance degraded significantly, so I am not keen to >disable it again. Now Informix are suggesting SHMEM_MAGIC but I can't >see how that will help when the machine only has 1.5 Gb of RAM. > >I have applied all of the HPUX patches recommend in the release notes. > >Kernel parameter SHMMAX = 1.5 Gb and onconfig SHMTOTAL=0 > >Onstat -g seg shows: > >Informix Dynamic Server Version 7.31.UC2 -- On-Line -- Up 1 days >17:31:26 -- 1094312 Kbytes > >Segment Summary: >id key addr size ovhd class blkused blkfree >1541 1381451778 80000000 640016384 10376 V 37265 40862 >61700 1381451777 c0cc4000 480559104 8248 R 58656 6 >6 1381451779 dd710000 1130496 628 M 138 0 >7 1381451780 dd824000 1130496 628 M 133 5 >8 1381451781 dd938000 1130496 628 M 131 7 >9 1381451782 dda4c000 1130496 628 M 131 7 >10 1381451783 ddb60000 1130496 628 M 131 7 >11 1381451784 ddc74000 1130496 628 M 131 7 >12 1381451785 ddd88000 1130496 628 M 131 7 >13 1381451786 dde9c000 1130496 628 M 131 7 >14 1381451787 ddfb0000 1130496 628 M 131 7 >Total: - - 1130749952 - - 97109 40922 > >OK I know the virtual segment has a lot of free memory, but at peak >times it's comes close to dynamically adding another segment, which >will also fail with the same error due to memory pressure. > >vmstat shows: > > procs memory >page faults cpu > r b w avm free re at pi po fr de >sr in sy cs us sy id > 33 0 0 10179 32583 8 2 0 0 0 0 >0 3804 9391 5580 15 29 55 > >I coming to the conclusion that I am hitting a the limitation with KAIO >in HP 10.20. > >Or am I missing something else? >Would adding more memory to this machine help? >If I add more physical memory, will I be able to allocate it to shared >memory and still keep KAIOON? I can't see how considering the machine >still has > 130Mb's of free memory? > >OK, here is my onconfig, running unbuffered logging, the machine has 10 >CPU and is a dedicated database server with only 1 instance of >Informix. Please feel free to offer any suggestions, especially if you >see something wrong or stupid with my onconfig. > >Thanks and regards >Matthew Byrne., > >onconfig: <SNIP>