From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Fehrle <brianf(at)consistentstate(dot)com> |
Cc: | pgsql-general General <pgsql-general(at)postgreSQL(dot)org> |
Subject: | Re: Server hitting 100% CPU usage, system comes to a crawl. |
Date: | 2011-11-01 18:17:57 |
Message-ID: | 16387.1320171477@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Brian Fehrle <brianf(at)consistentstate(dot)com> writes:
> Update on this:
> We did a switchover to another machine with the same hardware, however
> this system was running on some older parameters we had set in the
> postgresql.conf file.
> So we went from 400 max_connections to 200 max_connections, and 160MB
> work_mem to 200MB work_mem. And now on this other system, so far it
> seems to be running ok.
> Other than the obvious fact that each connection has a certain amount of
> memory usage, is there something else to watch for when increasing
> connections to numbers like 400? When we had the issue of the system
> jumping to 100% cpu usage, even at that point our number of backends to
> the cluster was at MAX 250, but generally in the 175 range, so well
> below our 400 max_connections we allow. So could this be the culprit?
Well, yeah, the pre-8.4 sinval problems I mentioned scale with the
number of live backends. When you have many more backends in the system
that will contribute to the problem, even --- in fact, especially --- if
the extra ones are idle.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Samba | 2011-11-01 18:35:44 | Disable Streaming Replication ==> Stop WAL Sender on master and WAL receiver on Slave |
Previous Message | Brian Fehrle | 2011-11-01 17:56:00 | Re: Server hitting 100% CPU usage, system comes to a crawl. |