64bit QV Server causing 333 system errors in the event viewer

[Michael_Reese]

An I/O operation initiated by the registry failed unrecoverably. The regristry could not read in, or write out, or flush one of the files that contains the system's image of the reigstry.

That's what I get repeatedly after opening a file residing on the server. This is a brand new box and nothing is running on it except QV 64 bit Server, 64bit developer and the plugin.

I have the same problem when i access the file from the plugin and when i access it from the developer app. This machine has been rebuilt and the problem is reoccurring.

QVW accessibilty becomes inconsistent. Somestimes the qvw will open. Other times, the app will hang and I have to kill it. Totally unpredictable.

Other issues start to occur at this point. I'll get insufficient resource errors when trying to open any app (notepad, calc, etc.) mmc's won't open. But if I start closing things, everything might go back to normal. However, this is a beast of machine with nothing else on it. CPU and RAM consumption are minimal.

It seems clear at this something in the connection from IIS to QVS is making things go haywire, but what? The QV service is running a local admin domain account. ASP and and Framework 2.0 are both allowed. I added the QVS Tunnel extension. I've done everything and it's still not working properly. Soon, I iwll have an angry client.

Also, prior to rebuilding, Publisher was installed. I was getting really inconsistent behavior here too. It would suudenly prompt me for authentication when I was already on the page. Auth might or might not work. Sometimes it would generate asp 2.0 errors

Any suggestions are appreciated.

[Michael_Reese · Accepted solution]

As of right now, this appears to be caused by the Working Set settings in QV Server. The default 70-90 limits are too high and this was turned down to 10 and 20. Everything seems to be working fine now. I will turn the settings up at some point, but not as high as they were out of the box.

[#3]

Are you running in a virtual machine?

[Anonymous]

I've got recently same behavior in my x64 server (Win2008) whitch was running in a virtual (VMWARE) server. Now i'm using win 2003 32 - bit VMWARE server, and everything seems to be ok.

Do you have some recommendations or advices running QV on virtual machines?

[Bjorn_Wedbratt]

I know that memory ballooning is a no-no, so basically it's recommended to allocate static memory to the VM-machine. There might be other things to consider as well, depending on hypervisor.

[Michael_Reese]

No, it's a physical server. This was the first time QlikTech has seen this issue on a physical machine. It is a single, quad core xeon with 4GB of RAM.

The client's server vendor chose to put only 4GB on, which is sort of pointless on a 64bit server. I'm pretty sure this problem would go away if it had more RAM. I'm not sure if this is the direct correlation, but the OS needs 1GB to operate. It might suggest there was a conflict here since I'm assuming QlikView Server does not check for how much memory is left for the OS. The default working set should not have a max value 90% either. This was dropped to 50-70 in QV9. We are using these settings now and it works fine.

Has anyone else experienced some of other issues I have mentioned? (like the insufficient resources error) The authentication problems I was having was due to network configuration.

[StefanBackstrand]

The allocation made by QVS for the Working set (according to the working set limits values) would in this case leave something between 1200 and 400 MB (low and high limits 70/90 calculated on 4 gb ram) for Windows to operate under - and with some load on the server that would easily get closer to the latter, thus causing the OS to behave this way.

Since the working set limit values are percentage, these kind of configuration mismatches can occur; both on 4 GB ram systems, aswell as on 128 GB ones. 90% of 128 GB is~13 GB - Windows won't need that, and certainly cannot operate with satisfying performance on ~500 MB as in your case. 😃

[Michael_Reese]

I agree to an extent. The 70/90 default is not appropriate. But, these issues surfaced even with an absolute minimal load on the server. Performance tab checked out fine. And also, in every environement (with more RAM) and same default settings, these specific issues did not occur.

With your 128GB example, assuming there is 1.5x virtual memory, it would leave 19-58GB for Windows. How much windows would actually use is subjective, but I beleive it needs at least 1GB free to operate normally. The issue arrises when there is a definitive conflict, like when QV only leaves 600-1800MB and Windows has 6GB allocated (4GB o RAM). While it may be ideal to lower VM based on usage, 'Too much' VM won't cause these 333 errors and 'insufficient resource' errors to occur.

Thanks

[StefanBackstrand]

Yes, QVS will say that performance is fine, since it is inside of its own memory reservation - and with no working set size to talk about, performance will look splendid. Though the reservation is not the same as commit amount - the reservation can still cause the issues on certain configurations, most probably on systems with (from a QVS point of view) sub-dimensioned memory resources.

QVS memory reservation does not span into virtual memory, it is made strictly on physical memory. And yes, the issue is a conflict symptom.

[#10]

This is urgent that we must verify the Working Set limits are working to stop memory allocation caching.

We will not purchase additional licenses until this feature is confirmed working in our environment.

I've adjusted our settings to 21/21/10%. Our server has 64 GB so QVS.exe should be limited to 13.44 GB

After adjusting the Working Set, we clicked around via AccessPoint.

QVS.exe is currently using 14.4 GB.

The working set settings are not stopping memory utilization. How do we adjust to make these settings work as designed?

Is a reboot required after adjusting the settings?

Thanks