Slow DFS - FRS replication

G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system (More info?)

I have two Windows 2003 servers - both with fibre network connections. I
created a DFS root on one of the servers, and links on both the servers. I
increased the FRS staging area to 4 GB on each server, I give replication
and all time to take place (I also force it). With nothing else in the dfs
links - I add a single 2.5 GB file. It takes over 1 hour before that file
appears on the second server. Everything is transferring, but extremely
slow.
When I transfer this file over a mapped drive from system A to system B - it
takes a short amount of time, and uses 50%+ of the network bandwidth
(nothing else running). When I check the network bandwidth during DFS / FRS
replication - it is less then 1% - 2%.

I will be running sonar and other utils to help troubleshoot, but I must be
missing something. I know there is additional processes that slow
replication down some - but not this much.

Anyone have any suggestions?

Thanks
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system (More info?)

We have a similar problem. A 20gb DFS share takes 20 hours to replicate
the data over a 100mb link.

No solutions found so far.

Does your scenario have a large number of files involved?
Our 20gb of data contains 145,000 seperate files. Perhaps DSF and FRS
are not so crash hot with large numbers of files?



--
russbaker
------------------------------------------------------------------------
Posted via http://www.mcse.ms
------------------------------------------------------------------------
View this thread: http://www.mcse.ms/message640624.html
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system (More info?)

You might want to try reposting the original question to the
microsoft.public.windows.server.dfs_frs newsgroup.

To address the question briefly, FRS has a lot of overhead when it is
replicating files. Beyond just copying the bits from one machine to
another, FRS reads an entire file and generates a hash of its contents,
performs multiple database transactions (on each member), copies files to
stage them, etc.

You can improve performance by having the replica root, staging folder, and
FRS database on separate physical disks. This helps reduce disk contention.

Note FRS tends to be more sensitive to the number of folders and files it's
processing rather than just the raw amount of data. For example, if you
have a large number of directories included in your 145,000 files, this will
also slow FRS down as it needs to track each of the folders too.

Also you might be interested to know that DFS and FRS are independent of
each other. If you have a scenario where FRS doesn't work and you want to
use another file replication mechanism (e.g. robocopy), that does not
preclude using DFS.

--Richard

Please post FRS related questions to microsoft.public.windows.server.dfs_frs
and prefix the subject line with "FRS:" to make it easier to spot. Note that
FRS is used to replicate SYSVOL on domain controllers and DFS root and link
targets.

For additional FRS resources, please visit http://www.microsoft.com/frs.

This posting is provided "AS IS" with no warranties, and confers no rights.

"russbaker" <russbaker.16ut2f@mail.mcse.ms> wrote in message
news:russbaker.16ut2f@mail.mcse.ms...
>
> We have a similar problem. A 20gb DFS share takes 20 hours to replicate
> the data over a 100mb link.
>
> No solutions found so far.
>
> Does your scenario have a large number of files involved?
> Our 20gb of data contains 145,000 seperate files. Perhaps DSF and FRS
> are not so crash hot with large numbers of files?
>
>
>
> --
> russbaker
> ------------------------------------------------------------------------
> Posted via http://www.mcse.ms
> ------------------------------------------------------------------------
> View this thread: http://www.mcse.ms/message640624.html
>