| From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: I/O on select count(*) |
| Date: | 2008-05-19 15:47:38 |
| Message-ID: | Pine.GSO.4.64.0805191137480.25115@westnet.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 19 May 2008, Matthew Wakeling wrote:
> Does it really take that long to zero out 8kB of RAM? I thought CPUs were
> really quick at doing that!
You don't get the whole CPU--you get time slices of one. Some of the
cases complaints have come in about have over a thousand connections all
fighting for CPU time, and making every one of them block for one guy who
needs to fiddle with memory for a while can be a problem. If you're
unlucky you won't even be on the same CPU you started on each time you get
a little check of time, and you'll run at the speed of RAM rather than
that of the CPU--again, fighting for RAM access with every other process
on the server.
The real question in my mind is why this turns into a bottleneck before
the similar task of cleaning the 16MB XLOG segment does. I expected that
one would need to be cracked before the CLOG switch time could possibly be
an issue, but reports from the field seem to suggest otherwise.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-05-19 15:53:49 | Re: I/O on select count(*) |
| Previous Message | Tom Lane | 2008-05-19 15:37:58 | Re: I/O on select count(*) |