Mailinglist Archive: opensuse (4344 mails)
| < Previous | Next > |
Re: [SLE] poor disk performance on 9.3 relative to 9.1
- From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
- Date: Mon, 22 Aug 2005 13:48:34 -0400
- Message-id: <87f94c3705082210483b0c0263@xxxxxxxxxxxxxx>
On 8/20/05, Hans du Plooy <hansdp-lists@xxxxxxxxxxx> wrote:
> Kelly Burkhart wrote:
>
> >Here are some representative numbers for three fairly comparable
> >machines:
>
> >All machines were idle while running the test. All filesystems are
> >Reiser 3.6.
> >
> The machine you use for 9.1 have more memory than the others. I'm not
> sure if extra memory should have such a big impact (if any at all) on
> software raid performance. Is there anything else that's different?
The lack of memory in the second 2 cases may not be the only cause of
slowness, but it will certainly effect the timings because the
original test did not flush disk cache.
It was only a 4 GB file being created. Half of that 4 GB could
potentially still be sitting in cache at the end of his test on the
bigger 2GB ram machine.
At a minimum the OP should modify the test to be (all on one line):
(dd if=/dev/zero of=bigfile bs=8k count=500000; sync; sync) & time wait
That will at least give a more realistic/comparable result.
Personally I use "iostat -d 5" and look at the blocks/sec column
number when I'm doing disk benchmarks, but I normally do raw i/o, not
filesystem i/o so that may not work in this case.
I often get values between 50,000 and 110,000 blocks/sec or 25 MB/sec
to 55 MB/sec. I'm doing a read test under 9.3 with IDE drive right
now and seeing 110,000 blocks/sec, so I'm pretty happy with that.
The best solution for the OP would be to run a real benchmark like bonnie++.
FYI: The double sync should flush disk cache (unless reiser has a bug?
xfs used to ingnore sync requests, so it is possible.)
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
> Kelly Burkhart wrote:
>
> >Here are some representative numbers for three fairly comparable
> >machines:
>
> >All machines were idle while running the test. All filesystems are
> >Reiser 3.6.
> >
> The machine you use for 9.1 have more memory than the others. I'm not
> sure if extra memory should have such a big impact (if any at all) on
> software raid performance. Is there anything else that's different?
The lack of memory in the second 2 cases may not be the only cause of
slowness, but it will certainly effect the timings because the
original test did not flush disk cache.
It was only a 4 GB file being created. Half of that 4 GB could
potentially still be sitting in cache at the end of his test on the
bigger 2GB ram machine.
At a minimum the OP should modify the test to be (all on one line):
(dd if=/dev/zero of=bigfile bs=8k count=500000; sync; sync) & time wait
That will at least give a more realistic/comparable result.
Personally I use "iostat -d 5" and look at the blocks/sec column
number when I'm doing disk benchmarks, but I normally do raw i/o, not
filesystem i/o so that may not work in this case.
I often get values between 50,000 and 110,000 blocks/sec or 25 MB/sec
to 55 MB/sec. I'm doing a read test under 9.3 with IDE drive right
now and seeing 110,000 blocks/sec, so I'm pretty happy with that.
The best solution for the OP would be to run a real benchmark like bonnie++.
FYI: The double sync should flush disk cache (unless reiser has a bug?
xfs used to ingnore sync requests, so it is possible.)
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
| < Previous | Next > |