Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-05-08 15:01:08 +0000 \ Torsten Neumann: > Lars Ellenberg <Lars.Ellenberg at ...> writes: > > > > So how can I check why drbd slows things so terrible down? Yes there is a > > > bottleneck. But without drbd all seems fine, with drbd not. > > > > see what io scheduler is in use > > (/sys/block/lower-level-device/queue/scheduler) > > on servers I prefer "deadline". > > you can switch to "deadline" like this: > > for q in /sys/block/*/queue/scheduler ; do > > echo deadline > "$q" > > done > > or by specifying a boot-time commandline parameter. > > > > if that did not help yet, > > check wether increasing "max-buffers" > > and/or decreasing "max-epoch-size" in drbd.conf does help. > > > Neither changer io scheduler from anticipatory to deadline nor lowering > max-epoch-size showed any effect. max-buffers was on the highest allowed value > anyway. But decreasing didn't helped also. would have been a work around anyways. as noted earlier, and by yourself when using different io-backend: drbd is able to saturate disk/network bandwidth. so I consider this a problem of your io-backend, not of drbd. what I can suggest is: if one kernel version works for you, and an other does not: try to find out what has changed: read the kernel change logs, use diff ... what else can you do, if you really want to try and see if messing with drbd's tunables could help: watch the al: and bm: values in /proc/drbd (they count drbd meta-data updates). if al: increases very often, you could try and increase al-extents. there is a tradeof with expected resync time on primary crash, though. if bm: increases very often, there is not much you can do about it... one more thought: are you sure your raid5 does not happen to rebuild itself at the same time? that would pretty much explain everything... -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.