Re: 7.3.1 New install, large queries are slow
От | Andrew Sullivan |
---|---|
Тема | Re: 7.3.1 New install, large queries are slow |
Дата | |
Msg-id | 20030117125939.J23422@mail.libertyrms.com обсуждение исходный текст |
Ответ на | Re: 7.3.1 New install, large queries are slow (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Fri, Jan 17, 2003 at 12:33:11PM -0500, Tom Lane wrote: > One reason not to crank up shared_buffers "just because you can" is that > there are operations (such as CHECKPOINT) that have to scan through all > the buffers, linearly. I don't *think* any of these are in > performance-critical paths, but nonetheless you're wasting CPU. I trust > the kernel to manage a huge number of buffers efficiently more than I > trust Postgres. For what it's worth, we have exactly that experience on our Sun E4500s. I had machines with 12 gig I was testing on, and I increased the buffers to 2 Gig, because truss was showing us some sluggishness in the system was tripping on the system call to get a page. It was satisifed right away by the kernel's cache, but the system call was still the most expensive part of the operation. After we'd increased the shared buffers, however, performance _degraded_ considerably. It now spent all its time instead managing the huge shared buffer, and the cost of that was much worse than the cost of the system call. So it is extremely dependent on the efficiency of PostgreSQL's use of shared memory as compared to the efficiency of the system call. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
В списке pgsql-performance по дате отправления: