web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics NAV (Archived) / Massive NAV Service Ti...
Microsoft Dynamics NAV (Archived)

Massive NAV Service Tier RAM Usage Fluctuations

(0) ShareShare
ReportReport
Posted on by Community Member

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

I have the same question (0)
  • Suggested answer
    Alexander Ermakov Profile Picture
    Alexander Ermakov 28,096 on at

    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.

  • Suggested answer
    Community Member Profile Picture
    Community Member on at

    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

  • Community Member Profile Picture
    Community Member on at

    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

  • Community Member Profile Picture
    Community Member on at

    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

  • Community Member Profile Picture
    Community Member on at

    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

  • Suggested answer
    Community Member Profile Picture
    Community Member on at

    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

  • Community Member Profile Picture
    Community Member on at

    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,

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics NAV (Archived)

#1
HoangNam Profile Picture

HoangNam 7

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans