Does match script in the VSI cause any memory leak in a customized VS?
Unfortunately, no, I can't think of anything short of testing each VS individually.
I was unable recreate a memory leak with a very simple VS with a match script. However, what I did notice is the VSE memory utilization climbed from 800MB to 1.6GB. This was with a thread capacity of 1. It leveled off at 1.6GB, so there was no leak. But, if goes to show how much heap was required. What is the heap setting on the VSE where the problem is appearing?
A few quick thoughts...
If it's a relatively old version of DevTest, there's a known defect in the BeanShell library (although a fixed version is available).
If OutOfMemoryExceptions are occurring, there should be a heap dump. A heap analyzer should ID the culprit object (and point to the source of the leak).
How have you determined it's a memory leak and not just memory demanding? Does increasing the heap allocation make the problem go away, or does it just delay it?
How have you determined the match script is the cause?
The VSM was created with older versions of DevTest( 5, 7, 9) and migrated to 10.1.
hprof file shows memory leak suspects as bsh.Interpreter and bsh.NameSpace.
Thanks. 10.1 should have the corrected version of BeanShell.
Nevertheless, the leak suspects still point to BeanShell. Can we get access to the project?
I agree, if we can get access to the project, we can review the script.
Thanks Mike, Surya,
This issue happens when a load test is performed against 10+ VSMs. All services are customized with match scripts.
Do you know of a way we could filter which VS might be causing the issue, or would we need to test each service?
My thought on using match scripts for virtual services is only suited for supporting functional testing.
What is being done in the match script? In my experience the same can be achieved by moving the logic to a custom DPH which being a compiled code would reduce the resources required on VSE.
Thank you, Mike.
I was able to replace all the magic dates for a specific date and run the tests again.
This time we could run the complete load test for hours and there were no memory issues.
We have engaged our team to look at it.
Retrieving data ...