Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-07-29 00:06:35 +0200 \ Bernd Schubert: > Hello Lars ;) and all others, > > I already shortly hinted in my previous mail that we have nfs problems. Well, > I first thought that it is nfs related and started a thread on the nfs > mailing list (http://sourceforge.net/mailarchive/message.php?msg_id=9064778). > > Finally Olaf Kirch suggested to run iozone directly on the server to see if > it might be filesystem related. It was then pretty fast clear that its the > drbd device that is slow. > > Here some numbers (iozone -s 1g -r 1m -o -i 0): > > both servers synchronized: 11MB/s > drbd stopped on the second server: 60MB/s can you post more verbose test results on some website, or here? which file system? > Well, with sync-nfs exports this probably causes the slow nfs-writes of only > 2-3MB/s on the clients for large files and even much less with small files. > > Well, we first tried to use 2.6.7 but it crashed every morning with page > allocation errors (and no one on LKML seems to care :-( ). > However, with 2.6.7 we didn't have performance problems with nfs. Before our > server went into production I did several speed tests and four clients could > write to the drbd exported device with 4 x 7.5MB/s, which I considered to be > sufficient and so did not further tests to the drbd device(s). > > Due to the instability of 2.6.7 we had to switch back to 2.4.27-rc3 on Sunday, > but kept drbd-0.7. On Monday the people complained that e.g. compiling their > projects took ages, so I changed to nfs async exports and the people stopped > complaining ;) > However, since we want to have failover, we also need sync-mounts, so I > started the thread on the NFS-ML. > > Olaf also suggested to tune the bdflushing, as I had no experience with that I > used the numbers from another howto > (http://robert.timetraveller.org/talks/optimisation/sect4.1.1.html), but it > didn't help. > > Well, so I'm asking here if someone here has an idea? > Somehow I would like to try using protocol A or B instead of the current > protocol C. Its worth a try, isn't it? > Is it sufficient to change the protocol in the configuration files and then > restart drbd? > Lars, referring to your mail to LINUX-HA we should use drbd-0.7.1 for any > other protocol than C? Thats not problem, but I don't want to reboot the > server with a new kernel until the weekend. lacking standardized bechmarks, we did not yet settle on the slightly arbitrary value we want to use to kick the lower level device on a secondary with proto A or B... but yes, it should already be better than what we have with 0.7.0. in any case, using DRBD adds more latency to your setup. so if you have had an io latency on a normal disk that is basically bound by rotation freq and seektime (say, 7 ms), you now add in network latency and the io-latency on the second node... for random writes, performance degrades considerably. as I said, lacking data, I can not really comment on whether protocol A or B with current drbd svn (on the way to 0.7.1) will help. you need to benchmark it yourself. please post your findings. Lars Ellenberg -- please use the "List-Reply" function of your email client.