On 03/05/12 11:08, Timo Sirainen wrote:
On 5.3.2012, at 9.25, Attila Nagy wrote:
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds. Sure the idea is to improve the performance :) There are two ways:
Use longer running SSH sessions which dsync more than one user at a time.
Use TCP connections instead of SSH. Don't forget about connection pooling to get concurrency. :) BTW, despite being somewhat harder to implement, I personally like native connections better.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs. The process startup/teardown costs are pretty low. I'll need to improve dsync's performance at some point though. Actually I pretty much redesigned the whole dsync already, but I'll probably leave that to v2.2. The current design can still be improved.
It depends. For a moderately loaded server I get this: # time ssh root@be02 "echo 1" 1 0.000u 0.009s 0:00.30 0.0% 0+0k 0+0io 0pf+0w ICMP echo RTT is 0.878 ms.
So the ssh connection adds ~29 ms overhead to each sync request.
Yes, dsync seems to need some optimizations too. :) I've tried previously on one pair of our servers with a higher level of concurrency (8-16 or so, I can't remember), and it couldn't keep up with the changes. The method was similar to yours:
- an external library wrote modified user ids to a file
- in an endless loop a script picked up those (moved the file) and started parallel dsyncs (on ssh)
The runs were longer and longer... BTW, we modify the maildirs externally, so this adds a lot of inefficiency here...