Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, Dan Frincu wrote: > Hi, > > You have to realize how many abstraction layers you have going on there. > It goes something like this, disk, software RAID on top of disk, LVM > physical volumes on top of software RAID, volume group on top of > physical volume, logical volume on top of volume group, DRBD on top of > logical volume. Does it sound like a lot? Well, of course I do realize, how many abstraction layers there are. But my tests compare many layers vs. many layers + DRBD. And it's with the last layer (DRBD), when performance drops so drastically. So in my opinion it's correct to look for problems in DRBD here. > Because it is, and this is > just one node, now put into play the secondary node and a network > connection to get your traffic there and then go back the chain down to > the disk for a write. I'm surprised you got up to 80MB/s, but then > again, the CPU is compensating for a lot here. > > On-point, what protocol are you using for the setup? For instance, if > you're using protocol C, then it has to wait for a lot of things to > happen for the write operation to be committed, it is the safest > protocol, but also the slowest, from what I know. Changing the protocol > _might_ help, but the main thing is the layer overload you got going on > there. And to add to that, what happens when a process requires CPU > time? What about 100 processes? > As I mentioned, I tested DRBD in _standalone_ mode - without network connection - so I don't need to take any network-related latencies into account. The only thing added on top of LVM (and all those other layers) here is the DRBD layer, which doesn't need to wait on network and (in my opinion) should be passing requests to lower layers as quickly as possible.