7 Replies Latest reply: Jan 29, 2018 4:55 AM by Fabian Otte RSS

    QVS.exe is wreaking havoc and I have no idea why

    Fabian Otte

      Hi everyone,


      I have a Qlikview Server running with serveral Reports on it. Since two days the QVS.exe is sporadically using the CPUs so heavily that the accesspoint gets slow and opened reports don't react anymore at all. This workload stays like this for at least 20 minutes, after this time period I killed/restarted the Qlikview Server Service, because I needed the system back on track for the users to work on it.


      Does anybody know how I can find out what causes the high CPU workload?


      Qlikview Performance-Logs, Windows Event Logs and Resource Monitor only give me the information that there is a high workload coming from QVS.exe, that there is more than enough RAM and that there are not more active users than usual, I get no information about which report/user is causing the workload.


      We did not deploy any new reports in recent time that would explain the sudden change in the servers behavior and on some days the issue does not appear at all, on others several times a day.


      If anybody could give me a hint to solve this mystery, I would be really grateful.

      If you need any further information, let me know.

        • Re: QVS.exe is wreaking havoc and I have no idea why
          Liron Baram


          one thing to look at ,is the sharefiles of the qlikview apps

          sometime a bookmark or an object a user created can cause the share file to become huge

          and in turn they might stuck the server

          • Re: QVS.exe is wreaking havoc and I have no idea why
            Peter Cammaert

            Is your setup allowing "Server Collaboration", i.e. the creation of Server Objects in the AccessPoint? If so, then a simple but badly written expression in a Server Object can run off with all ram and/or cpu cycles. And they may be difficult to spot.


            If you think this could explain the behavior you are experiencing, try to determine when exactly the cpu goes haywire, and who is actively using a document in the AP at that point in time.

            • Re: QVS.exe is wreaking havoc and I have no idea why
              Fabian Otte

              So here I am, back again. After a few weeks of silence, the problems have come back.


              After playing detective for a while I've come to the following conclusion:

              I need to know how much CPU which report is using in the course of the day.

              Is there any way to get this information?

                • Re: QVS.exe is wreaking havoc and I have no idea why
                  Michael Andreasson

                  If you have a lot of reports loaded at the same time there is no good way to seperate CPU usage for each report in my experience.


                  Have had those types of problems and my approach has been to investigate the QV-Eventlogs (or via Governance Dashboard) and try to figure out which report or user has logged just before problems occur. Have had instances when root has been found there but have also had times when nothing obvious can be found.


                  My first approach for getting rid of problems when no apparent reason can be found is to run the SharedFileRepair that comes with QVTools and replace the shared files where there are complaints.

                  • Re: QVS.exe is wreaking havoc and I have no idea why
                    Or Shoham

                    As far as I know CPU isn't tracked at that level. However, there is a CPU_spent__s_ field in the Governance Dashboard that links to a session, so you may be able to pinpoint the problem session and work your way to the object from there.


                    Additionally, several things to look into:

                    1) As suggested previously, user objects that are poorly thought out may be a problem. This is particularly true of detailed charts that may get very, very long when selections are cleared.

                    2) Developer objects may exhibit the same behavior - if you have any detailed tables (pivot or summary), consider a calculation condition limiting the chart to only run if e.g. 10,000 or fewer lines are selected.

                    3) Exporting large tables to Excel is a horrible resource hog even if you can get the table to render in QV. That's something to check the logs for as well, assuming you have audit-level logs.