After upgrading to QV11 SR2 last week we have been forced to performed restarts every day. Qlikview server is just not responding, today it showed "No server".
The installation has a separate machine for the QVS which also holds an IIS.
Today the memory usage was very low (4-9 GB) when the server had hanged before it have reached 25 GB.
175 users/ 50 applications
Nothing special is written in the logs. The only thing I see is when it happens is this: qvpx: Exception while handling request
and the 2nd time (when the "No server" message appeared) it hang today it said first
14:11 qvpx: Exception while handling request
14:42 Restart: Server aborted trying to recover by restart. Reason for restart: Internal inconsistency, type D, detected.
Just don't want the customer to force me to reinstall QV9 again but they are discussing it.
We recently upgraded from 9 to 11 SR2, and have similar environments (users/# apps). We are not seeing these kinds of stability issues. Is your QVS clustered? If so, where are the PGO files stored?
No it's not clustered. However while going through the system I found out that the new outsourcing partner hosting the servers have decreased the amount of cores from 12 to 2. There will be a meeting tomorrow and then I hope that we can increase that number again and that the problems will disappear.
Hi, Andy - Can you provide an update on this issue? We are seeing the same symptoms. QlikView support thinks it might be related to the SAN storage drives. Thank you
We are still waiting on the new hardware uintil then I'm doing like many others on this forum.
Scheduled a task running a bat-file every early morning with this content
net stop "QlikView Server"
ping -n 31 127.0.0.1 > NUL
net start "QlikView Server"
Most days this saves us from performing a manual restart in the middle of the day.
Is this a Physical or Virtual Server?
I only ask because Virtual Servers can sometimes "lie" about how much RAM is really available, especially if your outsourcing provider has used something like RAM Overcommit. The Virtual Guest might still think it has RAM to give but the Host might not have any.
We are on virtual machines (will be changed within some weeks).
It seems like a change of the outsourcing company running the servers is correlated with the problems. They made some fundamental changes on the virtual configuration. We realized this after hours of searching after the failure.
On Qliktechs recommendation we are now going for physical machines equipped with two Intel Xeon E5-2650 and 64 GB RAM.
(They also recommended Intel Xeon E5-2690 or the older X5690)
Cool, that makes sense then. If you are going to virtualise QlikView then at the very least RAM allocation should be dedicated to the guest running the QVS.
I like the E5-26nn range myself so sounds like a good way forward!
Exactly but when having dedicated resources the whole thing with virtualisation fails and on top of that the VMware licenses becomes very expensive.
Fair enough Andy and I understand.
It really depends on why you are virtualising. If it's to get better economy on hardware then frankly QV isn't the best product to virtualise as with any other product which is RAM/CPU bound. If your reasons for virtualisation are for DR or Management then it makes more sense but the virtualisation layer will still carry overhead to QV which is why a Physical machine is generally better if possible.