Skip to main content
Announcements
Qlik Community Office Hours, March 20th. Former Talend Community users, ask your questions live. SIGN UP
cancel
Showing results for 
Search instead for 
Did you mean: 
marcelo_7
Creator
Creator

Successively slower distributions

Hello,

I have a task running nightly which first reloads a document and upon completion it is distributed in a separate task. Since we upgraded to QV11 SR2 I've noticed the distributions get slower and slower.

Looking at the latest distribution I can see that it writes around 5 mb every 10 seconds and the earliest writes 5 mb every second. The size of this document in particular is ~870 Mb and this occurence is the same for other larger documents.

distribution A.jpg

Our setup consists of two servers. One Distribution server and another Qlikview Server with AccessPoint.

Does anyone have any idea what could be causing this?

1 Solution

Accepted Solutions
Anonymous
Not applicable

Andreas & Manelo

I had exactly the same issue and it was resolved by Windows update 2600217, as per Andreas 's earlier post.


The attached pdf gives more details.  It is on the QlikView web site, but I won't put the url in due the Moderation Quagmire.


I first applied all the latest Windows updates before the patch.


BEWARE:     We had not applied Windows Updates since early last year and they took the best part of 2 hours to run and fair few reboots, which was a bit embarrassing and I had advised only a one hour outage.


p.s.  Our issue was nothing to do with AD lookups, although the finger was pointed at that a few times.



I was advised by QlikTech that we were the only site people who had this issue, seems like we are not the only site.



Best Regards,     Bill



View solution in original post

11 Replies
markmccoid
Partner - Creator II
Partner - Creator II

I'm having the same issue and have a case open with QlikTech.  No resolutions as of yet.

I am curious as to where your source or user doc folders are located.  Are they on the distribution machine or the machine with QV Server or on NAS or  SAN storage?

We have the source of user doc folders on the distribution machine and I noticed in the task log the when distributing it is going through the qvp protocol on the QV server machine.

Let me know and I will keep you updated on what I find.

Not applicable

Any solutions yet?

I'm really wondering what that part actually does. For our bigger documents (around 4GB in size) that part took 2-3 hours! Due to some other distribution related issues we changed the distribution server's URL in QMC setup to point to the IP of that server instead of its name and this dropped the time dramatically. For a document it took before 3 hours now does it in 20 minutes. It's really hard to figure out what is actually going on, because shouldn't it be just distribution server talking to the QVS? Why would changing the distribution servers name to an IP have such a big impact? Note, we did not change the QVS settings, so that is still set up by its name as are all the other servers too.

marcelo_7
Creator
Creator
Author

We noticed that restarting the Distribution service on the publisher worked as some kind of reset because the distribution times were reduced back to normal. Also a restart of the service only takes a few seconds so I scheduled it for a daily run. Thanks for your information I'll invesigate if changing to IP has an effect on distributiontimes. Meanwhile here's the .bat for your convenience:

net stop QlikViewDistributionService

CHOICE /T 15 /C j /D j

net start QlikViewDistributionService

Not applicable

Hi guys this is very informative, lets keep this thread alive.

I was facing the same issue and I pretty much used the same approach as marcelo_7

swuehl
MVP
MVP

I've also encountered the same issue:

QV_Tasks_20131209_2.png

It's a simple Reload and Distribute Task on a QV 11.20.11922 server running on Windows Server 2008R2. Just a binary reload of the data model and distribution on the same server.

Durations starts around 3 min and goes up to more than 1 hour to 1:30. After restarting the service (as seen for the 20.11.2013, durations goes down to min duration again).

While using a scheduled service restart might be a workaround, does anybody have a closer insight to what is going on here?

Mark McCoid, do you get any feedback regarding your QT ticket? Could you share your ticket ID?

markmccoid
Partner - Creator II
Partner - Creator II

Hi,

The Case # was 00178136.

We ended up looking at network issues, changing chunk size and then one day it started working much faster.  I'm not sure what we did but we are assuming the chunk size may have helped:

"This is know as bug#48073 - Workorder does not get sent QMS to QDS fixed in 11.0 SR2 11440

The workaround QV 11 SR2 is to change the "chunk" size to a lower number.

1- Go to default location of the config file:  C:\Program Files\QlikView\Management Service\QVManagementService.exe.config

2-  Then adjust the QMSChunkSize from 100 to 20

<add key="QMSChunkSize" value="20"/> . The value 20 is not a set value so when you have a case with this issue you have to test different values like 5, 6, 8, 10 and so on to find the one that works for that customer.

3- Restart the QMS service."

Not applicable

Could be that you don´t have installed a fix for a bug in the ,NET framework, causes QDS to stack a huge amount of pinned objects.

Please verify that you have this windows update.

Windows update 2600217 (http://support.microsoft.com/kb/2600217). This
should be installed with standard Windows Update as part of "Microsoft
.NET Framework 4 Client Profile".

It could also be that you have a very large Active directory, if so, you can try and set down cache and timeout;

Try to set down cache in QvDirectoryServiceConnector.exe.config (found under ProgramFiles>QlikView)
<!-- How many minutes queries (and their replies) are cached -->
    <add key="CacheExpiryInMinutes" value="60"/>
    <!-- Timeout for requests to the LDAP catalogue -->
    <add key="ServiceTimeoutInSeconds" value="30"/>

And then restart QlikView Distribution service again, and messure time for each run.

You can also modify timeout in QVDistributionService.exe.config
  <!-- Timeout in seconds for calls to the DSC-->
    <add key="DSCTimeoutSeconds" value="120" />
    <add key="DSCCacheSeconds" value="900" />

Please!
document each settings that being modify, so it can be modify to
default if necessary, and make small adjustments each time.

Not applicable

easy way to test if AD lookup is causing time increase is to distribute to folder instead of QVS, then mount those folders to QVS.


Anonymous
Not applicable

Andreas & Manelo

I had exactly the same issue and it was resolved by Windows update 2600217, as per Andreas 's earlier post.


The attached pdf gives more details.  It is on the QlikView web site, but I won't put the url in due the Moderation Quagmire.


I first applied all the latest Windows updates before the patch.


BEWARE:     We had not applied Windows Updates since early last year and they took the best part of 2 hours to run and fair few reboots, which was a bit embarrassing and I had advised only a one hour outage.


p.s.  Our issue was nothing to do with AD lookups, although the finger was pointed at that a few times.



I was advised by QlikTech that we were the only site people who had this issue, seems like we are not the only site.



Best Regards,     Bill