Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
In my environment, where QlikView and the underlying database are on the same server, I've noticed that qvdistributionservice.exe has about the same CPU time as SQL Server. Each of these two process is has total CPU time equal to about one sixth of the server's uptime. This surprises me, as (if I understand it right) qvdistributionservice.exe should just be running for a few minutes each morning while I reload documents. That whole process starts and ends in an hour, and most of that is dead time: a dozen reports run in a few minutes, then the next batch starts half an hour later, and it wraps up in a few minutes. Meanwhile, SQL Server feeds dozens of scheduled reports throughout the day, some fairly intensive ETL, and ad hoc reports - I expect it to have signficant CPU load outside of ETL.
I've also noticed that qvdistributionservice.exe remains active at a trickle throughout the day, with about 2% of CPU resources, and it occasionally spikes up to near-100% for a few seconds at a time. This happens even though there are just two reports which are updated during the day. These reloads do not appear to correspond with the spikes in CPU usage.
This is not quite a problem, exactly, but it concerns me. Do you see significant CPU utage for qvdistributionservice.exe outside of expected ETL cycles?
Thank you.
smelcdus wrote:
Two document have only 20MB size each and during the day it increase up to 10GB in memory!
It might be a good idea to review the document data model and the sheet objects and their expressions, or the user load/behavior.
Also, please note that memory usage cannot be compared on any level between QVS and QDS. They are separate components, that uses memory very differently, built on different platforms (C++ and C# respectively). Memory leaks are extremely rarely found in QVS.
There you will see used huge amout of RAM of QVS service, not distribution service.
Jonathan Shaltz wrote:
I'd like to know if there's an official recommendation to do so, and what other people are doing. For my part, I've set it up to do so weekly (ick) until and unless someone can offer a real fix - I'm up to 330 MB of allocated space after less than a week of uptime.
This is easily handled with a batch file:
net stop "QlikView Distribution Service"
net start "QlikView Distribution Service"
Just add the .bat to a scheduled task, and make sure it runs outside of your normal ETL window.
What happens if you leave it running without restarting? Does the memory usage plan out?
I really don't see the problem with a server process that consumes ~300 MB in RAM - my web browser uses more than that.
700 MB is the most I've seen it using, after a couple of months. So most of the memory allocation is in the first couple of weeks, followed by slow growth. Hard to say if it eventually caps or if it grows without limit.
Yeah, but there's a reason I don't run web browsers on a server. It has better things to do with the RAM. I'm really more concerned about the CPU usage; this thread has gotten a little off track by focusing on memory allocation.
Stefan Bäckstrand wrote:
The QDS (Distribution Service) has sub-processes in form of threads that work in the background to do stuff like recieving workorders from QMS (Management Service), as well as keep and eye on trigger schedules and other resources in regards to the application data for QDS. Having CPU time on a service like this should not be a concern, if the usage does not interfere with regular operations or slows down heavier distribution tasks - which it probably own't since intensive threads in the process most likely will have precedence and hence get more priority.
Memory leaks in .NET processes are not very common, and the garbage collection in the framework usually works very well. Having a couple of hundred MB in RAM is not unseen in larger environments. If you see a constant increase thoough, where the curve doesn't flat out, that could be the foundation for a bug report and an investigation for QlikView Support.
Please see also thread http://community.qlik.com/thread/70807
This is now a known bug from Microsoft, please check so you have this fix installed from windows update: KB2600217
http://www.microsoft.com/en-us/download/details.aspx?id=28936