Re: AW: CommitDelay performance improvement
От | Philip Warner |
---|---|
Тема | Re: AW: CommitDelay performance improvement |
Дата | |
Msg-id | 3.0.5.32.20010227211809.0311d720@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | AW: CommitDelay performance improvement (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
At 10:56 27/02/01 +0100, Zeugswetter Andreas SB wrote: > >> > I agree that 30k looks like the magic delay, and probably 30/5 would be a >> > good conservative choice. But now I think about the choice of number, I >> > think it must vary with the speed of the machine and length of the >> > transactions; at 20tps, each TX is completing in around 50ms. > >I think disk speed should probably be the main factor. >After the first run 30k/5 also seemed the best here, but running the test >again shows, that the results are only reproducible after a new initdb. >Anybody else see reproducible results without previous initdb ? I think we want something that reflects the chance of a time-saving as a result of a wait, which is why I suggested having each backend monitor commits/sec, then basing the delay on some % of that number. eg. if commits/sec = 1, then it's either low-load, or long tx's, in either case CommitDelay won't help. Similarly, if we have 1000 commits/sec, then we have a very fast system and/or disk, and CommitDelay of 10ms is clearly glacial. AFAICS, dynamically monitoring commits/sec (or a similar statistic) is TOWTG, but in all cases we need to set a max on CommitDelay to prevent individual TXs getting too long (although I am unsure if the latter is *really* necessary, it is far better to be safe). Note: commits/sec need to be kept for each backend so we can remove the contribution of the backend that is considering waiting. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: