Qlik Community

Qlik NPrinting Discussions

Discussion Board for collaboration on Qlik NPrinting.

Announcements
Attend QlikWorld 2020 and hear keynote speaker, Malcolm Gladwell. Register by February 29th to save $200. Learn More
Partner
Partner

NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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.

Labels (1)
1 Solution

Accepted Solutions
Highlighted
Partner
Partner

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

Hi,

First of all, thank you all for all the suggestions and good advices on this topic. Everything was very helpfull to improve stability and performance in our reports.

However, unfortunatelly, R&D team has identify 3 issues/bugs affecting us (classified as OP-8457, OP-8394 and OP-8871). Let me paste R&D comments below: 

  1. OP-8457 (resolved on coming NPrinting November 2019)  -> RabbitMQ requests got lost because the engine was unable to send them back to the Scheduler (for some reason RabbitMQ broker closed the channel, hence the error you see in RabbitMQ logs).
  2. OP-8394 (I guess related to previous OP-8457) -> The fact that the 4 lost requests remained there even after an abort is known to me but is part of OP-8394 improvement that has not been planned yet. In any case essentially this does not produce any practical issue for the customer, just a theoretical very small performance degrade, probably difficult to measure, due to sub-optimal scheduler allocations (the scheduler thinks that there are four requests to resolve on that connection and so once in while, depending on starvation mechanisms, allocate one or more resolvers for them).
  3. OP-8871 -> qv.exe gets stuck sometimes. workaround is a script that could start every 20-30 minutes to clean up potentially stuck qv.exe

 

Let me clarify that (after many performance improvements) currently these issues only affect to certain documents.

If you guys have any additonal input on these JIRA issues, please let me know.

 

Regards,

Luis

View solution in original post

22 Replies
Highlighted

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

How many cpu cores you have on engine servers?
Max recommended is 12 per engine or performance will drop
cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
Highlighted
Partner
Partner

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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.

Highlighted
Support
Support

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

Hi @luis_pimentel 

You may be facing the issue with

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...

We are just 'like' you & like to be liked when we provide a helpful answer and or when you press the 'Solution Accepted' button if an answer provided resolves your question or issue... Cheers!
Highlighted
Partner
Partner

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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.

Highlighted
Support
Support

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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...

 

 

We are just 'like' you & like to be liked when we provide a helpful answer and or when you press the 'Solution Accepted' button if an answer provided resolves your question or issue... Cheers!
Highlighted
Partner
Partner

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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.

Highlighted
Partner
Partner

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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.

Highlighted
Employee
Employee

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

Hi,

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

Best Regards,

Ruggero



Best Regards,
Ruggero
---------------------------------------------
When applicable please mark the appropriate replies as CORRECT. This will help community members and Qlik Employees know which discussions have already been addressed and have a possible known solution. Please mark threads with a LIKE if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads with LIKEs if you feel additional info is useful to others.
Highlighted
Support
Support

Re: NPRINTING ENGINE CORES ARE ASSIGNED TO ALREADY ABORTED TASKS

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...

We are just 'like' you & like to be liked when we provide a helpful answer and or when you press the 'Solution Accepted' button if an answer provided resolves your question or issue... Cheers!