Nprinting server -> Qlikview not returning memory

[Marijn]

Hi all,

I'm having an issue where theQlikview processes on NPrinting server is not releasing the used memory after a finished task. This means that Qlikview processes are being stacked, which uses an increasing amount of memory until the server crashes and none of the tasks finish.

Some details:
Server version: Qlik NPrinting May 2022 SR4, Version: 22.15.14.0

Qlikview is used as a local instance, so no qlikview server. We also use connections with a QlikSense server, but no problems there.

This is the task manager after succesfully finishing all tasks, so there should be nothing running:

I hope someone else experienced this issue and found a solution!

[Ruggero_Piccoli]

Hi,

This is Work as Design and already discussed here in previous conversations. It is an optimization made to minimize the reports generation time:

- the first time you ask the creation of a report based on a .QVW it will be opened in a local QlikView Desktop instance. A process Qv.exe will be start.

- the reports are generated

- if needed more Qv.exe process are opened 

- at the end of report generations the Qv.exe reports stay alive to avoid to wait opening time next time you will request more reports from the same .QWVs. If needed the Qlik NPrinting Scheduler will close the exceeding Qv.exe process.

Note the in the Qlik NPrinting Scheduler and Engines computers you must install only NPrinting so that RAM is kept in use for its needed. 

Best Regards,

Ruggero

[Marijn]

Hi Ruggero,
Thanks for your quick response. We encounter problems with the NPrinting services freezing multiple times per week, with the only solution to reboot the server. Manually shutting down the Nprinting Engine does not work, it says "stopping" indefinitely. Do you have an idea where to look for the problem?

[Ruggero_Piccoli · Accepted solution]

Hi,

You can check the article  https://community.qlik.com/t5/Official-Support-Articles/Force-NPrinting-to-automatically-close-idle-...

Best Regards,

Ruggero

[Lech_Miszkiewicz]

Hi @Marijn 

Are you using Local or Server/Claster connections when connecting your QlikView documents. Using local connection would be a main reason/poor design of memory issues like that.

cheers

Lech

[Marijn]

@Lech_Miszkiewicz 
We use a clustered server that shares drives. So the NPrinting Server is in the same cluster as the QlikSense server. All the QVW files are on the shared server drive. We do not use any QlikView servers.

More or less this:

These three servers are within one domain:

[Ruggero_Piccoli]

Hi,

In short in Qlik NPrinting you configured local QlikView connections. Correct?

In that case all QVWs used to create reports are opened on locally on the Qlik NPrinting Engines computers. If you generate multi-doc reports all involved QVWs are opened at the same time and uses RAM. 

Best Regards,

Ruggero

[Lech_Miszkiewicz]

Ok, all I gathered from this is that you are using "LOCAL" connection to qvw meaning that your NPrinting server needs to be able open as many instances of largest QVW as many CPU cores it has. Since you are using QlikView connection you should not have more than 12 CPU cores per Engine anyway as documented here: https://help.qlik.com/en-US/nprinting/May2023/Content/NPrinting/DeployingQVNprinting/Performance.htm

Since those are LOCAL connections there is always risk of running out of resources - having a QlikView server would be right solution as load would be balanced better at that stage. With local connection you need to calculate max size of largest app in RAM + RAM required to easily calculate objects in those qvw's and multiply that by number of CPU Cores you have on the server which as mentioned before shouldn't be larger than 12 per engine anyway. That would give you minimum required RAM to support your setup. Then add extra RAM on top of it to support any operations, file saving processes, distribution and OS. 

Bottom line - this is not best design and I always say that LOCAL connections should only be used to support very small qvw files and for larger apps I always suggest server - sorry 

[Marijn]

Hi @Ruggero_Piccoli and @Lech_Miszkiewicz 
Thanks for your valuable insights. I have implemented that the server forces to close idle processes. The first week has had no hiccups so far, so we've decided to wait and see whether this solves our issues until the first week of September. If this does not solve the issue, we will lower our number of cores to 12 (now is 16, we didn't know about this limit). RAM shouldn't be a problem, there is 128GB available.

[Ruggero_Piccoli]

Hi,

About the number of cores: it is a matter of performances. You can use how many cores you want also with local QlikView connections but adding more over the suggested number the performances will not grow any more in a linear way; they will grow less than linear. So it is more convenient to create two engines that adding the same amount of cores to a single Engine. 

I suggest you to check also the usage of RAM, in particular if you are using QVWs with huge size.

Best Regards,

Ruggero