Obviously looking at more iostat information would give a better idea, but I'd estimate that you are NOT I/O bound. Sorry I can't give you absolute numbers from UM, but I can share a patch that we wrote that we believe has increase sync throughput substantially, as evidenced by the lack of a sync backlog which we were getting before we added the patch.

The patch itself is pretty simple. As with most TCP-based request- response protocols, the Cyrus sync protocol suffers from artificial "Nagle" delays. See:

        http://en.wikipedia.org/wiki/Nagle's_algorithm

for what's good about Nagle's algorithm. The patch disables Nagle delays in both sync_client and sync_server.

:wes

Attachment: nodelay.diff
Description: Binary data


On 09 May 2007, at 11:05, Nik Conwell wrote:
What sort of rates are you all getting for replication?

At 2.3.7 for a manual sync_client for a user, I'm seeing ~35MB/ minute across a 100M net to a linux SW RAID 1 pair of U320 disks.

Is this speed typical or abysmal?

Disks appear to be holding me back:

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util dm-0 0.00 0.00 0.00 429.96 0.00 3439.65 0.00 1719.83 8.00 7.24 16.75 1.86 80.01

Production (40,000+ users) would probably be FC and gigE...

----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Reply via email to