It is atypical for super short intervals for the duration of the quiesce,
snap & resume to be 2 seconds or so.  It is more common to have timings of
15 seconds to 2 minutes, depending completely on the ability of the disk
subsystem to handle the flushing of the disk buffers via the sync command
initiated!  Most common is over a minute.  One shop we are aware of it
takes over 10 minutes to flush the disk buffers via a sync.

Ouch.  I'll risk exposing my ignorance here but are these people not
opening themselves up to massive data loss in the event of an crash?
If the sync times are getting high, running a regular sync out of cron
might fix this (or completely grind the system to a halt).

As if that's not bad enough, the rsync copy can saturate a communications
channel (network card) for the duration of the rsync!  Yuck!  This has had
profound adverse impact on web performance at some sites.  For
applications that are really closely monitored, say a socket, can fail!

Nope.  Rsync will only do this if you let it.  Check the man page for
the --bwlimit switch, this situation is precisely what it is for.

AFAIK this doesn't actually change the speed of the traffic at all,
that is the function of the underlying transport.  This switch causes
rsync to monitor the average transfer rate and pause from time to
time.  The effect is the same though, you don't saturate your link.

Therefore, we do not recommend the cycle as an alternative to the
Transaction Logging capabilities of the Databases (UDT RFS & UV TL), which
are designed for much closer intervals, and less drain on resources.

It's a great idea that works extremely well for backup scenarios!  Other
implications preclude it from being used in short time frames.

I think ymmv should apply here.  If you have an environment that
supports it without the extreme sync timings you mention above, and
you use the --bwlimit switch to tune network load if necessary I can't
see why not.

Regards,
Adrian
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to