[clug] Tips for improving ext3 performance

[Daniel Pittman]

Chris Smart <chris at kororaa.org> writes:
> On Thu, 2008-07-03 at 15:02 +1000, Daniel Pittman wrote:
>> "Chris Smart" <chris at kororaa.org> writes:
>> 
>> > Been reading up a little about this lately, does anyone out there have
>> > any tips or suggestions for improving ext3 performance for a desktop
>> > machine?

[...]

>> > using a stride size when using raid and offsetting the partition start
>> > to align with stripe.
>> 
>> This should just come by magic, since the mkfs tools interrogate the
>> underlying RAID for details.  (As I understand it, with a sufficiently
>> recent version, etc, etc, which should be "it just works" today.)
>
> Interesting.. got any links to back that up? 'Cause I don't know how to
> check that once a filesystem has been applied, unlike things like the
> journal.

Off hand, no, not for ext3.  Let me see what a couple of minutes with
Google can turn up, though.

Damn.  Turns out I was wrong.  It doesn't do that at all. :/  Sorry.
(Also, turns out I needed to check the source to find out.)

>> > Anyone had a play with this sort of thing?
>> 
>> If you can, placing the journal on an external device will deliver a
>> much, much bigger performance boost that these other changes.  It allows
>> your data and metadata writes to occur in parallel.
>
> Ok, that should introduce some sort of bottleneck at some stage, perhaps
> on a large RAID0 system or something, whereby you can write lots of data
> on the stripe in parallel, but only have a single disk to write all of
> that data's journal. 

Yup, that surely would, save for two things:

First, having the journal on the same disk will cost you in seeks,
because you are going to have to move the heads more than you would
without.

Second, you don't have to put the journal on a bare device, you could
put it on anything Linux identifies as a block device.  Say, a striped
RAID array, for example.

So, performance shouldn't ever be worse than storing it internally, save
by deliberate choice to provide less resources.

> Of course I have no idea how fiddly the journal data is, how slow it
> is to write. 

Not very slow at all, especially since it is block journalling.  The
real killer for performance is the seek overhead and rotational latency
to write a journal entry, then to go back and write the real data.

Regards,
        Daniel