I'm facing some issues concerning the memory usage of QlikView publisher Enterprise. We have been monitoring our server and the results show that even if we have physical memory available, QlikView uses virtual memory without releasing it. Does anyone know how to manage this?
On the other hand, we know that Qlikview server/publisher Enterprise has a limitation in terms of how many QlikView engines can be created simultaneoulsy, we use to think that this matter was associated to the amount of CPU available in ther sever, but after updating the server we now know that we can only have 9 qlikview engines running at the same time, does anyone know if this will continue or if there is a patch that can enlarge this number?
Thanks to any recomendations.
FIrstly, you need to separate Qlikview Server and Publisher; they have separate behaviors although they work together.
If something is allocating and keeping memory (but not actively using it at the moment), that's Qlikview Server (QVS.exe) caching user behavior, aggregated data like charts, tables and so on from your QVW documents - this is expected behavior.
Publisher (QVB.exe) use memory during reloads, and then release it back to the system. Publisher does not cache anything between sessions and spawn new processes (Execution services) for each new job/task, depending on the configuration.
The number of executions services that you can use simultaneously is license bound, and generally shows in the licence LEF in the QEMC for Publisher, it's not bound to a patch or a specific version of Qlikview components.
Stefan, thanks for the clarification. i didnt mean to mix things up. i should have been more clear.
The problem that we are facing is the memory usage keeps on growing up until the serves stops responding as it should (QVS.exe) We know that this is expected but the problem is that eventhough the server has memory available, the qvs.exe uses virtual memory increasingly.
Concernign the QV engines, according to our consultant, this issue is not associated to the license. We use to think that this matter was associated to the CPU's available in the sever, in the past we had 8 so we new that number of CPU's - 1 was the amount of qV engines (or jobs) could be running simultaneously. A few months ago we made a server upgrade with 24 CPU, then we realized that we werent able to run more than 9 jobs at the same time.
The consultant requested more information about this matter and they found out that 9 was the limit.
We have 24 engines in the setup there, we tested with 20, 16 an nothing still only 9 engines we able to run simultaneously. All these tests were done with our QlikView consultant in Chile.
You'll have to be more precise when it comes to the QVS memory usage. QVS is set to avoid using virtual memory (as in Page file) as much as possible and will go to much extent to avoid it. If you're having virtual memory usage on the machine (that's more than the usual amounts that Windows itself uses for regular operations), then you have a physical memory shortage and will most probably need more memory in the machine.
Regarding the QVB engines (reload engines in Publisher); I'm not aware of any limit at 9 instances specifically. Please contact firstname.lastname@example.org for more help with this, if it is not license bound.
microsoft COM (which is used for communication with the qv engine) is for some unknown reason very unstable with too many engines running simultaneously so it has been locked down to the highest "stable" amount.
Actually, I need to revise my answer, since I've talked to some resources internally.
The Distribution Service is the only part which instances are regulated by any limit set by Qlikview - and that limit is set by the Publisher license information. And each additional Distribution service is equivalent with an additional server for Publisher, basically.
However, each Distribution service may theoretically spawn as many QVB's (let's call them "QV Batches") as it likes on a machine, and run at the same time. BUT, since for some reason Microsoft COM has trouble handling 10 or more of these QVB's (since COM is the backend for the communication from/to them), we don't recommend using that many per machine. In fact, if you try, all QVB's initiated after the 9th or 10th will fail.
You can limit the number of concurrent QVB's running with the "Max number of simultaneous QlikView engines for distribution" setting in QEMC > Distribution Services > QDS@machine > Advanced. This will queue all QVB's that tries to start when this number of concurrent QVB's are running.
I hope that answers your questions.