Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
It appears that after a couple of weeks?? the Qlikview server service stops. If you restart the service everything is good.... for a while
Yes, that is probably cached data sets and objects. It is by design. The next time those documents are loaded into memory (opened by clients) the cache will directly attach again, and users will enjoy the seamless experience of lighting fast results coming back, instead of having to wait for the server to re-calculate everything (as would be the result of flushing cache at every document timeout).
It is nice that the users "will enjoy the seamless experience of lighting fast results coming back".
For a developer developing a new QVW on the same server, RAM resources may be to scarce if the QVS has been up and running for some time.
In my case, my QV Desktop Client that I use for my development is significantly impacted after only a few days of the QVS running. Having to use a batch file is ok in my case, but for most of my customers this would be a poor solution.
Regards,
Jakob
I'm just taking the hammer approach as well. My users don't care why the server isn't working anymore, so the nightly reboot it is.
Jakob Fabian wrote:
It is nice that the users "will enjoy the seamless experience of lighting fast results coming back".
For a developer developing a new QVW on the same server, RAM resources may be to scarce if the QVS has been up and running for some time.
In my case, my QV Desktop Client that I use for my development is significantly impacted after only a few days of the QVS running. Having to use a batch file is ok in my case, but for most of my customers this would be a poor solution.
Well, that's what happens when you mix server components with developer tools. I'm personally finding it very strange that it's only in a QlikView administrators world that it is fully acceptable to run production like components like large data processing server services on the same machine as developers work with a developer tool much like any other IDE.
Would you have developers use Visual Studio to trial code on your production SQL Servers as well?
Just because you have a large machine, it doesn't mean that you can pack it with different roles. The buffer is there to serve the system, not to be lent to other type of components that don't belong on these machines.
The only advice I have to someone trying to do what you are doing is to restrict the QVS working set limit values (Low and High) to exclude the portion of physical RAM that you think developers will utilize, and hope for the best that they don't exceed it.
Stefan,
In my experience, the reason that development and production roles are both executed on the production server in QlikView shops is that it is hard for IT to justify buying ANOTHER high-grade server with lots of RAM just for development purposes. Specifically, just for QlikView development purposes (can't really be shared). QlikView development is just as RAM hungry as QlikView in production.
I know that this is besides the point of the original post, but I had to answer...
In principle share the opinion of Stefan:
There should always be a clear separation of production and development
Most applications were developed and run (with smaller datasets) on my standard-notebook.
The refreshing of the applications (with full dataset) is done on the server - and here Simon has a good point.
Am not sure, whether you actually need such a big machine for development. Looking at the memory-consumption during the refreshing of our applications, we are usually running @2-4 GB RAM consumed. We actually plan to use an older server with 8GB of RAM as production-engine (and might be used for development as well) and to have the "big" machine acting as server only.
Will revert with our experiences.
++Peter