[DRBD-user] [OT] rsync issues [Was Re: Read performance?]

Ross S. W. Walker rwalker at medallion.com
Tue Jun 5 17:25:04 CEST 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


> -----Original Message-----
> From: drbd-user-bounces at lists.linbit.com 
> [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Lars 
> Ellenberg
> Sent: Tuesday, June 05, 2007 10:55 AM
> To: drbd-user at lists.linbit.com
> Subject: Re: [DRBD-user] [OT] rsync issues [Was Re: Read performance?]
> 
> On Tue, Jun 05, 2007 at 08:30:12AM -0500, David Masover wrote:
> > On Tuesday 05 June 2007 04:12:12 Lars Ellenberg wrote:
> > 
> > > tune the io scheduler(s).
> > > get the queue length down.
> > 
> > Ok, which scheduler, and where? I ask because I see tunable 
> things like:
> > 
> > /sys/block/sda/queue/scheduler
> > /sys/block/sda/queue/iosched
> > 
> > But the "queue" directory doesn't even exist for DRBD:
> 
> that is what I'm saying. drbd has no "reqeust queue" in that sense.
> (dm-linear has neither, btw.,
> to draw an analogy between two "virtual" block device drivers...)
> drbd just does some housekeeping and then passes the requests along.
> 
> that's why it is very unlikely that it would be drbd's fault
> when your reads take too long.
> 
> have a look at your lower level devices.
> 
> generally I recommend deadline.
> for your situation (high latency network link) I suggest 
> small nr_requests.
> whether or not that is the real problem, I cannot tell, this has only
> been an educated guess.

Actually anticipatory might be better here as it will get the
read requests down first as the #1 slow-down are write requests.

That's my $0.02

> so I also strongly recommend that you do not just tune blindly
> something somewhere, because someone (me) told you (based on 
> *guessing*
> where the problem may be) that this *might* have an effetc...
> and then it does not help, and you complain that it had no effect...
> 
> first get the facts.
> monitor your io subsystem (maybe iostat helps?),
> monitor the counters in /proc/drbd,
> find out what is really going on.
> 
> until you know what is going on, you cannot really tune.

If the link is high-latency I would seriously look into using
asynchronous replication in an active-passive setup, then use
a network file system with local-cache backing store for sharing
the storage... I believe Solaris has NFS caching backing store.

I guess that makes $0.04 now...

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.




More information about the drbd-user mailing list