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

Memory Leak Bug on Qlikview Server Version 9 SR 2?

We've been monitoring the Max VM Committed by Day chart on the Qlikview Operations Monitor Server tab for the past several weeks after we upgraded from V8.5 to V9 R2 in early December 2009.. The VM grows each day until it reaches a maximum peak after several days and then crashes the QVS service bringing down the server. Restarting the QVS service clears the VM only for it to start growing again. The process continues to repeat itself. Shouldn't Qlikview swap out VM when it doesn't need it. This looks like a memory leak to me. We have a 64 bit server with 24GB of RAM which should be plenty. We increased our paging file to 12GB, but the VM will grow to that level in a few days only to crash again.

Is anyone else experiencing this problem? Any suggestions? Thanks.

Don Saluga

34 Replies
Not applicable
Author

Hi Stefan,

I am sure that I have done this. The services are running under the account that I am logged in as and I have shown processes from all users

Kind Regards,

Footsie

StefanBackstrand
Partner - Specialist
Partner - Specialist

In that case we need to look at the virtual memory usage - the term "Working Set" implies only physical usage. Download the tool "Process Explorer" from www.sysinternals.com (Microsoft nowadays), and run it. Right click any of the columns and select the columns "Working Set Size", "Private Bytes" and "Virtual Size", under the "Process Memory" tab.

Then, again, sort descending and post the results. Probably you will have a process with a high value in "Virtual Size".

Not applicable
Author

Stefan,

We did have this problem document preloaded at first, but due to the problems we were seeing we decided to remove the preload. Actually in order to stabalize the system we remove the document completely. I have asked for help looking over the application and it is most likely a bad design.

I'll keep you all posted on the resolution on this problem.

Tim

Not applicable
Author

Hi Stefan,

The issue that I am having with the reloads has until today been occuring on jobs that were generated using the publisher upgrade utility as there are a lot of jobs on the Qlikview 8.5 server that need to be ported across to the new server. As a test I took a copy of the directory structure for one of these jobs and recreated the job in publisher on the Qlikview 9 SR 5 server. When I start this job I do not get the memory issue. It appears to only occur for jobs generated using the publisher upgrade utility. Have you or anybody else ever seen anything similar.

Kind Regards,

Footsie

StefanBackstrand
Partner - Specialist
Partner - Specialist

Footsie,

I can't say that I know of any scenarios where a migrated job from 8.50 should be the cause of a memory leak, no. I've seen migrated jobs fail (being corrupt), but not specifically only cause memory leaks.

First, I would like to establish what process is using the memory. Did you follow the steps with Process Explorer, like I described above?

Not applicable
Author

Hi Stefan,

Here is a screenshot of the server process info from process explorer. As you suggested there are some high values in the Virtual Size column.

Kind Regards

Footsie

StefanBackstrand
Partner - Specialist
Partner - Specialist

Yes, but not any that;

1. Rise significantly higher than its own Working Set, or
2. Use ~15 GB of RAM.

QVB memory usage is by design, since that is the process entity performing the reload. Are you still having memory not accounted for, if you continue to look on these values during the reload?

Not applicable
Author

Hi Stefan,

Thank you for all your assistance on this. Some of the other Qlikview Processes (not QVB processes) are up to 20 times their working set limits. Is this of relevance?

Kind Regards

Footsie

StefanBackstrand
Partner - Specialist
Partner - Specialist

Hrm. When looking closer at the "Virtual size" column, it seems that it only shows the reservation of virtual bytes, not the actual allocations. That means the "Private bytes" column is the one interesting here. My fault, disregard the Virtual size.

Well, in that case, does the amount of memory showing in the Private bytes column add up to the amounts you are seeing as "disappeared"?

Not applicable
Author

Hi Stefan,

Thanks again. No the "Private Bytes" column adds up to nowhere near the "disappeared" RAM. The only column that adds up to the 12GB is "Virtual Size"

Kind Regards,

Footsie