Skip site navigation (1) Skip section navigation (2)

Figuring out the right block size for a stripe set

From: KÖPFERL Robert <robert(dot)koepferl(at)sonorys(dot)at>
To: pgsql-admin(at)postgresql(dot)org
Subject: Figuring out the right block size for a stripe set
Date: 2005-06-27 14:56:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin

I'm lost. Please give me a hint.

I'm currently fighting with myself of whether to use 8k blocks (pg's native)
or 64k Blocks (more data) as stripe set size.
...of course to get maximum performance. I want to setup a stripe set over 4
disks on a Solaris Sparc box with a stripe block size in question.
I found these arguments pro and contra either decision:
+ Postgres native (on Sparc Solaris) block size.
+ considdering random access to memory mapped pages this will distribute
access over all phys. disks
+ read and write of near blocks are not agglomerated (read for example a 32k
block) so this is as equal as good, even better because a block distance of
not 4 makes two disks read/write
- but exactly this may be bad, since this is one disk access that could have
been used by another query.
- Wal-files get written sequencially and in chunks of 8*8k which causes all
4 disks to work (be not avl. for other queries)
a sequencial scan should be equal on boht block sizes (given that a table is
bigger than 64k)

- not a native access. Maybe up to 8 requests on the same 64k block cause 8
accesses (this should apply to 8k as well)
+ writing a random 8k block seems to just write one 8k block ? not read a 64
and then...
+ 64k are more data whilst being 'the same work' as 8k
+ a wal-segment can be written on just one disk whilst the others remain
free for queries.
- the distribution of data is not that fine grained

What are you usually configuring?

Here: Ultrasparc, Sol9, Metadisk, Several SCSI-disks, ufs


pgsql-admin by date

Next:From: Michael FuhrDate: 2005-06-27 14:56:38
Subject: Re: wal logs in pg_xlog
Previous:From: Tom LaneDate: 2005-06-27 14:51:22
Subject: Re: DRDB?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group