Opening table in accesspoint slow.

[kris_vliegen]

Hi All,

We have a Qlikview-server with 128 GB of ram and Qlikview11.20 SR17 installed. Reloading data and accesspoint is all on the same server.

We also have about 30 dashboards that are reload several times a day. Now I have a dashboard of about 850 Mb. and sometimes a specified table is loading very quick in the access-point and sometimes it takes minites to open that table.

I've no Idea what I can do or where I have to search how I can find why sometimes the server reacts slow. (70% of ram was uwed when it was slow)

As you can see in the pictures, it keeps turning.

Who can help me with this?

Regards,

Kris

[marcus_sommer]

There are multiple reasons possible. One might the used working set limits of the  server the max. might be set to 70% and then the server hasn't enough resources. Another look could go to the fact if the document is already loaded within the RAM if the application reacts fast and slow if it needs to be loaded at first - maybe the pre-loading option might be an alternatively.

Another check should go to the data within the application - if it always (nearly) the same number of records and/or are always all essential fields and associations properly loaded. For this you could compare the document-logs.

Quite helpful could be further the use of the governance dashboard and various tools from Rob Wunderlich like the document analyzer and the script log analyzer.

- Marcus

[jerrysvensson]

If you reload during the day it will affect the performance also.
I would recommend setting up a separate publisher machine for reloads.

[Brett_Bleess]

Marcus and Jerry are on the right track here, it is most likely you are running into resource issues, and I just wanted to clarify a few things for you.  When you run all the services on the same box, you may need to adjust the QVServer Low Working Set limit from its default 70 percent downward to be sure the OS can get the resources that may be needed for the QDS to perform the reloads without 'forcing' the OS to use disk page file space, which QDS will have no issue with, and as you know, this will bring the server performance into a very poor state while all that disk swapping is occuring, so that is one thing to dig into.

I agree with Jerry, if you are doing a lot of reloads during the day, and you have a Publisher license, you can move the QDS to its own server, and that can be a virtual machine etc., just be sure the proper resources are allocated to it if you go that route.  Be sure those resources are allocated at boot of the VM as well, dynamic assignment will be too slow.  

Both the QDS and QVS services are the resource hogs in the environment, so splitting those out is a good thing to do if you can to ensure they are not causing each other issues and causing poor performance for the users.  

Just to circle back on the QVS Low Working Set Limit, that is the guaranteed memory the QVS service is allowed, and it does not have to give that memory back to the OS, that is why I suggested dropping that to say 50 etc., to see if that may get you back on track in the interim.   If the QVS is just using a chunk of memory for caching things, that will just mean we drop things from cache sooner versus later, which may or may not impact performance depending on whether those cached items were still any good.  

Hopefully this makes a little sense, and helps explain things a bit further.

Regards,
Brett