Suspension question?
Hello
I am hoping someone can help me understand what we am seeing in dynaTrace.
In our production environment we am seeing some web Requests with really high Suspension percents (example we have a request that is 100 seconds and 78% is sitting in suspension.). As we look closer at where the suspensions are happening we notice it is anytime we are interacting with the database.
We are here asking this question because we found in documentation that suspension time is in correlation with the GC. Is this suspension hiding something else going on like waiting for SQL to respond?
Any help would be great
Hey Andi,
There's currently testing going on with an application that seems to be exhibiting the same issues you mentioned here. We have a large amount of suspension time that occurs during socketread methods.
Here's a before shot.
And the same shot after we did some tuning to the memory and GC options
It's improved, but we still are seeing some pretty gnarly GC times in the young gen. We recently added more survivor space than is seen above, but didn't get any performance returns from the change.
There is a large amount of unused old gen space now which makes me consider lowering the tenuring threshold so we can begin using up that free space.
Any suggestions what else to do here?
I would take a look at the amount of data returned by your socketreads. You are probably retrieving a lot of data from your external system (Database, Web Services, ...) - and that consumes memory. tweaking memory heap space will obviously help a bit but it doesnt really address the issue in case you really retrieve TOO MUCH data. I would really analyze the data your app pulls in. Maybe this can be optimized. With that you reduce memory overhead and will bring down GC
Waiting for SQL would normally show up as I/O. In your case I assume you see the Suspension time on your executeQuery call - correct?
If you constantly see this then it is an indication that the JDBC/ADO.NET implementation requires a lot of memory to e.g: fetch the results and keep them in memory - this could cause a GC and therefore you see it there. It could however also be that the GC just really kicks in at the time of the SQL - caused by some other component that requested memory.
We have an excellent chapter on our online performance book that explains memory management and how to analyze GC activity. you may want to check it out: https://book.dynatrace.com/content/memory/how-garbage-collection-works.aspx
