IDS Forum

Re: Increasing shared memory

Posted By: Art Kagel
Date: Friday, 17 February 2012, at 6:04 a.m.

In Response To: Increasing shared memory (SUSHANT KODE)

See some notes below:

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.

On Fri, Feb 17, 2012 at 12:42 AM, SUSHANT KODE <ksushants@gmail.com> wrote:

> Hi All,
>
> We have Informix 11.10.FC2 on SUSE Linux 10,RAM 24GB with shared memory of
> 19190788 Kbytes. The bufferpool is as follows:
> BUFFERPOOL
>
> default,buffers=102400,lrus=32,lru_min_dirty=1.000000,lru_max_dirty=2.000000
> BUFFERPOOL
>
> size=2K,buffers=204800,lrus=32,lru_min_dirty=1.000000,lru_max_dirty=2.000000
> BUFFERPOOL
>
> size=8K,buffers=1700000,lrus=128,lru_min_dirty=1.000000,lru_max_dirty=2.000000
>
> We added 24GB more RAM to system and tried doubling the shared memory due
> to
> performance issues by setting the buffers as follows:
> BUFFERPOOL
>
> default,buffers=204800,lrus=32,lru_min_dirty=1.000000,lru_max_dirty=2.000000
>

Why double the 'default' setting? This is ONLY used to create new buffer
pools if you create a new dbspace with a pagesize that does not already
have a BUFFERPOOL setting.

> BUFFERPOOL
>
> size=2K,buffers=409600,lrus=32,lru_min_dirty=1.000000,lru_max_dirty=2.000000
> BUFFERPOOL
>
> size=8K,buffers=3400000,lrus=128,lru_min_dirty=1.000000,lru_max_dirty=2.000000
>

You only have 409,600 2K buffers but 3,400,000 8K buffers. Is this
realistic? Do you really have 64 times as much data in your 8K dbspaces as
you do in 2K dbspaces? Also, you increased your shared memory by 14GB by
increasing the buffers like this. Do you even have 28GB of data on disk?

>
> Instead of improving, the server perfromance has degraded. The processes
> are
> taking longer time. Also the IDS shuts downs in between with the following
> error:
> Fatal error in ADM VP at mt.c:13388
> Unexpected virtual processor termination, pid = 1825, exit = 0x9
> PANIC: Attempting to bring system down
>

Probably an old bug. Informix 11.10.FC2 is older and an early version of
11.10 at that. You should upgrade to 11.50.FC9 or 11.70.FC4 or later.

>
> We had the followng advisory in the online.log
> 09:45:31 WARNING! Logical log layout may cause Dynamic Server to get into
>
> a locked state. Recommended smallest logical log size
>

This is telling you do that you need to recreate your logical logs with a
larger size for each log.

>
> is 16 times maximum concurrent user threads.
>
> 09:59:56 Performance Advisory: Logical log file size might be too small
> for a
>
> checkpoint to complete.
> 09:59:56 Results: The size of individual logical log files is too small for
>
> the current workload, resulting in each log file filling very
>
> quickly. If log files fill in less than 30 seconds, the checkpoint
>
> might remain blocked because the last log file fills during the time
>
> needed to perform the checkpoint.
> 09:59:56 Action: Increase the size of the individual logical log files so
>
> that it takes at least 30 seconds to fill each one. Look at the
>
> online log to determine how quickly the log files are filling, and
>
> then increase the size of the files proportionately.
>
> 10:53:13 Performance Advisory: Based on the current workload, the physical
> log
> might be too small to
> accommodate the time it takes to flush the buffer pool.
> 10:53:13 Results: The server might block transactions during checkpoints.
> 10:53:13 Action: If transactions are blocked during the checkpoint,
> increase
> the size of the
> physical log to at least 739760 KB.
>

This one is often spurious. Watch the server shortly before a checkpoint
during peak update load and see what percent of the physical log is full
(see the onstat -F report). If it is close to 75% then this message is
valid and you probably should increase the physical log size as
recommended. If, however, the physical log is mostly empty at checkpoint
time then the message is spurious. The algorithm that the engine is using
to produce that message was brand new in 11.10 and is still evolving even
in 11.70.

>
> Also when checked the swap memory was completely utilised. So we had to
> rollback the buffer changes and get it back to the old setting of the
> buffer.
>

Linux follows the BSD memory model and copies everything from memory to
swap immediately when it is first loaded into memory. That means that you
need at least 3x the amount of memory for swap space. Did you double the
swap when you doubled main memory? Also, you should be running the engine
with the RESIDENT setting in the ONCONFIG file set to 1 or -1 so that all
shared memory segments used by Informix are non-swappable.

>
> I would like to know the following after increasing the shared memory:
> 1) If the shared memory is to be increased, what are the other parameters
> (LGOBUFF, PHYBUFF)to increase along with buffers, lrus, lru_min_dirty,
> lru_max_dirty?
>

You are running with the lru_min/max_dirty settings very aggressive. In
11.xx we can tune these down from 1 & 2, respectively, that we would
normally use in Informix 10.00 and earlier to higher values like 50 & 20
that allow the engine to do its writes more efficiently since checkpoints
no longer block user threads.

> 2) What are areas we need to look into apart from increasing the shared
> memory? What are the utilies (eg. onstat -g con) that will help us analyze
> the
> performance?
>
> Do let me know if any details are required.
> thanks in advance.
>
> Regards,
> Sushant
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--e89a8f3ba6813065d004b926e8ce

Messages In This Thread

• Increasing shared memory
  SUSHANT KODE -- Friday, 17 February 2012, at 12:42 a.m.
  • Re: Increasing shared memory
    Art Kagel -- Friday, 17 February 2012, at 6:04 a.m.
    • Re: Increasing shared memory
      Paul Watson -- Friday, 17 February 2012, at 8:12 a.m.
  • Re: Increasing shared memory
    George_Palmer@aotx.uscourts.gov -- Friday, 17 February 2012, at 8:15 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.