John R Pierce wrote: > Stewart Williams wrote: >> I have just purchased an HP ProLiant HP ML110 G5 server and install ed >> CentOS 5.2 x86_64 on it. >> >> It has the following spec: >> >> Intel(R) Xeon(R) CPU 3065 @ 2.33GHz >> 4GB ECC memory >> 4 x 250GB SATA hard disks running at 1.5GB/s >> >> Onboard RAID controller is enabled but at the moment I have used mdadm >> to configure the array. >> >> RAID bus controller: Intel Corporation 82801 SATA RAID Controller >> > > that is essentially desktop grade disk IO > > >> For a simple striped array I ran: >> >> # mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb1 /dev/sdc1 >> # mke2fs -j /dev/md0 >> # mount -t ext3 /dev/md0 /mnt >> >> Attached are the results of 2 bonnie++ tests I made to test the >> performance: >> >> # bonnie++ -s 256m -d /mnt -u 0 -r 0 >> >> and >> >> # bonnie++ -s 1g -d /mnt -u 0 -r 0 >> >> I also tried 3 of the drives in a RAID 5 setup with gave similar results. >> >> Is it me or are the results poor? >> >> Is this the best I can expect from the hardware or is something wrong? >> >> I would appreciate any advice or possible tweaks I can make to the >> system to make the performance better. >> >> The block I/O is the thing that concerns me as mostly I am serving a >> 650MB file via samba to 5 clients and I think this is where I need the >> speed. > > is this a sequential or random access application thats using this > file? is it read only/mostly, or is it random update? I'm not sure, how can I find this out? > its rather hard to read your bonnie output logs as they aren't very > columnar. but it appears the sequetial read speed at least is really high. > > i'm seeing 55MB/sec random(block) and 1.4GB/sec sequential reads on the > 1GB file, Correct. > so I dunno what your issues are... of course, a 1GB file > sits entirely in the system cache assuming a reasonable amount of > otherwise idle memory I'm not sure whether the performance would suffice as I've not tried putting it in production. I am going to benchmark the old server (currently in production) that this is replacing. Thanks, Stewart