Multiple QVBs spawned on QDS nodes with only a single reload resulting in Task failures

[sanchayan]

Hi all,

The subject is not quite self descriptory, the scenario is that we have max QV Distribution engines set in QMC as 6. But recently we have changed the non-interactive Windows station heap size to 4096, so that to reduce the reload time of several large size documents which we have.

The changes were done in : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows

              SharedSection=1024,20480,4096 Windows=On SubSystemType=Windows

              ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3

              ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off

              MaxRequestThreads=16

Now the issue we are facing is that, though only one or two tasks are load balanced to one QDS node but in task manager its showing about 15 QVBs running simultaneously. Yet we are not allowing more than 6 simultaneous QVBs in QMC. As a result of which when other tasks are triggered to reload, those are failing to start as already more than 6 QVBs are spawned on the node. So why and from where are those 12-13 extra QVBs getting spawned even though only 1-2 tasks are being executed on the server node.

FYI : We are having a cluster of 4 QDS nodes, all are 64-bit and having 20 Processors & 20 cores i.e. 1 core/processor.

mbaeyens‌     p.scheurich‌

Please help.

Thanks,

Sanchayan

[Miguel_Angel_Baeyens]

I would strongly recommend to deal this directly with Qlik Support.

As a first step, increase the Logging Level to "Debug Logging" for the QDS, run manually the task or chain of tasks which causes the error and verify, you will see which process has each task running, and which user started it.

(2017-12-11 17:32:36) Information: Opened the QlikView Engine successfully. ProcessID=2364

If you have several CONNECT statements or you are using NPrinting, this could be one cause.

I have not experienced this behaviour in either bare metal or VMWare VMs or AWS instances. We sometimes also run out of engines, but because we have a lot of tasks running at the same time.