thanks for the information, but at the moment I'm generating only one template (Powerpoint, 15 slides; each slides with one picture from QV) for our branches (~150). I'm using 8 tasks to group the branches.
What is the cause that the nPrinting process exceeds 2GB? (Amount of tasks, amount of images etc.)
How can I prevent that this happen?
So if I understand it correctly you create ~20 ppt files in one task? And you run 8 tasks in one job?
When exactly does it fail? It would be interesting to see the memory consumption over time as these are generated.
Also test if it fails when generating for a single branch.
I have ppt template with 25 pages (Images + tables) which is generated for 9 recipients in one Task. It runs for 50+ minutes and creates 9x ~1MB files as output and it runs without problems. How big is your output?
I have found mention of Out of memory in other post but it is for pdf Output from xls-ppt template.
...we typically use Excel and Power Point for generating output as I find it is the easiest to setup. Both of these will allow you to store your output as PDF, although I have found that their is a page limitation of 60-70 before it runs into conversion issues and runs out of memory.
I have 15 QV-Chart as images included in that PPT-File (all together 20 slides; size 3,5 MB)....
I have 8 jobs with 1 task included (before I tried 1 Job with 8 tasks, but the behavior of nprinting was the same).
Each Task has avg. 17 recipients. So at the end I get 17*8 Powerpoint files (for each branch of our company one presentation with their data).
When the scheduler is running, I was always checking the task manager. When the "out of memory" incident happen, the nprinting*32-process was using 1GB RAM. This happened after 3 hours running after 70% of all the files were done. If I'm running each job one by one (manually), I have no problems.
We do not have the server - we use only designer. So I cannot be much help with that.
Only thing that comes to mind - if one job runs fine - try to schedule separate jobs and spread them so that they do not run directly one after another. Maybe nprinting will release the memory after the schedule finishes.
Anyway, your best bet is probably directly contacting support.
Hello, please see Article 000045598 in Qlik's Support Portal.
The error " System.OutOfMemoryException " seems to happen because the process is unable to find a large enough section of *contiguous* unused pages in its virtual address space to do the requested mapping (not because of the total amount of memory, but rather contiguous unused space), or because a directory or template path is no longer valid. This may cause a memory leak. If the logs do not show an error related to "output producer", than it's usually because of the former.
The error "Error: QlikView NPrinting can't find a supported reporting output producer for the file" in the NPrinting logs demonstrates that there is a directory or template path that is no longer valid, or there is a duplicate template, as these will cause memory leaks... and the customer should update the path.
If you encounter an issue where the NPrinting execution remains in a running status forever, this was a bug (OP-5692) in NPrinting, and the resolution is to upgrade to the November 2017 release or newer. In summary, the report preview execution remained in "running" status forever due to an un-handled and not logged OutOfMemoryException error in Qlik NPrinting Scheduler, which is fixed, and an NPrinting (and QlikView/Qliksense) update to the latest version should be performed.
If the QlikView services are crashing when NPrinting tasks are executed, then it's likely that your QlikView documents are extremely large, charts are maximized, etc... so QlikView Server uses a lot of machine resources and it goes down right when the request from NPrinting is sent. You should try to schedule NPrinting when the Server has more resources. NPrinting uses the QlikView Desktop APIs. If the QlikView Server can't get back to QlikView Desktop, NPrinting shows the error.
Finally, ensure that the .NET Framework is updated, as Microsoft has confirmed memory leak issues which are addressed in the latest releases of the .NET Framework.