QVS - do bad app expressions impact all users on a node?

[rothtd]

I'm trying to ask a very high-level generalized question, so I'm not going to mention my environment specifics. If I have a specific qvw with a poorly written chart expression causing a drag on server resources - will the impact be felt only by users of the specific qvw or by all users on the QVS node? I'm not sure if QVS is able to compartmentalize resources such that apps don't impact each other. Obviously in the extremes everyone will feel the drain (ex: the node crashes), but in lesser extremes (chart expression taking abnormally long to calculate)  will that be felt by all users on the server, or just users of the specific app?

[Sonja_Bauernfeind · Accepted solution]

Hello!

If the calculation begins to drain system resources (CPU/memory), then the entire system will be affected and users will see a performance impact on all apps.

/Sonja

[rothtd]

Thank you, Sonja!

I'm curious if there are any sort of issues would affect one qvw on a node, but not the others? (let's assume qvw has been running without issue for a long time). For example, as memory reaches limits I believe QVS will clear the calculation cache - might this be done for only a single qvw, and hence, cause a noticeable impact for that particular qvw only?

The node in question is experiencing less than average load, but a few users of a qvw A are sporadically experiencing it freezing up (~20 qvws are on the node and no one else on the node is complaining). What seems to be happening is that on the QVS node memory is normal, then rapidly climbs to about ~95%, then after ~5-10 minutes returns back to normal. During this window qvw A stops responding. As users make selections it just freezes up. 

Qvw A has been stable for many years, no recent changes, and there is no real pattern yet. This is very sporadic (a couple of times a month at most) and I can't reproduce it with chart/selection activity. It's possible my other users are seeing the issue and just not reporting it, or perhaps they are doing an activity such that they wouldn't notice the issue anyway. We have ~250 qvws across multiple nodes/timezones, so we do have apps being loaded/unloaded from QVS during this time frame. 

At this point I'm just searching for high-level for suggestions/QVS insights that I can consider while troubleshooting. My mind first went to a bad expression in this qvw or another qvw on the node, but I'm curious what other ideas are out there. Not sure how much time I want to spend on this yet given it's seldom occurrence and self-resolution.

Thanks in advance to anyone with any prior experience/insight! 

[rothtd]

I've looked through the logs and they seem to be suggesting a user is either expanding a large pivot table or exporting data to Excel, which is causing the memory to temporarily spike and then be released. If this is true would this situation affect the users of the app in question, or all users on the node? (this does sound like my situation, but I'm still puzzled by the fact that only users of 1 app were complaining). 

It seems logical that if a user was conducting a massive export to excel from a single app, that other users of that app might feel the impact (due to how the app is only loaded once in QVS memory, and then each user loads essentially pointers to that app). Perhaps this would explain why users of other apps didn't seem to notice (my thought is maybe the export operation only puts load on the app in question)? I admit, I'm reaching my limits of QVS architecture understanding though... thoughts?

Relevant logs from the timeframe:

WorkingSet: Virtual Memory is growing beyond parameters - 102.808(102.400) GB

 IncreaseMemoryQuota: Request Graph::GetChartLayout going MT_HIGH

Other relevant threads:

https://community.qlik.com/t5/QlikView-Management/IncreaseMemoryQuota-what-does-it-mean/m-p/1417660 

[Brett_Bleess]

I would venture you are on the correct track, really need to know what version you are running to try to suggest anything further, if you are not on the latest SR of the track you are running, that would be one additional step to take to be sure you are not hitting something for which we may have implemented a fix.  I have seen a few cases where large exports from a chart in an app did cause some pretty significant performance issues, so the other thing may be restricting the exports to smaller sizes as R&D does not consider us an export engine, if users are simply using us as a means to get data from a backend DB, that is not our intended use case at all, just FYI.  

Here is a Help link regarding app performance you may want to review just to see if this may be part of the issue.  The real question on the exports likely boils down to whether it is an issue in the QVS creating the file, or getting it to the client, as those are two different issues, the latter would likely be network related whereas the prior more CPU/Memory etc.  The other thing you did not mention is whether you have Publisher and if so, are tasks running on the same server QVS is running upon?  If so, that is going to be another potential issue, it would be best to segregate Publisher to its own server in that case.  About the best I have given the information we have thus far.

Regards,
Brett