You’re offline. This is a read only version of the page.
Hi,
I would like some ideas please on what could be causing this behaviour.
On two different servers, for different customers they are both on-premise and the customer's have opted to self-manage their own servers and are both 2 tier.
System 1:
SQL STD 2014
NAV 8.0.37874
Windows Server STD 32GB RAM
~25 concurrent users
Baseline CPU usage ~ 7% and RAM 35%
System 2
SQL STD 2012
NAV 8.0.37874
Windows Server STD 123RAM
~60 concurrent users.
Baseline CPU usage ~ 15% and RAM 60%
Neither machine is pushed for resource.
What is happening is on the main Windows NAV service. Both customers mainly use Win client. What I am seeing is large fluctuations in RAM usage on this service, increasing from around 4GB up to around 24GB in incremental steps over the period of about 2 or 3 seconds, it will stay high for a few moments before largely reducing in a similar way. This happens over and over again two or three times a minute.
When the RAM usage is pushed high, it is not necessarily utilising all available RAM in the system and the CPU utilisation is not spiking in the same way at the same time although Hard Faults increase dramatically as well.
Customers report that NAV performance is affected.
I have run some performance monitoring and the main metrics appear healthy (Disk IO, other than the ram usage on this service.
Restarting the service appears to resolve the situation for a little while, probably until someone runs the same process within NAV that is causing the issue. I have briefly examined some trace data from the server at the time this was happening. I identified a user session that was running a lot of queries comparatively but when I ended this session alone, the problem did not go away.
Generally, I would think that if the RAM is available to be used then a process is welcome to do so, that is why it is there. However this is definitely accompanied by sluggish performance. We have other customers with similar environments that do not suffer this issue, but they are on different NAV versions.
The rest of our NAV 2015 setups are managed by us and are either 3 tier or are much more confined by the resources available within the virtual machine and are generally for far fewer concurrent users.
If anybody has any experience of this, and can help me with some suggestions for lines of investigation then I would very much welcome and appreciate the input.
Thanks
Ben
*This post is locked for comments
Hi Ben
Thank you very much on this info and fast reply. I will reply if i solve the problem with CU since I've seen that our CU is pretty old comparing to latest.
Best regards,
Hi Esmir.
For both sites experiencing this issue we had little choice but to perform a CU upgrade. I believe we upgraded to different CU's at different times, but this must have been a version issue, and the CU resolved the issue in both cases immediately. I would recommend just focussing effort on planning that, assuming your experiencing problem with the same build I noted in my query above.
Hope this helps.
Ben
Hello Ben,
I am experiencing exactly the same problem and due to reading your article I am wondering have you maybe solved this problem, since the post is quite older.
Thank you in advance,
Esmir
Hi,
Yes you make good points about background processing. I've checked, and these two machines have the power to cope without problem with background posting in place and they do seem to be set up in this way. However the problem only occurrs once or twice a week, so it does suggest that it is the type of function that you may need to run periodically.
I am hoping if I capture data from the event trace for both systems I may see if there is a match between various tasks running on each server during this period, to help narrow it down to a particular report or codeunit etc, or even a faulty flowfield.
As for NAV version, I don't think the build versions being the same is a coincidence, so I wouldn't be surprised if it is a version issue.
Thanks
Ben
Hi Alexander,
I think the involvement of SQL in this may be minimal. There isn't any real alteration in the RAM utilisation of SQL at the time of on CPU. I ran a couple of quick queries during the affected time to see if there were a large number of locks or blocked transactions and there was nothing of interest at all.
The RAM utilisation is in the NAV service tier itself. I do think it is hogging some memory. When the service is restarted and people begin work again it quickly increases to around 2 - 3GB as you would expect for the number of users, but during the problem the minimum is around 5GB, so I certainly don't think it is giving everything back.
It has occurred to me that this could be happening on many more systems, but because our virtual machines are all tweaked for sql max memory etc to ensure we get good value for money while not going over 90% ram usage, there just isn't the large amount of available memory at any one time to make this issue so obvious. On these systems they have many GB of available RAM free for NAV to utilise.
Thanks for your suggestion
Hi Ben,
Unless your RAM usage is continuously on higher side (Maximum), I don't see any reason of performance issue due to RAM....This is not the case in your scenario...
There are lot of parameters / setup needs to be checked both in NAV & SQL.... Like Inventory Setup for Automatic Cost Adjustments field, Analysis View Card (Update on Posting), SQL Re-indexing, Update Statistics, code review etc.
Try to use Background posting, wherever possible. Avoid running long queries during peak hours, if possible.
Can you please specify the exact processes, that is being mainly affected?
In the past, we have also experienced similar performance issues with our client and applying the latest platform build in live environment has also helped us to an extent. It seems that you are using NAV 2015 initial release. Try to see, if you can deploy the latest CU in the live environment (Only Platform Build) and see the improvement.
Best Regards,
Vishal Salot
Would be interesting to see what SQL is showing at that moment, however normally SQL does not give back the memory it took :-). Try limiting (reducing) memory, available for SQL, and see what happens.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (