Re: LWLock contention: I think I understand the problem
| От | Bruce Momjian |
|---|---|
| Тема | Re: LWLock contention: I think I understand the problem |
| Дата | |
| Msg-id | 200201031716.g03HGVj15783@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | 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
|
| Список | pgsql-hackers |
Tom Lane wrote: > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > 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. > > If anything, the revised patch seems to make things slightly worse :-(. > That agrees with my measurement on a single CPU. > > I am inclined to use the revised patch anyway, though, because I think > it will be less prone to starvation (ie, a process repeatedly being > awoken but failing to get the lock). The original form of lwlock.c > guaranteed that a writer could not be locked out by large numbers of > readers, but I had to abandon that goal in the first version of the > patch. The second version still doesn't keep the writer from being > blocked by active readers, but it does ensure that readers queued up > behind the writer won't be released. Comments? OK, so now we know that while the new lock code handles the select(1) problem better, we also know that on AIX the old select(1) code wasn't as bad as we thought. As to why we don't see better numbers on AIX, we are getting 100tps, which seems pretty good to me. Tatsuo, were you expecting higher than 100tps on that machine? My hardware is at listed at http://candle.pha.pa.us/main/hardware.html and I don't get over 16tps. I believe we don't see improvement on SMP machines using pgbench because pgbench, at least at high scaling factors, is really testing disk i/o, not backend processing speed. It would be interesting to test pgbench using scaling factors that allowed most of the tables to sit in shared memory buffers. Then, we wouldn't be testing disk i/o and would be testing more backend processing throughput. (Tom, is that true?) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: