I dont understand how to monitor LRUs

[WiccaChic]

Hi, I'm confused as usual. According to the performance manual to monitor LRU queues you do the following:

"To monitor the percentage of dirty pages in LRU queues, use the onstat -R command. When the number of dirty pages consistently exceeds the LRU_MAX_DIRTY limit, you have too few LRU queues or too few page cleaners."

So I do that and I see LOTS of stuff but I am guessing the summary portion on onstat -R is the important part:

"11674 dirty, 65498 queued, 65500 total, 65536 hash buckets, 4096 buffer size start clean at 20.000% (of pair total) dirty, or 205 buffs dirty, stop at 10.000%"

Problem is, what about this summary tells me if my dirty pages have exceeded my LRU_MAX_DIRTY limit? I guess I just dont understand this output and how to apply the monitoring rule to it.

 

[vpshriyan]

Hi,

Values of LRUS, LRU_MAX_DIRTY and LRU_MIN_DIRTY parameters decide the frequency of shared-memory buffers synchronisation to disk.

The onstat -R does not reflect the historical figures. It shows current LRU status and looking at the output you are unable to tell as how many times the IDS dirty pages have exceeded currently set LRU_MAX_DIRTY limit.

To see how your LRU related parameters have performed so far, you use onstat -F output. Here you will see 3 columns reflecting kind of writes that have taken place. In an ideally configured db server, one should have 0 Foreground-Writes, some LRU-Writes and maximum Chunk-Writes as possible. Here if the LRU-Writes out-numbers the Chunk-Writes, you need to reconsider the LRU, LRU_???_DIRTY parameters.

Looking at the inputs provided by you, it seems to me that you have following $ONCONFIG values.

BUFFERS 65500
LRU 64
LRU_MAX_DIRTY 20
LRU_MAX_DIRTY 10

Effectively you have a queue pair size of 65500/64=1024, and page cleaning will start the moment the dirty buffers reach 20% of 1024 ie. 204. If you have a large LRU-Writes, it would be better to increase the LRU_???_DIRTY parameter judiciously, or strengthen the Chunk-Write related parameters by tweaking them, again judiciously.

BTW, I could be wrong, but I feel that, 64 number of LRU are bit, on the higher side!

Regards,
Shriyan

 

[WiccaChic]

I would be willing to bet that when it comes to Informix subject matter, you are rarely wrong! Thanks for shedding the light once again V.

 

[WiccaChic]

Hi again,
I see the following in onstat -F:
Fg Writes LRU Writes Chunk Writes
0 60786507 2636054

So LRUw>ChunkW...what should I do?

 

[vpshriyan]

Hi Wic,

If the % of modified/dirty buffers exceeds the % in LRU_MAX_DIRTY, page cleaning begins. At system checkpoint event, the buffer pool is also cleaned. If these are not properly tuned/tweaked, the performance can suffer. You have two options to initiate a tuning.

1. Increase the LRU_???_DIRTY % just a bit, so that cleaners are called in bit late, meantime, the checkpoint mechanism will take care of syncing the modified buffers.

2. Decrease Checkpoint interval timings (CKPTINTVL), so that modified buffers are flushed, before it exceeds the LRU_MAX_DIRTY percentage.

Regards,
Shriyan

If the only tool you have is a hammer, you tend to see every problem as a nail.
An expert is a person who has a very good reason for guessing wrong.

 

[WiccaChic]

Hi again V, hope you or someone with more IDS experience than me (=most people) see this. I raised my buffers, LRUs and CLEANERs and noticed that my checkpoints increased from around 4 seconds to 10 seconds. I was wondering what I should tweak first - LRU*s or CLEANERS?

When I raised my buffers, I set LRUs and CLEANERS both to 84. The MAX and MIN are set at
LRU_MAX_DIRTY 2.000000
LRU_MIN_DIRTY 1.000000

 

[vpshriyan]

Hi wc,

I do not endorse the idea of changing several config parameters at one stroke, instead make required change in one parameter at a time and monitor it's effect. This is the most effective & successful way of tuning and tweaking.

As for the tuning, there is no hard & fast formula that can be applied on a production environment, that, one can expect to have great performance improvement. However, there are certain thumb rules and parameter recommendation by which one can try to get maximum benefit, within the various available resources.

Let us consider you queries:
1. BUFFERS can be set to approximately 10-20% of the system memory.
2. LRU_MAX_DIRTY can be set to >=2 and <= 20
3. LRU_MIN_DIRTY can be set to >=1 and <= 10
4. LRUS may vary >= 4
5. CLEANERS can be >= 4 and can be equal to LRUS
6. CKPTINTVL start with 300 seconds (once in 5 minutes)

If you have observed the checkpoints taking longer time to complete the syncing job, you may think of reducing the CKPTINTVL value, so that there could be frequent event of checkpoints, which will in turn reduces the volume of modified buffers to be written to the disk at a given point of time.

Regards,
Shriyan
"Minds, like parachutes, work only when they are open."

 

[informixtechnical]

I think that you have not configured your Least Recently Used Buffers Properly. You Should Have Mentioned Your Currently Configured Values, So That It Would Be Possible For Me To Give You A Better Solution, Anyway No Problem.We Can Sort This Out.

Change LRU_MAX_DIRTY TO 60 and
LRU_MIN_DIRTY TO 50.

This Should Solve Your Problem.

Don't Forget To Bounce Back The Informix Server After You Have Changed The Above Parameters.