We have a customer with converged infrastructure where multiple applications are hosted on one server.
This means, auto-learning mechanism will report popular operations (busy apps) and put the rest (quiet apps) into one All Other bucket.
This means, we cannot define applications in BU as CAS does not see quiet operations.
To get around this problem, we have manually defined regex and static URL's to capture operations we want to report and turned off the auto-learning mechanism.
Recently we found out that manually captured URL's are not aged out by URLAging mechanism leaving a big server cache and DB that eventually (1 year) ages out.
Has anyone come across a similar situation? How did you solve this issue?
This customer is running 12.3.3, recently found that adding operations to BU (Applications and transactions) stops URLAging from aging those operations.
We have a case open for this - SUPDCRUM-8100
That is by design
In general to help you with server cache you could try to set per-SS URL Learning parameters instead of using regexes but if you're adding then any of these URLs to BUs they won't be aged out.
With one exception: if you have many BU definitions set with masks you can add and set _VAS_URL_AGING_CHECK_MASK_ property to 1 on http://<YOUR_CAS>/DiagConsole#/advancedprops page to start aging URLs that are in BUs, but defined using masks.
For "full URLs" added to BUs there is no way to age them.
Ok, so I can age them out if I use asterisk - that is good to know.
As per software service per server - that is the issue we have. We have the same server and port serving multiple applications. So defining software service at server level will only include top URL's of top apps while all quite application url's end up in one All Other box.
Yep we did that, one of the CAS's have 256GB of RAM with 600K server cache. Memory is currenlty hovering around 50GB, our issue is the ever expanding DB that does not age out its URL's.
We are currently monitoring 20+ apps on that CAS, plan is to monitor 300+ apps in the coming months, so coming up with a solution for this is vital, we have other DCRUM customers who are moving in this direction too.