NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

[luis_pimentel]

Dear Community,

Having the following set up:

- Nprinting June 2019 with two engines. Windows virtual Server 2012 R2 CPU E5-2643v2 3.5 GHz and 128 GB of RAM each one.

One of the server has NPrinting Server and Engine installed and the other has just the additional engine.

- Qlikview April 2019.

Using local connections (not sure if this issue happens with qvp, since these are much more slower), we have seen the following behaviour using this console: https://servername:4993/#/admin/plan

Sometimes, when one or more local connections are running a task, the task get stucked. Normally when is about to finish. After a while, we decide to abort the task son we can try again and continue with another one.

However, as seen in the attached snapshots, the aborted task keep having nprinting cores/resources assigned and in consecuence other tasks can't use that resources. making the enviroment unstable and much morre slower. The only way to release those resources is restarting NPrinting Scheduler Services. But obviously this is not a solution, since this issue is happening basically every day.

Please note that:

- qvw associated to this task meet all requirements and recommendations provided by qlik help (no triggers, no one value selected, minimized objects, etc). Size goes from 10 MB to 200 MB.

- Reports asociated to these task have a high number levels and cycling. Timing of succesfully execution goes from 10 to 60 minuts depending on the specific report.

We believe that high usage of CPU during report execution is impacting Scheduler service, but cant say for sure.

Any ideas?

Thank you.

[Lech_Miszkiewicz]

How many cpu cores you have on engine servers?
Max recommended is 12 per engine or performance will drop

[luis_pimentel]

Hi Lech,

Thank you for taking the time of answering.

As recommended, we have 12 virtual proccesors on each nprinting engine machine. Snapshot attached.

Regards,

Luis.

[Frank_S]

Hi @luis_pimentel 

You may be facing the issue with

• Unsupported QV items as mentioned here: https://support.qlik.com/articles/000026081
• Dedicated NP service account required: Possiblly sharing the NP service account with other NP servers or even other QlikView servers. NP service account MUST be dedicated to running a single NP server only: https://support.qlik.com/articles/000033911

If either one of or both of these are found in your system, then you will need to follow both articles to resolve the issue.

Update: I noticed your response mentions that do not have unsupported items. Please double check those shown in the article as there are other items that 'may' have been missed.

Kind regards...

[luis_pimentel]

Hi @Frank_S 

Thank you for your answer.

Honestly, those articles are longer than last time I read them. So we will double check both in detail again. However I still think we meet all those requirements.

Since you are from Qlik Support, are you aware of a bug or known issue with nprinting as I describe it? 

What is shocking to us is that at this console: https://servername:4993/#/admin/plan we see very ofen many resources assigned to already aborted tasks. It looks that Scheduler is trying to finish a task that was already aborted (and we abort it because it was stuck).

I know my question is not very specific. But I would like to be aware of other knowledge beyond the articles you already share.

We are currently trying the following (in order to relase those cpu cores that seem stuck):

- https://support.qlik.com/articles/000055501 -> add <add key="force-unused-resolvers-closure-policy" value="1" />  to scheduler.config

and

- add <add key="qlikview-resolver-session-timeout-seconds" value="60" /> --> to scheduler.config

Finally, yes, our NP service accounts are dedicated (one for each server) and not shared with anything else. Both are also properly licensed.

Regards,

Luis.

[Frank_S]

Hi @luis_pimentel 

Thanks for the update...it is very good to know the NP domain service accounts are unique to your NP server and QV servers.

However, unless someone from the support desk suggested changing the config file unrelated to any support article:

ie:  <!-- <add key="qlikview-resolver-session-timeout-seconds" value="-1" /> -->

Your change: <add key="qlikview-resolver-session-timeout-seconds" value="60" />

I suggest changing back to the original default especially for the point above. I would also be concerned if other config changes have been made without the direction of our support or R&D teams unless a specific article is written about a specific config update.  Have you made any other config file updates? If so I suggest using 'only' the default values and only changing config files recommended by our articles or directly by our R&D team. Hopefully you have a backed up copy of the original scheduler.config file.

After making the config file change to restore the default mentioned above (and any other config file changes that may have been made), I suggest:

• Aborting ALL NPrinting task executions 
• Restart the QlikView server/Publisher server
• Restart the NPrinting server
• Start execution of your NP tasks.

<add key="force-unused-resolvers-closure-policy" value="1" /> change is supported as you know by article 55501 so this is ok.

Since you already appear to have the recommended number of CPU's (12) you won't need this article specifically but it might come in handy while troubleshooting if the issue persists.

NPrinting how to manage max number of QV.exe (QlikView) and QS reporting_web_renderer.exe (Qlik Sense) in use https://support.qlik.com/articles/000047616

I am not aware of a specific defect regarding this other than the points I mentioned previously but that's not to say you haven't come across something new assuming there are no undiscovered or recently inserted unsupported items into your QVW (we often find that a developer unaware of unsupported items will come along and insert them).

If the issue persists, I would recommend starting a support case so that the issue can be investigated more thoroughly.

Kind regards...

[luis_pimentel]

Hi @Frank_S 

Thanks for taking the time to support.

Following your advice, we just added the

<add key="force-unused-resolvers-closure-policy" value="1" />

line to the config file. No additional changes where made on this or any other config file. 

We also opened a support case to investigate the issue deeper.

Regarding the article:

NPrinting how to manage max number of QV.exe (QlikView) and QS reporting_web_renderer.exe (Qlik Sense) in use https://support.qlik.com/articles/000047616

It might be useful in order to prevent a high usage of RAM consumption to crash the server or Nprinting service. We wont make that change for now, waiting for a response to the case.

I will get back to this post when having a clear view of what is happening.

Thanks again.

Luis.

[luis_pimentel]

Hi again @Frank_S 

I am wondering If we might have an issue with the qv.exe license. Let me explain:

Our Qlikview set up is:

- 1 Qlikview Server Production (qlikviewserver1). -> Used as Access Point, and to lease licenses to users.

- 1 Qlikview Server Test License (qlikviewserver2). -> Used as ETL and for QVP connections from Nprinting.

So, even if we have properly licensed our qv.exe in both NPrinting servers agains qlikviewserver1. Using qvp connections against qlikviewserver2 might be an issue? Even if most of the times works properly.

Most of our NPrinting connections are local, but some of them are qvp against qlikviewserver2. None qvp connections against qlikviewserver1.

Attached, is an spanshot of Assigned CALs at qlikviewserver1. As you can see, both nprinting service accounts are licensed but the Last Used Date is Sep 4th (the day we licensed them). Instead of today.

Attached as well, an snapshot of the connection verification process on qlikviewserver2. If this verification is succesful, can we discard and issue with licensing?

Your inputs are highly apreciated.

Regards,

Luis.

[Ruggero_Piccoli]

Hi,

Did you checked the Qlik NPrinting log files? Are there any specific error?

Best Regards,

Ruggero

[Frank_S]

Hi @luis_pimentel 

I think there can be an issue as I personally have seen that on rare occasions.

As you most likely know, the QV test server can issue licenses but the TEST licenses are not valid for use with NPrinting as they result in a 'personal edition' message when accessed by the QV desktop that is running on the NPrinting server. 

Now if you use 'dynamic' leasing on your test server I suppose in some cases there might be the opportunity that the NP service account 'leases' a test license. This is not desirable for the reason mentioned above. This will cause NPrinting to hang/fail since a valid PROD QV license is not in use. To avoid the possibility, I would recommend turning off 'dynamic' leasing on the QV test server and using manual leasing on the QV test server 'if' dynamic leasing is enabled.

'If' you are have had problems losing the valid PROD license for either of your NPrinting service accounts, you may wish to consider using a QV desktop license manually installed directly on the QV desktop on each of your NP servers (while logged on as the NP service account. (See the dedicated NP service account article I posted earlier).

Again, this is a suggested option for you whether you are losing a QV CAL or not. This suggestion would ensure that the NP service account always has a valid dedicated QV license and thus eliminating license as a possible issue.

Hope this helps...