recommended database blocksize on ext3 volume

4096 (4k)

8k

The difference between 4k and 8k isn't much but I prefer 8k.  In my experience it performs enough faster to be worth it.

You have to take advantage of it though.  Use type 2 storage areas with aggressive rttows per block and cluster sizes.  If you just dump everything into the schema area you're not going to get a good result.

running ATM.bench on the same machine:

Progress 10.2.A, linux,  Mandriva, ext3.

according of ATM.bench  (Gus)  the statistics for 4k are:

Database  Features

   ID   Feature                            Active  Details
   ----  ---------------------------------  ------  -------
      5  Large Files                        Yes
      8  After Image Mangement/Archiver     Yes
      9  64 Bit DBKEYS                      Yes
     10  Large Keys                         Yes
     11  64 Bit Sequences                   Yes

Clients  Tps  |--------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
        1   974,1 *************************************************
        3   950,9 ************************************************
        5   969,6 ************************************************
        7   956,4 ************************************************
Clients  Tps  |--------|---------|---------|---------|---------|---------|---------|---------|---------|---------|

and  for the 8k are:

                     180       360       540       720       900

Clients  Tps  |--------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
        1   811,4 *********************************************
        3   909,1 ***************************************************
        5   862,5 ************************************************
        7   907,3 **************************************************
Clients  Tps  |--------|---------|---------|---------|---------|---------|---------|---------|---------|---------|

Sure, for transaction intense workloads 4k and 8k blocks are within a few percentage points of each other.

But transaction intense workloads are not all that common.  In my experience most people are far more constrained by read performance.  And when it comes to read performance 8k has a noticable advantage.  Not a huge advantage, but a noticable one.  Both 4k and 8k are, IMHO, "good" choices.  They are both much better than 1k     And block size is just one consideration anyway.  Without a good type 2 based storage area design you won't get the best result regardless of block size.

I'm not dis-agree with you .. construction... in my opinon, redirect the -T to a "ramdisk" si the best

option regrding app. performances. This is stupid, but ... it work's!

mkdir /media/montmpfs
chmod 777 /media/montmpfs
mount -t tmpfs -o size=256M tmpfs /media/montmpfs

and say to -T /media/montmpfs

That's not a bad thing.  But it is better to avoid the -T IO in the first place

As far as I know (which, to be honest, is not that much in terms of DB tuning...) there is an advice to use the same block size for the DB as for the OS.

So would it make sense to change the block size of the ext3 filesystem to 8k ? how much of an adavantage would one gain compared to having 4k OS and 8k db block size?

There are multiple layers to that advice:

1) The simplest safe thing is to make them the same.

2) The slightly more complicated answer is to make sure that the db block is not smaller than the OS block.

3) A twist on all of this is that "blocks" don't apply to filesystems the way they used to.  It might be more important to consider the OS page size.

4) 8k is bigger than 4k so it is ok by test #2 & test #3.

5) I wouldn't bother changing the ext3 block size but it might be fun to test it and see how it works.

6) The difference in performance is dependant on what you are doing.  You would have to test it to find out.  In most cases it probably doesn't matter too much.

7) Don't worry about 4k vs 8k until you have addressed your storage areas.  There is way more advantage to doing that.