Re: LWLock contention: I think I understand the problem
От | Tatsuo Ishii |
---|---|
Тема | Re: LWLock contention: I think I understand the problem |
Дата | |
Msg-id | 20020103101825N.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: LWLock contention: I think I understand the problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: LWLock contention: I think I understand the problem
Re: LWLock contention: I think I understand the problem Re: LWLock contention: I think I understand the problem |
Список | pgsql-hackers |
> I have thought of a further refinement to the patch I produced > yesterday. Assume that there are multiple waiters blocked on (eg) > BufMgrLock. After we release the first one, we want the currently > running process to be able to continue acquiring and releasing the lock > for as long as its time quantum holds out. But in the patch as given, > each acquire/release cycle releases another waiter. This is probably > not good. > > Attached is a modification that prevents additional waiters from being > released until the first releasee has a chance to run and acquire the > lock. Would you try this and see if it's better or not in your test > cases? It doesn't seem to help on a single CPU, but maybe on multiple > CPUs it'll make a difference. > > To try to make things simple, I've attached the mod in two forms: > as a diff from current CVS, and as a diff from the previous patch. Ok, here is a pgbench (-s 10) result on an AIX 5L box (4 way). "7.2 with patch" is for the previous patch. "7.2 with patch (revised)" is for the this patch. I see virtually no improvement. Please note that xy axis are now in log scale.
В списке pgsql-hackers по дате отправления: