What's typical CPU usage for qvdistributionservice.exe?

[#1]

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.

[#2]

As an aside, this process also uses quite a bit of memory (700 MB, ATM), even long after it has finished the overnight ETL cycle.  Restarting the service, its memory load dropped to "only" 100 MB.  Is it considered a good practice to restart the distro service after large jobs to reclaim memory, or is this unusual behavior I'm seeing?

[#3]

We have the same issue running on QV 11 SR1.

Beside the DirectoryServiceConnector still writes "Warning Search aborted: no resources" into log (C:\Documents and Settings\All Users\Application Data\QlikTech\DirectoryServiceConnector\Log)

[#4]

I should have specified: we're also on 11 SR1.

Hmm, I don't see that error in my log file (C:\Users\All Users\QlikTech\DirectoryServiceConnector\Log, or C:\ProgramData\QlikTech\DirectoryServiceConnector\Log, on Windows Server 2008).

[#5]

Small update: two weeks after restarting the service, it's accumulated 300 hours of CPU time, and it's back up to 500 MB of memory used.  So restarting the service periodically may help, but plan on doing so on a weekly basis if memory is a concern!

[StefanBackstrand]

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.

[#7]

Hello

during several months memory for qvdistribution was growed to 200 K. After restarting is about 30 K and is very slowly growing.

Does recomend to restart service for example once a month ?

Thanks

[#8]

Sorry: MB

[#9]

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.

[#10]

We use daily server restart (running only 2 documents, simple deployment) at night. End users required almost no session timeout and every 20 min reloads. Therefore we had to untick option "Allow Only One Copy of Document in Memory" in System>Setup>Qlikview Servers>tab Documents. Two document have only 20MB size each and during the day it increase up to 10GB in memory!

In attach. is the Performance setup (in CPU Affinity we save one core for other server applications).