Periodically we receive requests where customers asking us about RTC print preview consumes all available memory and computers hangs.
Repro scenarios are more/less similar: run report, click preview, go per pages up/down, close report. Run another report, click preview, go per pages up down and… RTC hangs. If we look to memory usage, NAV is using all available memory.
If we analyze what has happened, we see: with every move per pages memory usage increase and increase and increase until all memory is used. It looks like typical memory leak because in NAV 2009 with the same repro everything is OK.
However it is not so simple. What NAV does in this scenario is: it loads Microsoft Report Viewer 2010 with 2 files: report definition (RDL file where is described report structure) and record set. And that is all, next actions like preview/print/export are managed by report viewer. The same we have in NAV 2009 just it loads Report Viewer 2008 and .NET Framework 3.5 as NAV 2013 uses Report Viewer 2010 and .NET Framework 4.5. And here is reason pointing us to memory usage behavior: Report Viewer 2010 and .NET 4.5 uses another way to manage memory (named more advanced and more secure). However this ‘another’ way gets us mentioned questions from customers and really we can do nothing from NAV platform side – system works as it is designed to work.
But things are not so bad. In .NET memory is managed very smart and not used memory is released by function named ‘garbage collector’. This function periodically review memory blocks and release not used. And actually it works: if we monitor memory during report previewing and after it close we see that in preview and going per pages memory usage increase, after preview close memory usage is still the same, but after 5-10 min used memory decrease to initial numbers. For example in my tests started RTC using 98.5 MB, after few previews and scrolls and etc. usage increases to 215 MB and doesn’t decrease if I close preview. But after few minutes garbage collector returns usage to 100.4 MB. We can force (in NAV platform) garbage collector to work faster and memory release will be faster, but this will increase processor usage and in many cases it is worse than memory usage.
Few trick could help users do not meet memory problems:
New Information since Update Rollup 5:
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Gedas BusniauskasMicrosoft LithuaniaMicrosoft Customer Service and Support (CSS) EMEA
Thank you for bringing this issue and for your comments and tricks to try to resolve this problems, but I don't think we can rely on this as a solution:
1. The interactive features are one of the sales argument for the new reports. Is really the best option to tell the customer don't use them because memory issues?
2. I suppose you understand this is not an option in the vast majority of cases
3. Do you see that what you are saying is that all the big reports (used for instance at end of fiscal year) need to be prepared to be launched on the server? This can be a lot of work for partners, and is very difficult to explain and sell to customers.
NAV has issues with printing and memory management and they need to be solved: we can't tell customers when their reports and NAV hang just try again.
You cannot say that "system works as intented", it doesn't: hanging is not an expected behaviour. Saying that is right "from the poing of view of NAV" means nothing to the customer because they see them from a global perspective.
I hope NAV team can solve this problems.
Unfortunately only way NAV team could do here is to push SQL reporting team and .NET team to add features allows us manage memory in better way. Trust me - we pushing these guys.
Regarding other points:
1. We didn't say: do not use interactive mode. Just if you have report with 50 pages and want to see totals in every page, then better to go to page layout mode and use it for scrolling. That's all - just do not scroll per pages in interactive mode if you want to see only last page.
2. In most cases memory usage is not problem or garbage collector does his job in time. For that specific cases when memory is going out of normal - user scrolls per 100 pages to see something in the end - solution is create pdf and scroll it instead. My personal opinion is that preview report with 100 pages is not needed in any case, it only means that user is interested in one amount or something and try to "control" that. In pdf we can search, mark and etc - preview is just preview.
3. Big reports (end of fiscal year) need to be run on server and saved as pdf - this is only solution. Again my personal opinion: printing 100 of pages and save it is just waste of nature resources (paper) - nobody will ever read it. It could be required by law to print it, but it only shows old and incorrect laws.
So far we have no direct way to allow user to scroll per pages in interactive mode and do not have memory usage temporary increase.
I tend to agree with Xavi. One of the primary purposes of an ERP system is to be able to extract contextual information on what's happening in your organization. If reporting simply does not work in many cases, the ERP system has failed in one of its primary objectives.
There are people that cannot run essential reports in RTC, but they work fine in classic. Whether the underlying issue is the SSRS viewer or not (which it clearly is), the fact remains that NAV is not able to provide information to end users without external reporting tools or work-arounds. Users don't care who within Microsoft is responsible, all they know is NAV is not doing what it is supposed to do. This is really not an acceptable situation and falls directly on the NAV platform team, as that's the group that selected SSRS in the first place. (I'm not trying to lay blame here - I'm simply responding to the deflection of responsibility from the NAV team to the SSRS team).
This specific issue, and NAV reporting in general, is costing customers and partners a lot of money in work-arounds, custom report building, and less efficient access to information. I certainly hope the situation improves dramatically in the next release.
thank you for picking up this issue. Xavi put the finger in the wound, but very politely I must say. This is a really pressing problem, because it is one of the "fit for business use" criteria which means no sale at all when the word is spreading. "Works as designed" doesn't mean anything when it results in "not working" at the customer's site. A little prodding doesn't help here, action is required. Reporting is a major and unfortunately not the only problem with NAV RTC, making the whole package not fit for business use, regardless what the marketing says. The problems have been pointed out by partners for YEARS now.
with best regards
I fully understand you: without mentioned questions your and my life would be easier.
But because reasons laying outside NAV, we (NAV) can't just release fix and close question - we need to wait for SSRS/.NET.
While here is not direct solution, I'm trying decrease your pain with workarounds.
Thank you for sharing this.
I would recommend users to postponed the customer to upgrade their solutions, except if they could accept this "design".
For us server and client is the same, as we use terminal server, so client is installed on the same server and runs from there as the sql server. Still in Classic, in 2009, but will upgrade soon. Does it mean if we do the same thing the users can crash the whole server?????? That would be really bad!
I see here are more doubts about NAV 2013 reports so I will try to clarify few points:
1. Memory consumption hanging only client (RTC), no problems with server/service. RTC is 32 bits app, so can't use more than 4GB (really less) RAM.
2. This article is about memory consumption and later usage when report viewer doesn't release it in expected time frame. With mentioned "update Rollup 5" NAV 2013 uses memory in the same way as NAV 2009 and mentioned problem has gone. So if RTC didn't hang in 2009, there is nothing new in NAV 2013.
3. Mainly memory consumption comes from situation when user tries to preview/print report with hundred pages. In this situation dataset (millions of fields) is loaded from DB and uploaded to report viewer. Everything staying in memory in some moments it becomes not enough. Workaround is to use "server side" printing as service is 64bits and theoretically can manage terabytes memory or reduce printing of big report (nobody reads it, even requires).