setting Resident to 1will prevent the system from swapping the shared memory segments to disk.
It is advised to use it when your machine's functionality is exclusively dedicated to this Informix instance. If this is not the case, the fact of forcing the shared memory 'in memory' instead of swapping may have unexpected negative effects on other components running on the same box.
as per the other shmem related parameters, the more buffers you set, the better the performance. A general rule of thumb is:
1) calculate the memory needs for all the applications running on the box, excluding Informix.
2) take 60-70% of the remaining memory, leaving some spare room for eventual growth.
Calculate the number of buffers accordingly, and monitor the Virtual shared memory segments allocation in the informix log file, while the user applications are running. The total of these allocations + SHMVIRTSIZE in the onconfig file will give you the right quantity to set for the SHMVIRTSIZE parameter.
Also think about creating as many LRUs as need, or set automatic LRU parameter (AUTO_LRU_TUNING) if you are i 11.50 or above.
Check values of onstat -p in production time, checking 'read cache' above 97% and 'write cache' above 90-92%. (you will need to rebounce the engine).
Also check that 'lru waits' value in onstat -p is not constantly growing strongly.
This is a starter of your cache tuning. we can talk after, but this is gonna be longer :-)
Thanks for the reply. I am having 11.7 version and already using AUTO_LRU_TUNING. Read cache never goes beyond 95% and write cache goes till 85% (need to see how this can be improved).
Also FG Writes (onstat -F) keeps on increasing, need guidance on how to decrease this.
Do you have these figures after a comfortable warump time ( 1 day or 2 for instance? )
else the solutionis to put more buffers.
AUTO_LRUS won't improve cache rate, but how lRus are accessed and flushed
95% for read cache is not excellent, but can be improved and it can make a positive difference.
same for write cache, but write cache is very sensitive to how the applications behave
We have page size of 16 K for one of our dbspaces that is reason behind having 16K buffers. Actually the server handles some bulky applications. In a system with 4GB memory, I have seen applications eating up around 2 GB. So the intent is that Informix should not go beyond 1 GB.
Also one more thing that seems strange to me is the uneven distribution of CPU vps. I have dedicated 50% of the total Virtual CPUs to Informix. But only 1 cpu takes majority of the load, is it expected?
VPs of Class: CPU
VP ID Class User CPU Time System CPU Time Total CPU Time
19 cpu 80.58 0.47 81.05
14 cpu 4832.92 25.13 4858.05
1 cpu 5512.83 201.36 5714.19
16 cpu 833.84 7.92 841.76
17 cpu 178.41 0.82 179.23
18 cpu 266.8 0.81 267.61
13 cpu 10106.33 187.77 10294.1
15 cpu 1270.24 12.75 1282.99
Total 23081.95 437.03 23518.98
sorry for the delay I was deeply crawly in technical reports writing...
How many cores does your server have?
you probably have oversize the cpuvp's number as compared to the real load and the number of available cores your server has.
Too many cpuvps can induce overhead also...
How many user sessions are running in average ?
Try setting 2 cpu VPs, then run onstant -g glo, and look in the "eff" column, in the individual virtual processors part.
The closer to 100%, the better you cpuvp's number is configured.
Regarding the SHMEM, you have about 200 Mb of ShMEM configured, so you still have
800 Mb of margin to reach your limit of 1Gb (please also consider SHMVIRTSIZE)
So why not grow up to 800 Mb, keeping 200 Mb for shmvirstsize ?
Can you also justify precisely why you use 16 K pages? Blobs? Enormous row size tables ?