This starvation can cause backlogs even on the high-bandwidth connection, as the customer experienced. This will help address the issue known as “starvation,” which can result from keeping several low-bandwidth (throttled) connections open along with high-bandwidth connections. At night, leave the connections at full bandwidth (not throttled) or throttled depending on the volume of traffic being generated. Instead of having throttled connections at 16 K and 64 K during the day on low-bandwidth connections, adjust the replication schedule to prevent replication during the day on those connections. We recommended a few tests for the customer to determine whether throttling was the cause of the backlog and slow replication: If CPU on the hub machines is not consistently high, we would assume the customer was not hitting any connection limits (which are not hard-coded) but rather experiencing backlog and possibly some limit on served files, with throttling the likely culprit. The amount of space allocated to staging was insufficient and was probably generating churn on the disks as well as probably limiting the benefit the customer was getting from cross-file RDC. Having 12 additional hours at fairly low bandwidth pipes means that DFSR will do some catching up but it can’t perform miracles, and certainly can’t do much with only 16 KB or 64 KB.
With throttling set at 64 KB and 16 KB, the customer was severely restricting the flow of data for 12 out of 24 hours (i.e., while data is being generated or modified but not allowed to replicate up). Some specific observations made by our DFSR gurus who reviewed this case: We have observed that the backlog seems to clear overnight."īecause the customer reported that the backlog goes down at night when throttling is not set and builds up again during the day when throttling is in effect, we believed that the amount of data modified and replicated was larger than the capacity of the throttled pipe. Note that on most links, bandwidth is throttled only between 7am and 7 PM. A few of the members do log events stating that staging folder cleanup has occurred. Staging area is set to the default of 4096 MB for all replicated folders. The average file size is difficult to estimate given the huge range - most of the data is Office files ranging from 500KB to 2 MB. The total size at the hub server is about 800GB - each branch server ranges from about 10GB up to 100GB. Here is a breakdown of the links being used:Ī large number of 512KB Links = 64K (7am - 7pm)Ī large number of 256KB Links = 16KB (7am - 7pm)
a 256K link site will have both connections each throttled to 16KB during the day. There are two replication groups for each site so they are both throttled to the same rate - e.g.
So we end up with 50 replication groups and 50 replicated folders.īandwidth is being throttled during the day. This replication however is scheduled to replicate only between 12AM and 4AM. We also have another replication group across all sites for common data. We use one replication group per site to replicate site-specific data folders and one replication group per site to replicate user-specific folders. "We have one hub site server and 25 branch site partners. The customer described the environment as follows: Even on fast links, changes to small files (a few KB) would take 4 to 5 hours to replicate. First published on TECHNET on Jun 14, 2006Ī customer recently contacted us about a consistent backlog they were experiencing using DFS Replication.
0 kommentar(er)
