Thread: Re: [PATCHES] TODO Item - Add system view to show free space map

Re: [PATCHES] TODO Item - Add system view to show free space map

From
Simon Riggs
Date:
On Fri, 2005-10-28 at 08:31 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Fri, 2005-10-28 at 13:21 +1300, Mark Kirkwood wrote:
> > 
> > >      regression=# SELECT c.relname, m.relblocknumber, m.blockfreebytes
> > >                   FROM pg_freespacemap m INNER JOIN pg_class c
> > >                   ON c.relfilenode = m.relfilenode LIMIT 10;
> >
> > 
> > I like this, but not because I want to read it myself, but because I
> > want to make autovacuum responsible for re-allocating free space when it
> > runs out. This way we can have an autoFSM feature in 8.2
> 
> What do you mean, re-allocating free space?  I don't understand what you
> are proposing.

Moving to -hackers.

FSM currently focuses on reusing holes in a table. It does nothing to
help with the allocation of space for extending tables.

There are a few issues with current FSM implementation, IMHO, discussing
as usual the very highest end of performance:

1. Data Block Contention: If you have many free blocks in the FSM and
many concurrent UPDATE/INSERTers then each gets its own data block and
experiences little contention. Once the FSM is used up, each new block
is allocated by relation extension. At this point, all UPDATE/INSERTers
attempt to use the same block and contention increases as a result. ISTM
that if we were to re-fill the FSM with freshly allocated blocks then we
would be able to continue without data block contention. (We would still
have some index block contention, but that is a separate issue).

2. FSM Contention: As the FSM empties, it takes longer and longer to
find a free data block to insert into. When the FSM is empty, the search
time to discover that no free blocks are available is O(N), so the
freespace lock is held for longer the bigger you make the FSM. So
refilling the FSM automatically when it happens seems again like a
reasonable way to reduce contention. (Perhaps another way would be
simply to alter the search algorithm to make it O(1) when FSM empty,
which is simpler than it sounds.)

3. Helping Readahead efficiency: Currently blocks are allocated one at a
time. If many tables are extending at the same time, the blocks from
multiple tables will be intermixed together on the disk. Reading the
data back takes more head movement and reduces the I/O rate. Allocating
the blocks on disk in larger chunks would help to reduce that. Doing so
would require us to keep track of that, which is exactly what the FSM
already does for us. So automatically refilling the FSM seems like a
possible way of doing that since the FSM effectively tracks which
relations extend frequently and for whom larger allocations would be a
win. (Larger allocations in all cases would give very poor disk usage
that we might call fragmentation, if we can avoid debating that word)

There are other solutions to the above issues, so I really should have
started with the above as a problem statement rather than driving
straight to a partially thought through solution. 

Do we agree those problems exist?

(I'm not intending to work on these issues myself anytime soon, so happy
for others to go for it.)

Best Regards, Simon Riggs





Re: [PATCHES] TODO Item - Add system view to show free space map

From
Martijn van Oosterhout
Date:
On Fri, Oct 28, 2005 at 05:05:25PM +0100, Simon Riggs wrote:
> 3. Helping Readahead efficiency: Currently blocks are allocated one at a
> time. If many tables are extending at the same time, the blocks from
> multiple tables will be intermixed together on the disk. Reading the
> data back takes more head movement and reduces the I/O rate. Allocating

Ok, I agree with the rest but this isn't true. Any filesystem designed
in the last ten years leaves gaps around the place so when you extend a
file it remains consecutive. Some filesystems (like XFS) take it to
extremes). Interleaving blocks with this pattern hasn't been done since
FAT.

That isn't to say that preextending isn't a good idea. With my pread()
patch it was the one use of lseek() I couldn't remove.

Other than that, good thought...

Have a nice dat,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Re: [PATCHES] TODO Item - Add system view to show free space map

From
Tom Lane
Date:
Simon Riggs <simon@2ndquadrant.com> writes:
> There are a few issues with current FSM implementation, IMHO, discussing
> as usual the very highest end of performance:

Do you have any evidence that the FSM is actually a source of
performance issues, or is this all hypothetical?
        regards, tom lane


Re: [PATCHES] TODO Item - Add system view to show free

From
Simon Riggs
Date:
On Fri, 2005-10-28 at 18:43 +0200, Martijn van Oosterhout wrote:
> On Fri, Oct 28, 2005 at 05:05:25PM +0100, Simon Riggs wrote:
> > 3. Helping Readahead efficiency: Currently blocks are allocated one at a
> > time. If many tables are extending at the same time, the blocks from
> > multiple tables will be intermixed together on the disk. Reading the
> > data back takes more head movement and reduces the I/O rate. Allocating
> 
> Ok, I agree with the rest but this isn't true. Any filesystem designed
> in the last ten years leaves gaps around the place so when you extend a
> file it remains consecutive. Some filesystems (like XFS) take it to
> extremes). Interleaving blocks with this pattern hasn't been done since
> FAT.
> 
> That isn't to say that preextending isn't a good idea. With my pread()
> patch it was the one use of lseek() I couldn't remove.
> 
> Other than that, good thought...

Thanks. I wasn't aware of that.

Best Regards, Simon Riggs



Re: [PATCHES] TODO Item - Add system view to show free

From
Simon Riggs
Date:
On Fri, 2005-10-28 at 12:50 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > There are a few issues with current FSM implementation, IMHO, discussing
> > as usual the very highest end of performance:
> 
> Do you have any evidence that the FSM is actually a source of
> performance issues, or is this all hypothetical?

This was a side-bar issue for my current focus, as I already said, so
I'll skip what sounds like a lengthy debate on this for now.

Best Regards, Simon Riggs