Re: Very low disk performance on 5.x

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 05/02/05

  • Next message: Steven Hartland: "Re: Very low disk performance on 5.x"
    To: "Steven Hartland" <killing@multiplay.co.uk>
    Date: Mon, 02 May 2005 21:20:48 +0200
    
    

    In message <005401c54f4a$7f271890$b3db87d4@multiplay.co.uk>, "Steven Hartland"
    writes:

    >> As such that is a fair end-user benchmark, but unfortunately it
    >> doesn't really tell us anything useful for the purpose of this
    >> discussion.
    >
    >Yes but the end-user performance is really the only thing that matters.
    >There are two killer issues here:

    No, there is three issues here, and you correctly identify the
    secondary two, but forget the first:

    0. Does the user know enough about what he is doing.

    >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.

    >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).

    >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.

    >> 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 ?

    >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

    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.

    One thing you could try is to use a larger block/fragment size
    on your filesystem. Try:

            newfs -b 32768 -f 4096 /dev/da0

    >> 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 ?

    >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 :-)

    -- 
    Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
    phk@FreeBSD.ORG         | TCP/IP since RFC 956
    FreeBSD committer       | BSD since 4.3-tahoe    
    Never attribute to malice what can adequately be explained by incompetence.
    _______________________________________________
    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: Steven Hartland: "Re: Very low disk performance on 5.x"

    Relevant Pages

    • Re: which PC
      ... Only if you have a very poorly designed filesystem. ... I understand filesystem and that he was talking about disk based ... would not cause significant fragmentation. ... A configuration that fragments for that specific use is ...
      (rec.photo.digital)
    • Re: [AGPGART] intel_agp: use table for device probe
      ... ACPI: ... Using ACPI for SMP configuration information ... device sda2 operational as raid disk 0 ... mounted filesystem with ordered data mode. ...
      (Linux-Kernel)
    • Weird harddisk behaviour
      ... A couple of weeks ago my 400Gb SATA disk crashed. ... Partition Table for /dev/sda ... # Type Sector Sector Offset Length Filesystem Type Flag ... Superblock backups stored on blocks: ...
      (Linux-Kernel)
    • Strange case of root filesystem corruption
      ... Yesterday GRUB would suddenly not display the boot menu anymore. ... Looking at filesystems on the disk with the free ufs2tools program, ... Subfolders of / on the same filesystem are affected as well. ... sectors/track: 63 ...
      (freebsd-questions)
    • Re: Making a bootable second hard disk (and larger filesystems)
      ... >filesystem on disk2 and it has to be bootable. ... >backup on second hard disk, ... under "root" and let both discs in the server? ... If you do only "dd" you may want to boot a "Knoppix" CD. ...
      (comp.unix.sco.misc)