Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
hartleyr
Contributor III
Contributor III

Undersatnding Server Usage

Hi All

Can somebody help me understand the numbers we are seeing consumed on our QV Server....?

I'm using the governance dashboard fro analysis, and information available out there on what MBytes Sent + Rec'd and Session Calls are, is all very woolly, but I understand that these two numbers will show me the highest consumption from my users....

I've attached a screenshot of the top several consumers of Mbytes for the YTD.  My main user (user 1) of MBytes consumes several reports through out the day and  sends around half to print, once daily.  This to me, is normal usage for their position

User 1 has used 315MB and has had 98k session calls

User 2 has used 207MB and 78k of session calls

User 3 has used 93MB and 3k of session calls

Can someone please advise;

1.  What are these two fields actually representing?

2.  Why would user 1 be consuming over 3x more MBs than user 3

3. What kind of activities on QV are going to have an impact on these numbers? 

The range of MB and Session Calls ranges vastly (we have x26 consuming less than 1 MB, x44 consuming more than 1MB and less than 10MB and x38 consuming more than 10MB).  Our 2 biggest consumers of session calls however are using 6MB or less (session calls are 102k and 131k)

Any light that can be shed on this would be greatly appreciated

Cheers!

Rebekah

Labels (6)
3 Replies
Josh_Berg_Support

Rebekah,

Memory consumption in Qlikview is caused by caching datasets and results when users filter data on the QVWs in the Accesspoint.  Each time this occurs, that data is written to server memory so the next time a users performs the same action, the results will be shown quickly.  If User 1 is making more selections and thus filtering more data than User 3, that would explain the difference in memory consumption.  You can see this by the difference in session calls 3k vs. 98k.  

Are you concerned with the amount of memory Qlikview is consuming in your environment?

Thanks,
Josh

Qlik Support

To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
hartleyr
Contributor III
Contributor III
Author

Hi Josh

Thanks for your response

Memory usage has been somewhat of an ongoing concern.  We appear to have it mostly under control, but we are still seeing the server spike in memory at least once a month.  In most instances the server manages it by restarting the engines, however we have also seen it crash the server

This query was raised for such an occasion and we were trying to establish route cause.  The general pattern of usage is that the server will restart all services at 4:15am, thus clearing any memory being used.  The users then start usage from around 5am and the memory grows steadily throughout the day, reaching on most days around 45GB on a 60GB machine

On this particular day, the server crashed at around 2pm having reached around 57GB.  it had climbed from around 20GB at 12pm to 40 at 1pm and 57 at crash

This was one route we were exploring.  It was, the beginning of month/year end, but in terms of the impact of these users, their usage was high, but I'm reassured that they were doing their normal day to day work (looking specifically at 1 day rather than month/year(s)...?

 

Since the issue on the 4th April, we have seen 3 further spikes in memory, however these have not caused the server to crash.  We have however, increased the paging file from 800 to 10000MB to see if this has any impact

Brett_Bleess
Former Employee
Former Employee

So the first key point you must understand is QlikView Server cannot make use of Disk Page File space, anything that is actively in use in the server must reside in physical memory, so increasing your Disk Page File size is unlikely going to address any of your issues here, it could potentially make them worse actually.  

Please see the following Support Article which should help explain resource usage on the server quite a bit better:

QIX Engine Memory management and CPU Utilization

There is an attached pdf you will want to download and read through, but that should give you a much better grasp on resource usage etc.

So, to your last point, the spikes, these are most often related to applications that have data model or expression related issues most of the time, or if you are allowing users to create their own server objects, it could be something a user has created as well, as if they do not understand the data model the expressions they end up writing may create massive Cartesian Product calculations etc.  Finding these can be a bit tricky, but generally using the QlikView Server Audit Logging feature can help in these cases, and in the November 2018 track, there is also the new QlikView Server Telemetry logging which can be very useful as well.

I would likely recommend you highly consider working with our services organization to consider having a consultant engage with you to an environment and app review to help you review the applications to be sure things are efficient and the environment to be sure you have used all the best practices in configuring things.  This is about the best I can do at the moment, if you have further questions, feel free to leave them, I will try to get back to them as quickly as I can, but sometimes it can take me a while depending upon what else I have on my plate.  Hopefully this does help though.  Oh, I did almost forget to give you the Help link to the logs and fields and explanations too:

QlikView logs and field descriptions

This should help with your other questions, the ones you were trying to find are in the Performance Log just FYI.

Regards,
Brett 

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.