Do you have Cache to burn?
March 17, 2016 /
0 comments / in
Support
/ by Jacob Allred
Do you know how to tell if the cache on your machine is being used properly for your CygNet services? What are the effects of a rampant cache growth? We in CygNet Support have not only had to troubleshoot these issues, we’ve also found the tools needed to diagnose and fix these issues.
As many of you already know, cache is used to speed up processes by storing data that is constantly retrieved in memory instead of hard disk. This allows processes to access the information they need more rapidly than having to fetch from disk. The act of creating and managing disk cache is something that operating systems manage and, as it turns out, might be doing a lousy job of it! Sometimes the operating system will load a CygNet service’s entire index into memory. This can cause other processes to be completely starved for memory. If your business critical application are starved for memory then it’s highly likely that they will stop functioning properly.
So how do we correct this issue?
Is the File System Cache doing a bad job caching my CygNet service data?
The tell-tale signs that something is up is if the system is using more memory than you can calculate in Resource manager or Task Manager. If this happens, then you should use the RAMMap utility to determine what is actually occurring with your Ram. This utility will show you what is being housed in the File System Cache.
How do I limit the File System Cache?
Once you know that your CygNet processes are being stored improperly in memory via the File System Cache, you can address this issue by adjusting the amount of File System Cache that is available on the server where your services are running. To do this, you can simply Compile an application that calls the SetSystemFileCacheSize function. Or if you’re lazy (like me), you can let someone else create an application to do this for you (be sure the application matches your system architecture i.e. x86 vs x64). Also, this setting must be re-set each time the system restarts.
There’s a UDC available in 8.0, SVMTFSCASH, that lines up to the perfmon item Memory\System Cache Resident Bytes. SVMTHRDFLT (total hard page faults) is present in 7.3.0 and later that increments each time a page of memory had to be read from/written to disk. Both of those items should be tracked over a long period of time when altering the cache size so you can observe the effects of modifying the cache size alterations.
Share this entry
