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:
1) Use longer running SSH sessions which dsync more than one user at a time.
2) 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...
