Server Communication Lost

[#1]

Hi Folks

I wonder if anybody can help.

Today I had a report of the above message from a user, they had opened a QlikView document and had made three selections when they got a big cross over the object. They hit the refresh button that always comes with those big cross errors and then they got a server communication lost message.

When checking on the server stats immediately afterwards, we find that we are running critically low on memory and that the server is making extensive use of the paging file. We have 8 GB Ram on the Server and 2 processors.

We then found that a number of users are stated on the server as having multiple documents open, but when checking physically on their machines, they have only 1 open.

I cannot understand, in an installation where there are a maximum of 20 users logged onto QVW documents, that we are running out of memory, this must be a small installation compared to most.

Also, I don't understand why we are using 8GB of Ram when there are only 6 distinct QVW apps open at one time (even when all 20 users are logged on, they will still only be using the 6 apps).

The quick answer of course is going to be....... get 16GB of Ram on board, but actually, I'd really like to back up the request with some numbers to show why we need it, how much we need, when we might need more.

If anybody has any clues to help I would really appreciate it.

Cheers,

[johnw]

I was only peripherally involved in this, so I don't have many details. However, we used to have an issue where a user session would crash out - but STILL take up a license, and still consume server resources. So one user could be consuming multiple licenses, and from the server's perspective, have multiple documents open. I believe our solution at the time was to simply reboot the server now and again to remove these crashed-out sessions. I believe this no longer happens to us, and I believe it was fixed while upgrading our server to a newer version (this was back in 8.something, was I think fixed in 8.somethingelse, and we're now on 9.something on the server). It possible that you're running into the same problem.

[#3]

Hi John

Thanks very much for the response, we are going to put a daily restart of the service in place which should overcome most of these issues for us.

On a further note, have you ever managed to scientifically calculate the RAM Requirements of a QlikView server? It should not be beyond QlikTech to provide me with a formula that could be used so I can go to senior management with a purchase request backed up by some real evidence of requirements rather than "chuck an extra 4GB in, that should solve the problem" when we get memory problems.

Cheers,

[#4]

Nigel,

In Management Console (I am still on 8.20 so this may be elsewhere on other versions) is the 'Allow > 1 copy of a document in memory' checked or not?

I have never had an issue with performance but I seem to recall that Windows Server 2003 32 bit can only allocate 2Gb per task (can be extended to 3Gb), so I dont understand what is occuring unless you are using a later version of Win Server.

In terms of memory requirements, this is very much dependent on the individual document, but on the Server and Publisher course I went on a couple of years ago, Qliktech advised:

5Mb for program operation

nMb for the document itself to be opened

10%-15% of the document size for each session

Regards,

Gordon

[#5]

Hi Gordon

Thanks for responding to this, I am getting more and more convinced that the issues we have here are caused by some server setting in the management console, but I just can't get to the bottom of it.

Some more info:

Qlikview version : 8.50

Management Console (Allow only one copy of document in memory) : Is NOT checked

Server: Windows Server 2003 Enterprise (64 Bit) - I am sure that the 64 bit version can allocate as much ram as you like to a single task.

On the memory sizing information, our DBAs here had been told the same thing that you said, the thing is though that we have a document that is stored with data on the server at about 10MB, but when this is first loaded on the server (when there are no other documents open) the memory usage shoots straight up to about 100MB, but even with that increase I still can't make the numbers work, see following.

We had 20 sessions open at the time, and these sessions were spread over 6 documents.

The initial load of the 6 documents we would assume to consume 600MB Ram, add on the 5MB for program load and then add on 15% * 20 sessions gives us a total of 905MB which is nowhere near 2GB, 3GB and certainly nowhere near the 8GB Ram we have available on the server.

I'm therefore, at a complete loss because this server is dedicated to QlikView, there's nothing else on there!

Cheers,

[johnw]

Nigel West wrote:have you ever managed to scientifically calculate the RAM Requirements of a QlikView server? It should not be beyond QlikTech to provide me with a formula that could be used so I can go to senior management with a purchase request backed up by some real evidence of requirements rather than "chuck an extra 4GB in, that should solve the problem" when we get memory problems.

I haven't myself calculated RAM requirements for a QlikView server. However, I think that there is some estimator either included in the product somewhere, or maybe it was one of the applications posted to QlikCommunity, or maybe in someone's blog. I wish I could remember. I haven't really been involved in purchasing, other than preparing documentation to show that one of my applications was very soon going to overwhelm our 32-bit server, and that we therefore needed a 64-bit server. I do pay attention to how much memory my larger applications are using during the load, and try to keep it from getting too excessive. But if I ran into serious problems, I'd just request they add more RAM. RAM is cheap compared to developer time, licenses, slowdowns from swapping to disk, and so on. I think we're doing pretty well with what I consider a very minimal amount of RAM, 8GB if I recall, but then our applications aren't all that big (perhaps tens of millions of rows in the largest ones).

Still, as far as going to senior management with a purchase request, in THIS case, you're responding to an actual problem. You should know from experience how much memory it is consuming. Add some more for comfort, and it seems like a very solid request, particularly given how cheap RAM is.

Still, since the memory doesn't seem to be behaving as expected, throwing RAM at it, while a good idea, might disguise the true problem (such as the crashed-out but persisting sessions in our case). So it's definitely worth continuing to poke around at it.

[#7]

We had these issues quite a bit a few years ago and found that a nightly reboot helped a lot.

One other thing that helped us was to change the document timeout setting on QVW This allows the server to release a document from memory after it has not been used for a certain period. In QVS 8.2, the default was 1440 minutes (24 hours - not good when you have hundreds of users/day!). We have changed this to anywhere from 10-30 minutes, depending on how busy we believe the server to be. In QVS 8.2, this is called "Document Timeout" and is found on the General tab of the QVS Control Panel.

One other thing that we ran into was on the application side - some applications had inefficient or "buggy" objects that caused our server to crash. One time, an upgrade to the latest QVS service release fixed this. Another time, the developer actually changed the formula in use, as we could consistently crash the server by opening a certain object.

Good luck!

-Jen

[#8]

Hi Jen and others,

We are battling with this timeout issue right now ("Server Communication Lost -- Closing Document!"). I have set the "Timeout" settings ini two places:
1) QVS Mgmt > General > Sessions: Possible Session Timeout 10800 (3 hours), Max Innactive 10800 and Max Total 0 (unlimited)
2) In the individual QVW files (Settings > Doc Properties > Server > Max Total Session Time and Max Innactive Time to 10800.

However, we are still gettting this apparent timeout error for users whose total session time is less than 3 hours -- per the EventLog for the server.

This is a larger deployment for us (150 users on two separate servers accessing up to four applications, the largest being 1.7GB highly compressed or roughly 14 GB in memory), but previous performance benchmarking on our server showed that the servers can handle it. The virtual memory is well below 50% max for the box, though the CPUs sometimes are maxed for seconds at a time. Servers are 128GB 16 processors each. QV Server version 8.5.

Ideas anyone? It appears that others are experiencing some issues as well: http://community.qlik.com/forums/p/23523/89828.aspx#89828

Anyone?

[#9]

Like Nigel, we have the setting set to only allow 1 copy of an application open (QVS version 8.5). I have observed a few times when users will experience problems opening an application and will rack up 2 - 8 sessions at a time. Restarting the QV Server service clears that up, but, hey, this is starting to sound like Microsoft

[#10]

Okay, first: programmer error. I had not updated all of the documents with the proper max session time settings.

Second: the document settings for timeout trump the QVS session settings -- at least from my experience in QVS v 8.5

Sorry for the confusion and extra posts.