8 Replies Latest reply: Jan 6, 2010 6:45 PM by Gustav Guldberg RSS

    Server Virtual Memory Leaks until system become nonresponsive

    Marc Morris

      We are running Qlikview Server 9.0 32 bit in the Community Server model.

      Installed on a VMWare ESX server on a Window 2003 VM with (1 processor and 4 GB RAM allocated)

      The server is serving up 1 qvw file about 4,500 KB. On average 3-6 users are accesing the document using the IE Plugin ver 9.0. The server is configured to maintain a single instance of the file in memory and we reload the data every 15 minutes. Reload takes 1 minute and load ~800K records.

      The problem is that the QV server reports the virtual memory (from the Performance log) as

      VMCommitted(MB) : 108
      VMAllocated(MB) : 160
      VMFree(MB) : 1888
      VMLargestFreeBlock(MB) : 1024

      when the server is first brought up.....

      over time the VMFree deteriorates.... is never recovers any of the memory.... it just deteriorates until there is no VMFree left and the service/server hangs and needs to be restarted.

      Here are the same stats just before the server dies...

      VMCommitted(MB) : 1409
      VMAllocated(MB) : 1522
      VMFree(MB) : 526
      VMLargestFreeBlock(MB) : 155

      Is this normal behavior? Seems like a memory leak somewhere....

       

        • Server Virtual Memory Leaks until system become nonresponsive
          Stefan Bäckstrand

          Usage by clients on the server increases the working set amount in memory when calculations of expressions and charts are done and cached for later use. This is normal behavior. 4GB RAM in a 32 bit QVS server might not be enough to host the application that you have - especially as the QVW file size says little or nothing of the size it requires when loaded and extracted by QVS into memory. Document structure, chart expressions, table data uniqueness and other factors are key indicators to how the document will behave in memory.

          Review the structure of the document and it's memory usage to try and figure out if the performance is insufficient. Review QVS log files to get more information and increase the verbosity of the logs from the QV Management Console.

            • Server Virtual Memory Leaks until system become nonresponsive
              Marc Morris

              Stefan,

              Thanks for your response. Is there any reason that the memory should not be released back once the client connections have been closed. What we are seeing is slow growth of the memory footprint with it never releasing any of the memory that it consumed. Even when no documents are loaded and all users are off the system.

              Fundamentally I agree that we may need to increase the memory available and move to a 64 bit version of the app however I am still trying to determine if the behaviour we are seeing is expected or not.

              I am attaching the ganglia graphs we have of the memory usage and the performance log file itself. The sharp dips coincide with when we restarted the services and/or the server.

              Thanks,

              Marc

               

            • Server Virtual Memory Leaks until system become nonresponsive
              Björn Wedbratt

              Just a note when using ESX. Make sure you allocate static RAM to the virtual machine, and not use dynamic allocation in ESX. Depending on how ESX is mapping the physical RAM to its virtual memory you may get undesirable when running QlikView Server.

              • Server Virtual Memory Leaks until system become nonresponsive
                michaelm

                Hi,

                What value is set in QEM Systems, Setup, Documents for the Document Timeout? (also are users access the vairous .qvws 24 hrs a day?

                In my case the timeout was set to 1440 minutes (a full 24 hrs) which basically means, never unload this document. I reduced this setting to 480 and that appears to be working for releaseing the memory.

                This solution came from QlikTech support. thanks Gustav!

                Michael