Re: User concurrency thresholding: where do I look?
Вложения
В списке pgsql-performance по дате отправления:
| От | Simon Riggs |
|---|---|
| Тема | Re: User concurrency thresholding: where do I look? |
| Дата | |
| Msg-id | 1185465076.4190.87.camel@ebony.site обсуждение исходный текст |
| Ответ на | Re: User concurrency thresholding: where do I look? ("Jignesh K. Shah" <J.K.Shah@Sun.COM>) |
| Ответы |
Re: User concurrency thresholding: where do I look?
CLOG Patch |
| Список | pgsql-performance |
On Thu, 2007-07-26 at 11:27 -0400, Jignesh K. Shah wrote:
> However at 900 Users where the big drop in throughput occurs:
> It gives a different top "consumer" of time:
postgres`LWLockAcquire+0x1c8
> postgres`SimpleLruReadPage+0x1ac
> postgres`TransactionIdGetStatus+0x14
> postgres`TransactionLogFetch+0x58
TransactionIdGetStatus doesn't directly call SimpleLruReadPage().
Presumably the compiler has been rearranging things??
Looks like you're out of clog buffers. It seems like the clog buffers
aren't big enough to hold clog pages for long enough and the SELECT FOR
SHARE processing is leaving lots of additional read locks that are
increasing the number of clog requests for older xids.
Try the enclosed patch.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера