Re: Very low disk performance on 5.x

From: Steven Hartland (killing_at_multiplay.co.uk)
Date: 05/02/05

  • Next message: Robert Watson: "Re: Very low disk performance on 5.x"
    To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
    Date: Mon, 2 May 2005 21:43:57 +0100
    
    

    ----- Original Message -----
    From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
    > 0. Does the user know enough about what he is doing.

    Im no expert but then again Im not beginner either :)

    >>1. Write performance being nearly 3x that of read performance
    >>2. Read performance only equalling that of single disk.
    >
    > If the user expects an out of the box configuration with
    > default parameters to give him maximal performance, the
    > answer to issue number zero is: Obviously not.

    Not maximal, that will never be the case, but reasonable yes and
    it doesnt look like we are getting that ATM.
     
    >>I'm quite willing to test and optimise things but so far no one has
    >>had any concrete suggestions on that to try.
    >
    > First thing I heard about this was a few hours ago. (Admittedly,
    > my email has been in a sucky state last week, so that is probably
    > my own fault).

    Hehe its been kicking around for a few days, might be of benifit
    it you check back some some of the info posted by others.

    >>This is just me though I think we do need to strive for good out
    >>the box performance in these types of senarios
    >
    > We strive for a sensibly balanced system, no matter what use
    > people put an out-of-the-box configuration to.

    Indeed and I would classify this one of those such senarios.

    >>> Testing end-to-end means that we have very little to go from to
    >>> find out where things went wrong in any one instance.
    >>
    >>To eliminate various parts of the subsystems I've just tested:
    >>dd if=/dev/da0 of=/dev/null bs=64k count=100000
    >>Read: 220Mb/s
    >
    > This is a very interesting number to measure, you'll never
    > see anything else going faster than that. Presumably
    > this is -current ?

    Nope thats 5.4-STABLE this should be at the very least
    260Mb/s as thats what the controller has been measured on
    linux at even through the FS.

    >>Compared with:
    >>dd if=/usr/testfile of=/dev/null bs=64k count=100000
    >>Read: 152Mb/s
    >
    > On -current and 5.4 you don't have to make partitions if you
    > intend to use the entire disk (and provided you don't want
    > to boot from it). You can simply:
    >
    > newfs /dev/da0
    > mount /dev/da0 /where_ever

    Booting from it unfortunately. Although wasnt when running
    the big set of tests results I reported ealier.
    Gonna rip the machine out and put the test OS disk back in
    and try that.

    > This should have the sideeffect of aligning your filesystem
    > correctly to the RAID volume.
    >
    >>So looks like the FS is adding quite an overhead ~70Mb/s ( 60% )
    >>although from the linux tests we know the disks are capable
    >>of at least another 40Mb/s
    >
    > Yes, filesystems add overhead. That's just the way things are.

    To be expected but 60% overhead is a bit excessive.

    > One thing you could try is to use a larger block/fragment size
    > on your filesystem. Try:
    >
    > newfs -b 32768 -f 4096 /dev/da0

    Will do.

    >>> Did you remember to disable all the debugging in FreeBSD 6-Current ?
    >>> (see top of src/UPDATING)
    >>
    >>Yep all debugging was disabled on my second run on current.
    >
    > Just checking: what exactly did you disable ?

    Dont have it to hand any more witness etc, all the debugger options +
    stripped out all the unneeded drivers.

    >>N.B. Current had at least on out of order lock issue while I was using
    >>it but not while the tests where going on.
    >
    > Yes, current is current :-)

    As I thought hence its not running that any more bit to unstable for
    my main dev box :)

        Steve

    ================================================
    This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

    In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
    or return the E.mail to postmaster@multiplay.co.uk.

    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"


  • Next message: Robert Watson: "Re: Very low disk performance on 5.x"

    Relevant Pages

    • Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
      ... On Thu, 22 Feb 2007, Evgeniy Polyakov wrote: ... My tests show that with 4k connections per second more ... overhead, which in turn can be high or noticeble. ... Eventually it will be reading some blocks from the disk ...
      (Linux-Kernel)
    • Re: Not wasting space on a RAID array?
      ... There's at least two overhead measures. ... We can verify the size of the filesystem matches the volume with this... ... surely formatting the disk wont hog up so much space. ... The cylinder sizes that the A1000 generates for the LUN aren't the same ...
      (comp.unix.solaris)
    • Re: Whats the variable holding the dir seperator?
      ... > little daunting although I do agree with you. ... There's always overhead for method/function calls, ... notice if the code is in a really, really tight loop. ... strutures in memory, and makes an occasional system call, but no disk ...
      (comp.lang.perl.misc)
    • Re: copy 150G over 100Mbit
      ... protocol overhead and disk speed. ... look to the network first.You should consider the size of your files. ... Another consideration might be to move the entire filesystem. ...
      (freebsd-performance)
    • Re: BerkeleyDB locking question
      ... > the locking for you behind the scenes. ... :) So, the actual overhead seems ... to disk, everytime I open a dbase connection. ...
      (comp.lang.perl.misc)