QlikView 10 Server Issue

[#1]

I'm running QV 10 Server 10.00 SR 2. And throughout the day the qvs.exe runs and takes up threads and CPU for no reason. Once I reset the QlikView server service, it goes back to normal. This allows the jobs to finish much quicker as the qvs.exe process is not running. Is there any reason why this is occuring? Right now, I have QlikView Publisher and Server on the same machine. I've seen information where this setup is not advised, but that is how the system was setup when i came to the company. Anybody have any recomendations?

Thanks,

Alex

[Anonymous]

Stefan,

I tried to Defrag the .shared file and open the document with this file.  I get the same response.   The QV Server keeps increasing the Physical Memory Usage until it finally makes the Server unusable.  Also, I cant close the plugin on my machine.   I have to go in and end task, but it will only end after I restart the services on the QV server.  

Luckily, this shared file is not very large and I can get by with deleting it.  If this would happen to some of our larger analytics, I would definately have upset users.

Thanks,

JS

[niklas_hedlund]

QT support have looked at the shared-files but found nothing strange about them. Bookmarks and server objects are used very little. Still a mystery exactly when this happens but Prohibit Session Recovery seems to be a work around for the moment.

[Anonymous]

Have you guys tried SR4?  I obtained a patch for SR3 that seemed to fix our "memory" issue on QVS and apparently the patch is included in SR4.

Kevin

[niklas_hedlund]

Yes, we're currently using SR 4 and have experienced the same behaviour also with SR 2, SR 3 and SR 1. We're using Ajax client with QlikView's out-of-the-box webserver. Windows 2008.

[Anonymous]

We upgraded to SR4 and are still having the same problem with one of our analytics and the .shared file.   If we open the analytic with the PlugIn, we get a white screen saying that it is Opening the analytic, but it never opens.   Then if we check on the QV server, our memory grows until it uses up the entire 48 GB and then makes the Accesspoint unusable forcing us to restart the server.   If I delete the .shared file, everything opens up fine but I have some upset users.

I have also checked the "Prohibit Session Recovery" checkbox and that doesn't appear to help either.

Going to send this to support.  Will let you know if I find anything else out.

JS

[niklas_hedlund]

That's bad news that "Prohibit Session Recovery" doesn't bite for you. We have had a stable server the whole week since we checked that option so I was certain that was the issue. We have also unchecked the "Allow Server Objects" during the week, but decided this morning to allow them again (to allow users for bookmarks). It has been working so far today. Let's see how it develops...

[StefanBackstrand]

jsomsen: Ok, so I reviewed your .shared file, and someone has created input field values on the server, and when they wind up in the .shared file - this might happen, depending on data model, data size and so on. Remove them (uncheck then and defrag, or just from the QEMC), and it should be fine.

This is a known "issue", but is working as designed, when it comes to input fields. It will generated A LOT of data in memory to satisfy the input field that the user created.

[StefanBackstrand]

And as a consequence, this *should* not have anything to do with "Prohibit Session Recovery".

[Anonymous]

Stefan,  That did it.  We have a few documents that use a rather large amount of input fields.  We will have to monitor that.

Thanks for your help. 

JS

NOTE: I'd mark this as complete, but I think I hijacked a thread that I thought was related!

[StefanBackstrand]

Ok, good to hear. Do you have any open cases in Support? If so, give me the case #'s, I can get the owners and refer them to this solution so they can close your cases - since I'm in the global team in Lund.

Thank you!