| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Brian Wipf <brian(at)clickspace(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org, "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
| Subject: | Re: Disconnects hanging server |
| Date: | 2007-12-06 16:36:57 |
| Message-ID: | 16153.1196959017@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Brian Wipf <brian(at)clickspace(dot)com> writes:
> Nearly 100% of the CPU is going into pmap_remove_range. The stack
> trace for pmap_remove_range, viewable within Shark, is:
> -> pmap_remove_range
> --> pmap_remove
> ---> vm_map_simplify
> ----> vm_map_remove
> -----> task_terminate_internal
> ------> exit1
> -------> exit
> --------> unix_syscall64
> ---------> lo64_unix_scall
In case it's not obvious, this is a kernel performance bug, which
you should report to Apple.
In the meantime you might want to think about backing off your
shared_buffers setting. I would suppose that the performance bug
is being triggered by a very large shared memory segment (you
said 3Gb right?).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henrik | 2007-12-06 16:47:00 | Re: Unreasonable size of table pg 8.2.5 |
| Previous Message | Erik Jones | 2007-12-06 16:21:08 | Re: pg_dump and server responsiveness |