Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>
>>Using time with dd, I found the DRBD disk to be about 13 MB/second
>>and the non-DRBD disk to be 29 MB/second on the slow set of servers.
>
>This was with them connected and DRBD up on both?
>If so that sounds good considering your network speed.
Yes, I've never see a problem with times when everything is
connected. (well, almost never: see my other recent post).
>>
>>On the fast servers, the non-DRBD disk tested via dd yields an
>>astounding 182 MB/second and the DRBD disk, a mere 16 MB/second.
>>
>>Actually, that's in line with drbd.conf. So I want to make clear
>>that I have seen these slow numbers only when the secondary has
>>been offline for some time and there is quite a bit of data to be
>>resynced.
>
>So you are saying that with the pair completely synced, if you run
>the same tests you get much better numbers (which would only be
>logical), or are you saying that with the unit under test
>disconnected from it's mate and having a lot of data out of sync,
>the numbers drop while they are still disconnected?
Server A is up and has been for a while.
Server B comes up and there is a fair amount to resync to.
I frequently do "more /proc/drbd" and that's where I saw the numbers
alternating between fast and slow.
However, this happened only two times really. First, with the slow
server pair and the first time its secondary came up and then again
with fast server pair and when its secondary came up.
Just recently, I had to resync the whole fast server and the
performance overall was excellent. Only rarely did I see the numbers
low.
I don't know why it was wild and crazy with those first syncs on both
pairs. When I saw it slow during this recent full sync, it was rare
and fleeting, implying as if it really was never actually slow. It
just may be the way calculations of the speed are made and I just
typed "more /proc/drbd" at a time when the calculation itself just
happened to yield a slow number of K being transferred.
But the tests are not entirely comparable. I've updated numerous core
programs (e.g., the kernel itself) on both fast and slow pairs since
that initial wild and crazy sync.
><SNIP>
>>
>>On the slow server pair:
>>ttcp-t: 134217728 bytes in 28.13 real seconds = 4659.27 KB/sec +++
>>ttcp-t: 16384 I/O calls, msec/call = 1.76, calls/sec = 582.41
>>
>
>This is on 100Mb/s ethernet???
yes.
>is drbd (or something else) also using the network at that time?
I believe drbd was on, but I don't think that either computer was doing much.
>i.e., this seems really slow.
>For a two computer 100Mb/s ethernet with nothing else on it, the
>theoretical limit is ~12000KB/sec, most times you can practically
>see 11000KB/sec, and you are only seeing ~1/3 the theoretical...
>
Will test again when the primary is online. It's missing a drive now. >:-o
>>I wonder if the fact that the secondary of the slow pair's having
>>only 256 MB impacts the overall performance for this result.
>
>Should not really be a problem unless you are running x, gnome/kde,
>firefox, thunderbird, OpenOffice.org, and emacs {:^) all at the same
>time.
>
When drbd is syncing the fast pair, the secondary, which has an
Opteron 240 and 512 MB, is virtually unusable from ssh.
--
Maurice Volaski, mvolaski at aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University