| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | "Vasudevan, Ramya" <ramya(dot)vasudevan(at)classmates(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: max_connections reached in postgres 9.3.3 |
| Date: | 2014-06-13 02:19:30 |
| Message-ID: | 1402625970.54448.YahooMailNeo@web122304.mail.ne1.yahoo.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> we have to be careful to rule out some underlying possible
> contributing factors before switching up things up to much.
Agreed.
> THP compaction in particular has plaguing servers throughout the
> company I work for;
I've seen many support tickets where turning off Transparent Huge
Page support has been the solution, but in all cases that I've seen
it is *system* CPU time that spikes when that is the problem, and
the OP here showed a graph where it was *user* CPU time spiking.
With high concurrency that is usually (in my experience) spinlocks
inside of PostgreSQL -- often spinlocks guarding transitions of hot
lightweight locks.
> we haven't figured out OP's system went loaded all of a sudden.
Agreed, although I feel that THP problems are not indicated because
system CPU time wasn't pegged, and write gluts seem unlikely based
on the IO wait numbers.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Saravanan Subramaniyan | 2014-06-13 03:25:43 | Re: OpenSSL Vulnerabilities |
| Previous Message | Tom Lane | 2014-06-13 01:27:02 | Re: Memory leak with CREATE TEMP TABLE ON COMMIT DROP? |