Referring back to this question:

How can I disable or limit disk cache memory usage globally?

Have a use case where the monitoring tools are pretty basic, and we can't add SNMP to the server. We keep getting warnings that the memory usage is out of hand - however, it is merely the disk cache. I want to still set a monitoring alert on the server for a real problem, but short of setting it to 99%, I'd like to limit the memory usage of the disk cache to around 90% so that if it does go over that than we can get a 'real' alert, if you follow.

It seems as though Chris' answer (on previous Q) might be the best though.

Any other suggestions on how this may be achieved?

  • What is the monitoring server alerting on? What figure is it classing as memory 'free'? – Ed Neville Mar 15 '17 at 18:15
  • Hey Ed. It's just alerting on amount of memory used, from the free command I suspect. Either that or cat /proc/meminfo 'memfree' entry. As mentioned, the monitoring tool is pretty basic and cannot be configured to look at 'cached' as well and do something intelligent. – FiddleDeDee Mar 16 '17 at 10:02

What you are proposing is to reduce the disk memory cache to satisfy a monitoring requirement. This is sub-optimal and I advise strongly against doing this. The performance increase from disk cache is probably the best use of your resources, lowering this is akin to removing memory chips from the computer and throwing them away.

What is the monitoring software called? Is it possible that it is reading meminfo? If so, I would look into using LD_PRELOAD (https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick) to disguise the file that it is reading and perhaps change the contents that it is reading to replace the true value free to cache+buffer+free. Without knowing what the software is I cannot suggest any other ideas. Perhaps you could alter $PATH so that a different copy of free is found?

If you go down the LD_PRELOAD route you would be looking at replacing the open call with your own so that if /proc/meminfo is accessed then a modified copy in /tmp/ may be used instead.

| improve this answer | |
  • 1
    Ed says it all. Fix your monitoring instead of breaking your performance. – Thomas Mar 16 '17 at 18:46
  • To reply to Ed, It's Nable. The monitoring will not do anything more granular on Linux. It's total garbage. A ticket has been raised with them, apparently it's in their 'to-do' stack, but has been been for a long time, so basically never we think. There is a chance that the agent is using meminfo. I will look into the LD_Preload to see if that helps. Thanks for the solid suggestion. – FiddleDeDee Mar 21 '17 at 9:54
  • Thanks for the heads-up, I'll make sure not to use that in future. – Ed Neville Mar 21 '17 at 22:22
  • As an aside, this has highlighted something that could be a lot more serious - it's a production system that hasn't been updated for a while (as the RHEL subscription has run out). We are going to get the client to pay the subs so that we can patch it. Once that is done (and back in subs), we can install SNMP and bypass the rubbish agent. – FiddleDeDee Mar 22 '17 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.