Re: Monitoring buffercache...
От | Scott Marlowe |
---|---|
Тема | Re: Monitoring buffercache... |
Дата | |
Msg-id | dcc563d10811241324t116f6e71j4863632b2c0c09a5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Monitoring buffercache... (Brad Nicholson <bnichols@ca.afilias.info>) |
Ответы |
Re: Monitoring buffercache...
Re: Monitoring buffercache... |
Список | pgsql-performance |
On Mon, Nov 24, 2008 at 12:52 PM, Brad Nicholson <bnichols@ca.afilias.info> wrote: >> I just ran it in a loop over and over on my 8 core opteron server and >> it ran the load factor up by almost exactly 1.0. Under our normal >> daily load, it sits at 1.9 to 2.5, and it climbed to 2.9 under the new >> load of running that query over and over. So, it doesn't seem to be >> blocking or anything. > > The internal docs for pg_buffercache_pages.c state: > > "To get a consistent picture of the buffer state, we must lock all > partitions of the buffer map. Needless to say, this is horrible > for concurrency. Must grab locks in increasing order to avoid > possible deadlocks." Well, the pg hackers tend to take a parnoid view (it's a good thing TM) on things like this. My guess is that the period of time for which pg_buffercache takes locks on the buffer map are short enough that it isn't a real big deal on a fast enough server. On mine, it certainly had no real negative effects for the 5 minutes or so it was running in a loop. None I could see, and we run hundreds of queries per second on our system. Of course, for certain other types of loads it could be a much bigger issue. But for our load, on our machine, it was virtually unnoticeable.
В списке pgsql-performance по дате отправления: