Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Server Memory usage

I'm facing some issues concerning the memory usage of QlikView publisher Enterprise. We have been monitoring our server and the results show that even if we have physical memory available, QlikView uses virtual memory without releasing it. Does anyone know how to manage this?

On the other hand, we know that Qlikview server/publisher Enterprise has a limitation in terms of how many QlikView engines can be created simultaneoulsy, we use to think that this matter was associated to the amount of CPU available in ther sever, but after updating the server we now know that we can only have 9 qlikview engines running at the same time, does anyone know if this will continue or if there is a patch that can enlarge this number?

Thanks to any recomendations.

21 Replies
pablolabbe
Luminary Alumni
Luminary Alumni

Stefan,

This limitation still apply to Qlikview 10 ?

How its possible to track QVB.exe memory Usage using Qlikview Small Business Server ?

Thanks.

StefanBackstrand
Partner - Specialist
Partner - Specialist

Yes, it is. The setting in the QEMC is still there as well, so this can be controlled.

Qlikview Server (or Publisher) does not log performance data for tasks running - that you have to do yourself for now. That is not a licensing setting either.

Not applicable
Author

Lars or Stefan,

Is that Microsoft COM limitation (to the number of simultaneous qv engines) per server or per Execution service or per Publisher? We have 4 XS, one on each of our 4 identical servers. Are we limited to 10 qv engines or 40?

(We've been experieincing issues with jobs repeating themselves across XS. See http://community.qlik.com/forums/t/33239.aspx)

Thanks!

Tyler

StefanBackstrand
Partner - Specialist
Partner - Specialist

Tyler, the limitation is per system. Not per Qlikview system, but per Windows server system. If you have 4 Publisher servers, you should be able to spawn ~40 (or slightly less) simultaneous QVB's - 10 per system.

This is for v9, in 8.50, I am not that sure actually.

Not applicable
Author

Hi,

The strand started with concerns over use of RAM. I have 12 gig of RAM and the error message I am seeing in the logs suggest that the service is only using 2 gig of VM. The logs give a warnig when using our larget app of 250 Mb on a qlikview plugin saying working set nearing limits. The set is 75 to 90 with 10 5 cache and it says 1.49 gig is nearing the limit.

Really need a pointer here as the task manager ays that there is 10.5 gig of actual RAM not being used?

Following the above a disconnection occurs and the PF usgae drops back down

Please advise?

Mark

StefanBackstrand
Partner - Specialist
Partner - Specialist

/red. Wrong thread.

StefanBackstrand
Partner - Specialist
Partner - Specialist

amadeus132;

It sounds like you are running on a 32 bit server - is that correct?

Also, if the QVS log verbosity is set to high - please find the "WorkingSet:" prefixed rows that states how much memory QVS reservs for usage at service startup, and post it here.

Not applicable
Author

Hello,
if you're using a 32bit Windows system, it's completely normal because it's able to manage only 2GB per process. If it's your case, you've to install a 64bit Windows system and it'll be able to address all memory you've on your machine, hope help, Regards.

Not applicable
Author

I've also had some (similar?) problems:

I have recently found an issue with a single CPU server at a client site where a model refresh task (10-15 files x 5-10mb in size) did not complete.
After some testing I found that when running .cmd files which are linked to .vbs calling the distribution service, that the following occured:

A) Batch task containing ODBC data loaders worked fine (30 x 100kb qvw's)
B) Batch task containing Non-ODBC 8 x 100kb qvw's worked fine

C) As soon as a 900kb .qvw was added to the above refresh task this model would not reload

Other factors to consider are:

1. All batch tasks (regardless of .qvw file size) works fine when executed manually in Windows Explorer but not through the QVS?

2. Multiple QVB's are spawned at one time - causing problems for the one CPU - I did not have the option to change the number of QVB's spawned as suggested in this thread at:

QEMC > Distribution Services > QDS@machine > Advanced.

Must the server be enterprise-level to change this setting?

What techniques can be used to overcome this issue without adding further CPU's?


Not applicable
Author

We regularly run 16 simultaneous reloads without any problem. You have to change the Desktop Heap settings to go past 9 or 10. See below, which was sent to us from QlikTech support.

Currently we're trying to use even more cores, but can't seem to go much past 16. Supposedly this is a COM/MS limit, but I don't have the original source for this information.

------------------------------------------------------------------------------------------------------

Desktop Heap

There is a workaround to get you past the limit of 9 engines for distribution and since you are running mostly EDX tasks this might be worth trying.  Then you can set the number to 16 or less.

**Please note this is a Microsoft function not supported by QlikView**

There is a workaround and you can employ this at your own risk as it involves changing registry settings for the OS:

There are some registry settings you can change to increase the number of com communication threads allowed per machine.

Change the registry key and restart the server

ComException error 80080005 Solution

Change the registry setting:

            HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

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

               SharedSection=1024,3072,512 Windows=On SubSystemType=Windows

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

               ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off

               MaxRequestThreads=16

(Default is 1024,3072,512 in 32bit or 1024,3072,768 in x64)

Read more on http://blogs.msdn.com/ntdebugging/archive/2007/07/05/desktop-heap-part-2.aspx

To:

Change the GDI and User handle max count in the registry to SharedSection=1024,20480,2048

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

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

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

               ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off

               MaxRequestThreads=16

Read more about Desktop Heap on:

http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx