Re: DSA TUNNING: SHARED MEMORY
Javier Puente wrote:
> This is a multi-part message in MIME format.
>
> --------------36FE63984788
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I folks, i would like to tunning DSA Shared Memory to get a better
> performance.
> I am using DSA 7.22 with Solaris 2.5.1 in Sun Sparc server 5 with just
> one processor.
> The machine uses 128 Mb of RAM.
> I have tried moving tha whole parameters of SHM :
> STACKSIZE
> SHMVIRTSIZE
> PHYSBUFF
> LOGBUFF
> BUFFERS
> SHMADD
> SHMTOTAL>
> I also modified some values in /etc/system:
> set shmsys:shminfo_shmmax=104857600
> set semsys:seminfo_semmap=64
> set semsys:seminfo_semmni=4096
> set semsys:seminfo_semmns=4096
> set semsys:seminfo_semmnu=4096
> set semsys:seminfo_semume=64
> set semsys:seminfo_semmsl=100
> set shmsys:shminfo_shmmin=100
> set shmsys:shminfo_shmmni=50
> set shmsys:shminfo_shmseg=100
>
> altougt i am not sure in this last part. Anybody knows which are
> the best kernel parameters for this???
>
Read the release notes that comes with your version/release
> The special first probe is an INSERT of 10.000 records over a
> transactional database. I get around 145 seconds, that's my best time.
>
Do you have indexes in your table? Tables with quite a number of indexescan slow down inserts
since each index will also be updated.
> Any comment or help will really apreciated.
>
> I am sending my onstat -a for aditional help.
>
> THANKS IN ADVANCE
>
> Javier Puente
>
> 22:31:31 DR: DRAUTO is 0 (Off)
> 22:31:34 INFORMIX-OnLine Initialized -- Shared Memory Initialized.
> 22:31:34 Physical Recovery Started.
> 22:31:34 Physical Recovery Complete: 0 Pages Restored.
> 22:31:34 Logical Recovery Started.
> 22:31:37 Logical Recovery Complete.> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks
>
> 22:31:37 Onconfig parameter SHMADD modified from 8192 to 16000.
Why increase SHMADD? This is only done if users running DSS queries
suddenly increase and decrease in number. If it's fairly constant, SHMVIRTSIZE
should be the one increased.
Both these parameters rarely affect OLTP performance.
You said you only have 128 MB of RAM. Informix recommends that the total
amount of memory to be alloted for the engine is 25% of physical memory.
> DBSERVERALIASES alamos1_shm # List of alternate dbservernames
> NETTYPE ipcshm,5,10,CPU # Configure poll thread(s) for nettype
> NETTYPE tlitcp,5,10,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
> RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)>
Use Forced Residency if supported.
> MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
> NUMCPUVPS 1 # Number of user (cpu) vps
> SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
> NOAGE 0 # Process aging
> AFF_SPROC 0 # Affinity start processor
> AFF_NPROCS 0 # Affinity number of processors
> LOCKS 15000 # Maximum number of locks
> BUFFERS 16000 # Maximum number of shared buffers
> NUMAIOVPS # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)> LOGSMAX 100 # Maximum number of logical log files
Do you really have to allocate that amount (100) of logical logs.If not, keep this down. I think
this also consumes memory.
> CLEANERS 1 # Number of buffer cleaner processes
> SHMBASE 0xa000000 # Shared memory base address
> SHMVIRTSIZE 8192 # initial virtual shared memory segment size
> SHMADD 16000 # Size of new shared memory segments (Kbytes)
> SHMTOTAL 96000 # 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
Keep this low to shorten the duration of checkpoints. Very impt. in OLTP.
That's all,
Zandy