Re: spinlock contention
От | Heikki Linnakangas |
---|---|
Тема | Re: spinlock contention |
Дата | |
Msg-id | 4E03678E.2060404@enterprisedb.com обсуждение исходный текст |
Ответ на | spinlock contention (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: spinlock contention
|
Список | pgsql-hackers |
On 23.06.2011 18:42, Robert Haas wrote: > ProcArrayLock looks like a tougher nut to crack - there's simply no > way, with the system we have right now, that you can take a snapshot > without locking the list of running processes. I'm not sure what to > do about that, but we're probably going to have to come up with > something, because it seems clear that once we eliminate the lock > manager LWLock contention, this is a major bottleneck. ProcArrayLock is currently held for a relatively long period of time when a snapshot is taken, especially if there's a lot of backends. There are three operations to the procarray: 1. Advertising a new xid belonging to my backend. 2. Ending a transaction. 3. Getting a snapshot. Advertising a new xid is currently done without a lock, assuming that setting an xid in shared memory is atomic. To end a transaction, you acquire ProcArrayLock in exclusive mode. To get a snapshot, you acquire ProcArrayLock in shared mode, and scan the whole procarray. I wonder if it would be a better tradeoff to keep a "materialized" snapshot in shared memory that's updated every time a new xid is assigned or a transaction ends. Getting a snapshot would become much cheaper, as you could just memcpy the ready-built snapshot from shared memory into local memory. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: