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

Re: Performance TODO items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance TODO items
Date: 2001-07-30 21:10:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > New TODO entries are:
> > 	* Add queue of backends waiting for spinlock
> I already see:
> * Create spinlock sleepers queue so everyone doesn't wake up at once

That is an old copy of the TODO.  I reworded it.  You will only see this

	* Improve spinlock code, perhaps with OS semaphores, sleeper queue, or
	  spining to obtain lock on multi-cpu systems

> BTW, I agree with Vadim's opinion that we should add a new type of lock
> (intermediate between spinlocks and lockmanager locks) rather than try
> to add new semantics onto spinlocks.  For example, it'd be very nice to
> distinguish read-only and read-write access in this new kind of lock,
> but we can't expect spinlocks to be able to do that.

Yes, I agree too.  On a uniprocessor machine, if I can't get the
spinlock, I want to yield the cpu, ideally for less than 10ms.  On a
multi-cpu machine, if the lock is held by another CPU and that process
is running, we want to spin waiting for the lock to free.   If not, we
can sleep.  We basically need some more sophisticated semantics around
these locks, or move to OS semaphores.

In fact, can't we sleep on an interruptible system call, and send
signals to processes when we release the lock?  That way we don't have
the 10ms sleep limitation.  One idea is to have a bytes for each backend
in shared memory and have each backend set the bit if it is waiting for
the semaphore.  There would be no contention with multiple backends
registering their sleep at the same time.

We have seen reports of 4-cpu systems having poor performance while the
system is only 12% busy, perhaps because the processes are all sleeping
waiting for the next tick.

I think multi-cpu machines are going to give us new challenges.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-30 21:14:01
Subject: Re: Performance TODO items
Previous:From: Tom LaneDate: 2001-07-30 20:46:51
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

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