Re: Shared Memory allocation error
In article <5j3fd5$bt0@cssun.mathcs.emory.edu>, Mark Stannard
<mws@appi.ci.in.ameritech.com> writes
>All:
>
>I am having a problem with online ver 7.10.UD1 running on AIX 4.1.4.0.
>When I run a query on a view that joins many tables online begins
>allocating additional shared memory until it hits an illegal address. At
>this time the query hangs but the engine stays up. If anyone can point
>me towards something to check/change I'd appreciate it. Below is an
>excerpt from the log file and the config parameters concerning shared memory.
>
>10:32:39 Checkpoint Completed: duration was 0 seconds.
>10:32:56 On-Line Mode
>10:46:30 dynamically allocated new shared memory segment (size 8388608)
>
>10:46:36 dynamically allocated new shared memory segment (size 8388608)
>
>10:47:44 dynamically allocated new shared memory segment (size 8388608)
>
>10:47:51 dynamically allocated new shared memory segment (size 8388608)
>
>10:47:58 dynamically allocated new shared memory segment (size 8388608)
>
>10:48:04 dynamically allocated new shared memory segment (size 8388608)
>
>10:48:10 dynamically allocated new shared memory segment (size 8388608)
>
>10:48:17 shmat: [EINVAL][22]: shared memory base address illegal
>
>10:48:17 using 0xd0000000, needs 0xffffffff
>
>10:48:17 out of virtual shared memory
>
>10:52:39 Checkpoint Completed: duration was 0 seconds.>
>
># Shared Memory Parameters
>
>LOCKS 2000 # Maximum number of locks
>BUFFERS 200 # Maximum number of shared buffers
>NUMAIOVPS # Number of IO vps
>PHYSBUFF 32 # Physical log buffer size (Kbytes)
>LOGBUFF 64 # Logical log buffer size (Kbytes)>LOGSMAX 6 # Maximum number of logical log files
>CLEANERS 1 # Number of buffer cleaner processes
>SHMBASE 0x30000000 # Shared memory base address
>SHMVIRTSIZE 8000 # initial virtual shared memory segment size
>SHMADD 8192 # Size of new shared memory segments (Kbytes)
>SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
>CKPTINTVL 300 # Check point interval (in sec)
>LRUS 8 # Number of LRU queues
>LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
>LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
>LTXHWM 50 # Long transaction high water mark percentage
>LTXEHWM 60 # Long transaction high water mark
>(exclusive)
>TXTIMEOUT 0x12c # Transaction timeout (in sec)
>STACKSIZE 32 # Stack size (Kbytes)>
>
>
>Thanks,
>
>
>Mark Stannard
>Ameritech
>Indianapolis, IN 46204
>
>
Make sure OPTCOMPIND = 0 (NOT 2)! This should reduce memory
requirements considerably.
--
David Williams