Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, May 05, 2009 at 06:49:06PM -0400, Gennadiy Nerubayev wrote:
> On Tue, May 5, 2009 at 6:15 PM, Lars Ellenberg <lars.ellenberg at linbit.com>wrote:
>
> > On Tue, May 05, 2009 at 03:57:16PM -0400, Gennadiy Nerubayev wrote:
> > > On Sat, May 2, 2009 at 2:06 PM, Lars Ellenberg <
> > lars.ellenberg at linbit.com>wrote:
> > >
> > > > nice. you are going into page cache here, mostly
> > > > (how much RAM did you say you have?)
> > > >
> > >
> > > 4GB on one node, 8GB on the other. I verified that benchmark numbers are
> > the
> > > same on both nodes.
> > >
> > > > dd if=/dev/zero of=/dev/drbd0 bs=4M count=1000 oflag=direct
> > > > > 4194304000 bytes (4.2 GB) copied, 17.6633 seconds, 237 MB/s
> > > >
> > > > do variations.
> > > > use 512k, 1M, 2M, 100M.
> > > >
> > >
> > > After rerunning these various sizes, there is no appreciable performance
> > > difference from bs=4M, in either connected or disconnected mode, across
> > all
> > > flags. I didn't do connected benchmarks on a single core, as the resync
> > > performance dropped by 100MB/s with only one core..
> >
> > Ah. right.
> > in that case, try "syncer { cpu-mask 3; }" and see if that improves
> > performance during normal operation on your dual core cpu.
>
>
> Not much effect, except dsync which appears to be a little faster by about
> 10MB/s.
then you may have to start with checking tcp timings,
or going for some of the kernel profiling stuff.
the main difference of internal-resync vs. streaming writes from userspace
are the context switches involved.
I'm not sure how to explain the "missing 100 MB/s", though.
have not seen that in person, yet.
--
: Lars Ellenberg
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed