QVS Memory usage -> Daily restarts of QVS service

[klaus_feldam]

QV 11.20.12235.0

Windows Server 2008 R2 SP1

X64

Memory: 28GB

3x Xeon EON E5530 2.4GHz

10 users

10 QVW documents

<500,000 records

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

We are daily running through the memory ceiling of our QlikView 11 server, with the QVS consuming 70-80% of available memory. At that point, users are kicked off and unable to reconnect as memory utilization keeps growing. It's not until we stop and restart the QVS service that normal operation is restored. This happens every 18-24 hours.

We only have 10 users and 10 QVW documents. I have previously worked in a 250-user QlikView environment with 8 quad core processors and 128GB memory - same problem.

Does anyone have any recommendations to resolve this problem?

If there isn't a solution to this unsustainable daily operational issue and memory 'leak' maybe it is time to finally look at a competitor solution.

After 4 years of using QlikView, I love the product, but can't believe Qlik hasn't found a sustainable solution to this memory issue.

[klaus_feldam]

How frequent are your reloads? It could be  that there is insufficient RAM to support your users accessing the applications, and also running the reload process running during the day.

We have 12 QVWs. 5 reload daily. 6 reload every hour (simple dashboards with max three charts that pulls performance metrics) and one (our main QVW) reloads every 30 minutes.  

I would suggest running an app to view your QV logs and see what RAM is consumed when your reloads run without users accessing the applications, and then how much ram is consumed by user access. This may help identify if the issue is in optimising your load scripts, optimising your chart expressions, or even simply changing your reload schedule.

We are using the Governance Dashboard. I will analyse this closer based on your troubleshooting recommendations.

Thank you.

[Ronnie_Taborn]

2014-05-15 03:21:32

2014-05-15 13:17:53

2

500

Warning

WorkingSet: Virtual Memory is growing beyond parameters - 19.436(16.800) GB

Possible resolutions:

• limit the amount of concurrent sessions allowed
• develop the application(s) for optimal memory footprints
• reduce the amount of Publisher/Server task reloads
• limit application development on the server
• free up resources by disabling other applications
• increase your hardware resources

2014-05-09 17:01:23

2014-05-12 12:14:22

1

300

Error

Session Recovery Failed: An exception (T) occured during create $LASTKNOWNSTATE on document D:\QLIKVIEW\ACCESSPOINT\PATH VOLUME.QVW.

This error message is about file handling and often related to shared files.When QlikView logs out an error into the Events file, it should display the entire error message as a consequence of the exception that has been caught, in the program.
However, some cases in 11.20 SR4 or 11.20 SR5, it just display the first character of the error message in stead of displaying entire error message.

Typically, you can only see a capital T, which does not tell that much about the actual error.

Example: An exception (T) occured during open of Test.qvw

It was intended to show those messages in parentheses.

The file cannot be opened

The file doesn't exist

Upgrade to 11.20 SR6. The issue has been fixed.

[Colin-Albert]

The 6 tasks that reload every hour, do these all reload at the same time, or can their reloads be staggered ? Could you trigger each of these 6 so each one runs after another has completed?

This will reduce the impact of running all 6 at the same time.

[klaus_feldam]

The 6 frequent reloads are all staggered.

They run for 1-5 minutes each and never at the same time.

[markodonovan]

Hi Klaus,

If you are using publisher you could look into moving it to a new server if possible.

This is what we have done here for free some RAM.

Here is some info on how to move publisher:

Re: Publisher install in different machine

Thanks

Mark

http://www.youtube.com/practicalqlik

[#7]

Klaus,

A Couple of ideas, that have helped me.

There is a server option to allow only one copy in memory at a time, this needs to be set if you are doing frequent reloads, and users are connected for long sessions.

also set the qlikview documents parameter

"Refresh Mode when document is Updated on Server" to

"Server performs refresh automatically without any client action"

Does the increase in memory coincide withthe reload of documents?

How much space do the documents take straight after reload without anyone using them?  does the memory utilisation increase rapidly as the users start to use the applicaitons?

Richard

[Ricardo_Gerhard]

Qlikview is a in-Memory produtc, but exists a lot of config to avoid this issue.

I work with Qlikview more than 2 years only in infrastructure scenarios and all tunned servers working fine WITHOUT REBOOT TASKS.

The default installation is a poor config. There are a lot of configs in QMC, documents and files.

[rwunderlich]

It's normal for QVS to use 70-80% of memory, as it will fill it with cached results. This is not a leak. However, you mention that users are experiencing instability so somethings not right. Look in the QVS event log to see if there is an error message for the users being terminated or denied access. Also look for log "Working Set..." messages.

There were some QVS memory fixes on SR6. Are you using Preload by chance?

-Rob

[klaus_feldam]

Thanks, Richard.

I have changed the setting to 'allow only one copy in memory' and will see how that affects users, memory utilization and performance.

"Refresh Mode when document is Updated on Server" is already set to

"Server performs refresh automatically without any client action"

The memory utilization increases gradually throughout the day with usage and reloads. We have had increased usage and increases to the number of reloads through the day, so it's difficult to point to which one is the main reason.

We have had very little changes to the actual QVWs, but can't rule out ineffective scripts, which will be our next priority.

Thanks again for taking the time to respond.

[klaus_feldam]

Thanks, Rob.

Very helpful.