Re: Performance Tuning Document?
| От | Steve Wolfe |
|---|---|
| Тема | Re: Performance Tuning Document? |
| Дата | |
| Msg-id | 004001c1d67c$c12c9de0$d281f6cc@iboats.com обсуждение исходный текст |
| Ответ на | Performance Tuning Document? (Matthew Kirkwood <matthew@hairy.beasts.org>) |
| Ответы |
Re: Performance Tuning Document?
|
| Список | pgsql-general |
> I'm playing with OSDB (http://osdb.sf.net/) and trying to get > the best numbers possible out of it. > > I haven't been able to find anything resembling a performance > tuning document. Does such a thing exist? Unfortunately, not in any complete sense. There are a few guides from Bruce that make a good effort, but there seems to be a *lot* of other information that can only be gleaned by either being a developper or following the list very closely for a few years. Bruce's hardware tuning guide also doesn't really give any sorts of guidelines or numbers to start from, it merely explains concepts and leaves the investigation and twiddling to you. > Under the "crossSectionTests(Mixed IR)" part of an OSDB run, a > large number of shared_buffers causes severe slowdown on one of > the tests -- it goes from a little over 200 seconds to nearly > 2000. I suspect internal lock contention, or maybe it's just > that the read() path in Linux is quicker than PG's own cache? > > Any tips and tricks available? Yes. Huge, raging amounts of shared buffers do have the consequence of diminishing your disk cache size. You want to make sure that you can always keep the *entire* database in disk cache, or you end up taking a performance hit by having to read from disk, in the same spirit of keeping your machine from swapping. Steve
В списке pgsql-general по дате отправления: