Results 1 to 8 of 8
  1. #1
    Join Date
    Jan 2012
    Posts
    6

    Unanswered: Can someone provide some pointers on Shared Memory Configuration paramters

    Need to understand how tweaking of "Resident" parameter and other shared memory configuration parameters can impact the performance. Can someone give some pointers on this.

  2. #2
    Join Date
    Sep 2011
    Location
    Pont l'Abbé, Brittany, France
    Posts
    381
    Provided Answers: 1
    Hi,

    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 :-)


    E.

  3. #3
    Join Date
    Jan 2012
    Posts
    6
    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.

  4. #4
    Join Date
    Sep 2011
    Location
    Pont l'Abbé, Brittany, France
    Posts
    381
    Provided Answers: 1
    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
    E.

  5. #5
    Join Date
    Jan 2012
    Posts
    6
    my Informix instance was around 15 days old when I took these numbers. Here are the buffer configuration, is there any formula to configure these buffer values?

    BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=60.00,l ru_max_dirty=70.00 # Default is 50/60.5
    BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=60,lru_ max_dirty=70
    BUFFERPOOL size=16K,buffers=10000,lrus=8,lru_min_dirty=60,lru _max_dirty=70

    Also how can I figured out if buffers are properly flushed?

  6. #6
    Join Date
    Sep 2011
    Location
    Pont l'Abbé, Brittany, France
    Posts
    381
    Provided Answers: 1
    These values are strange, use of 16K buffers are not usual, and the sum of them gives very few shared memory. ( =~ 200 Mb ), unless you have 10 users working on it

    How much memory available has your system? and how many users to be connected.

    Before going into fine tuning, give your instance some air ( buffers ) to breathe.
    I would give =~50% of the available RAM, or more if the server only handles Informix

    monitoring buffers flush is obtained by running onstat -F, but your problem is, again the very small size of your buffer cache

    E.

  7. #7
    Join Date
    Jan 2012
    Posts
    6
    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
    Last edited by pujakalra; 09-06-12 at 07:04.

  8. #8
    Join Date
    Sep 2011
    Location
    Pont l'Abbé, Brittany, France
    Posts
    381
    Provided Answers: 1
    Hi,

    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 ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •