Hello all!
Anyone experienced issue with memory on nav2015 instance where in some point in time memory consumptions goes to 100% in short cycles (3-4 times in a minute) where only solution is to restart instance?
This is separated instance for 30-40 users, no soap, no nas, rtc only. First I thought it was due to background sessions (report inbox) but last time I found no open bsckrgound sessions. That means that some user started aomething that caused memory to goes up&down in which time users experienced low performance.
There is no .net customizations, (Ivl read somewhere that .net in loops could leak to sort of memory leak).
SQL on separated server in that time did not experienced issues.
0
Comments
They are experiencing slower performance. NAV is not halted but visibly slower.
When I checked memory graph it looked like saw.
we are experiencing the same issue from time to time where memory consumption is doing a kind of pumping between 3-4 GB and 10-12 GB (max. server memory). We are on 8.00.46765.
We first thought it could be some kind of improper DotNet usage, but now we assume it is extensive use of temporary tables in a process. But we are still not finished with the analysis as this is a production environment...
What build are you running on?
Carsten
==> How To Ask Questions The Smart Way
This post is my own opinion and does not necessarily reflect the opinion or view of my employer.
It is definitively cause by excesive memory consumption since first couple of times was due to badly written report which was producing huge dataset for RDLC. After he was executed as background report to report inbox instance showed the same behaviour.
As for temporary tables, "Rows in all temporary tables" performance counters could help to trace it, maybe.
In our case it originated from re-opening a page from the page itself e.g. after posting a Sales Order from the Sales Order Card (Page 42) you re-open the same page. If the same user did this over and over the user session on the Service Tier would start hogging memory.
I was able to replicate it with at simple button on at custom page that just re-opened the page with the same result.
In our case we managed to avoid the issue through handling the re-open from the list page instead of the card page.
Thanks for the suggestion regarding "Rows in all temporary tables". We already have implemented monitoring for this value. Unfortunately we are not able to track it down to a specific user or process. We have 6 NST with around 70-80 users on it and knowing the NST is not enough
Carsten
==> How To Ask Questions The Smart Way
This post is my own opinion and does not necessarily reflect the opinion or view of my employer.