Hello Kevin
Getting back at this.
> -Original Message-
> From: Kevin Grittner [mailto:kgri...@gmail.com]
> Sent: Mittwoch, 23. November 2016 17:04
> To: Charles Clavadetscher
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] max_connections limit violat
On Wed, Nov 23, 2016 at 4:43 AM, Charles Clavadetscher
wrote:
> From: Kevin Grittner [mailto:kgri...@gmail.com]
>> Is it possible to upgrade? You are missing over a year's worth
>> of fixes for serious bugs and security vulnerabilities.
>
> Yes. Actually it is foreseen to move to 9.6 (and RedHat
Hello Kevin
Thank you very much for your input. I appreciate it very much.
> -Original Message-
> From: Kevin Grittner [mailto:kgri...@gmail.com]
> Sent: Dienstag, 22. November 2016 22:37
> To: Charles Clavadetscher
> Cc: pgsql-general@postgresql.org
> Sub
On Tue, Nov 22, 2016 at 12:48 PM, Charles Clavadetscher
wrote:
> We are using PostgreSQL 9.3.10 on RedHat (probably 6.x).
Is it possible to upgrade? You are missing over a year's worth of
fixes for serious bugs and security vulnerabilities.
https://www.postgresql.org/support/versioning/
> Amo
Hello
We are using PostgreSQL 9.3.10 on RedHat (probably 6.x).
The database is hosted by an internal service provider and we have
superuser access to it over a PG client, e.g. psql, but not to the OS.
For that reason we only have access to the log files indirectly using
some of the built in syste
We turned off NUMA in the BIOS on Jul 2nd and haven't seen the issue since -
(though once last week, we had the connections count go up to 1000, but
recovered in few seconds on its own). Will keep you all posted when I have more
updates.
Appreciate everyone's help, comments and suggestions so f
Erik van Zijst writes:
> On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure wrote:
>> In your case user% is dominating system load. Along with the high cs
>> this is really suggesting spinlock contention. A 'perf top' is
>> essential for identifying the culprit. It's very possible that 9.4
>> wil
On Fri, Jun 20, 2014 at 12:58 AM, Erik van Zijst
wrote:
> On Thu, Jun 19, 2014 at 10:10 PM, Erik van Zijst
> wrote:
>> On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure wrote:
>>> In your case user% is dominating system load. Along with the high cs
>>> this is really suggesting spinlock contentio
On Thu, Jun 19, 2014 at 10:10 PM, Erik van Zijst
wrote:
> On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure wrote:
>> In your case user% is dominating system load. Along with the high cs
>> this is really suggesting spinlock contention. A 'perf top' is
>> essential for identifying the culprit. I
On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure wrote:
> In your case user% is dominating system load. Along with the high cs
> this is really suggesting spinlock contention. A 'perf top' is
> essential for identifying the culprit. It's very possible that 9.4
> will fix your problem...see:
> ht
We do record perf data. For each incident we've had the data looks about
the same. Unfortunately, I can't read much into it. Besides it getting
stuck on a spinlock. But why and with what?
### from perf report
53.28% postmaster postgres [.] s_lock
6.22% postmaster
Hi Borislav – Thank You for the update and all the information. It does look
like we are on the same boat. And I feel the same too - maxing out on
max_connections is just a symptom. pgbouncer may help alleviate the problem
(though in your case it didn’t) and is definitely good to have either wa
On Thu, Jun 19, 2014 at 5:12 PM, Borislav Ivanov wrote:
> However, most people on our team think that the number of connections is
> purely a symptom of the actual problem. We would love to be wrong about
> this. But for now we feel the high number of connections contributes for
> preserving the p
Hi Ramya,
We experience exactly the same problem here at Bitbucket. From what I can
tell the major difference between your setup and ours is that you run 9.3.3
and we run 9.2.8. Our post for the issues is at
http://www.postgresql.org/message-id/CAJ+wzrb1qhz3xuoeSy5mo8i=E-5OO9Yvm6R+VxLBGaPB=ue...@m
On Thu, Jun 19, 2014 at 2:35 PM, Kevin Grittner wrote:
> "Vasudevan, Ramya" wrote:
>
>> On the waiting queries - When we reached 1500 connections, we
>> had 759 connections that were in active state (116 COMMIT, 238
>> INSERT, UPDATE 176, 57 AUTHENTICATION, 133 BIND. These active
>> INSERTS and
"Vasudevan, Ramya" wrote:
> On the waiting queries - When we reached 1500 connections, we
> had 759 connections that were in active state (116 COMMIT, 238
> INSERT, UPDATE 176, 57 AUTHENTICATION, 133 BIND. These active
> INSERTS and UPDATES also includes the 80-90 waiting sessions (We
> checked
Merlin, Thank you for the response.
On the waiting queries - When we reached 1500 connections, we had 759
connections that were in active state (116 COMMIT, 238 INSERT, UPDATE 176, 57
AUTHENTICATION, 133 BIND. These active INSERTS and UPDATES also includes the
80-90 waiting sessions (We chec
Merlin Moncure 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 Tra
On Thu, Jun 12, 2014 at 3:32 PM, Kevin Grittner wrote:
> Merlin Moncure wrote:
>
>> or something else entirely.
>
>
> It strikes me that this might be relevant:
Agreed. The stock advice to many, many problems of this sort is 'use
pgbouncer' but it can be hard to work in a lot of code bases and
Merlin Moncure wrote:
> or something else entirely.
It strikes me that this might be relevant:
http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsq
quickly realized that we already had a
high number (1500)
Thank You
Ramya
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, June 11, 2014 4:24 PM
To: Vasudevan, Ramya
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] max_connections reached in
@postgresql.org
Subject: Re: [GENERAL] max_connections reached in postgres 9.3.3
On Thu, Jun 12, 2014 at 1:23 PM, Vasudevan, Ramya
wrote:
> Thank you for the response.
>
> On further investigation, we found out that select statements were happening
> normally. But DMLs (writes to
On Thu, Jun 12, 2014 at 1:51 PM, Vasudevan, Ramya
wrote:
> Thanks Merlin.
>
> We did look at the locks in the DB and all we saw were RowExclusiveLock,
> AccessShareLock, RowShareLock, AccessExclusiveLock. The ExclusiveLocks we saw
> were all in the virtualxids.
>
> I think the max_connections ma
On Thu, Jun 12, 2014 at 1:23 PM, Vasudevan, Ramya
wrote:
> Thank you for the response.
>
> On further investigation, we found out that select statements were happening
> normally. But DMLs (writes to the DB) were hung for minutes at a time, and
> some of them went through. And we had 2 checkpoin
On Wed, Jun 11, 2014 at 1:24 PM, Vasudevan, Ramya
wrote:
> Our set up:
>
> · Db version: postgres 9.3.3
>
> · OS: CentOS 6.5
>
> · kernel Version - Linux 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3
> 21:39:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> · cpu - 24 pro
On 06/11/2014 11:24 AM, Vasudevan, Ramya wrote:
Our set up:
·Db version: postgres 9.3.3
·OS: CentOS 6.5
·kernel Version - Linux 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3
21:39:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
·cpu - 24 proc
·memory - 768 GB
·The disks are SAN fiber.
·We have str
Our set up:
* Db version: postgres 9.3.3
* OS: CentOS 6.5
* kernel Version - Linux 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3
21:39:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
* cpu - 24 proc
* memory - 768 GB
* The disks are SAN fiber.
*
Sireesha Modumudi wrote:
> I am using postgres 8.3.9 on SUSE 64 bit. By default max_connections
is 100, but I want to know if
> this can be increased, if so, what should we take into consideration?
It can be increased, but you habe to restart the server for
the change to take effect.
It is not a
According to
http://www.postgresql.org/docs/8.3/static/kernel-resources.html
The maximum shared memory usage of a connection in bytes is
1800 + 270 * max_locks_per_transaction
max_locks_per_transaction default is 64
19080 Bytes
or .018 mb's per connection
or
1.819 mb at 100 default connect
"Modumudi, Sireesha" wrote:
> I am using postgres 8.3.9 on SUSE 64 bit. By default
> max_connections is 100, but I want to know if this can be
> increased, if so, what should we take into consideration?
http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
-Kevin
--
Sent via pgs
On Wed, Sep 5, 2012 at 2:30 PM, Modumudi, Sireesha
wrote:
> Hi all,
>
> I am using postgres 8.3.9 on SUSE 64 bit. By default max_connections is 100,
> but I want to know if this can be increased, if so, what should we take into
> consideration?
If you're considering raising this then you should p
Hi all,
I am using postgres 8.3.9 on SUSE 64 bit. By default max_connections is
100, but I want to know if this can be increased, if so, what should we
take into consideration?
Thank you,
Sireesha
On Thu, May 26, 2011 at 5:30 PM, Tom Lane wrote:
>
> OK, maybe word it as "If you're considering raising max_connections much
> above 100, ..." ?
I think it can be even shorter and to the point:
If you're considering raising max_connections consider pooling instead.
--
Sent via pgsql-general m
Thank Graig for the links. You have been very helpful.
When I get time, I will definitely read over the materials to get familar
with Postgres.
Have a wonderful night.
Edison
On Sun, May 29, 2011 at 7:27 PM, Craig Ringer
wrote:
> On 05/30/2011 03:26 AM, Edison So wrote:
>
>> Thanks Graig for y
On 05/30/2011 03:26 AM, Edison So wrote:
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I
have just started to use Postgres 9.0 with no prior training.
Google is great :-)
http://www.postgresql.org/docs/curr
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I have
just started to use Postgres 9.0 with no prior training.
I live in Canada and where I live has no instructor-led training on Postgres
9.0 with replication. C
On 29/05/2011 4:39 PM, Craig Ringer wrote:
On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise pe
On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise people that they might want to
consider it.
Can anyone tell me that if the max_connections is above 100, the server will
use pooling instead?
For all participants in this particular dsicuss, what is the reasonable
value for max_connections without causing any harm to the Postgres 9.0
server.
I am a nonvice Postgres user so any advice is al
On 05/25/2011 10:58 PM, Craig Ringer wrote:
max_connections = 100 # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a connection pool instead. See:
# http://wiki.postgresql.org/max_connections
#
# Not
On Fri, May 27, 2011 at 6:22 AM, Craig Ringer
wrote:
> Best performance is often obtained with the number of _active_ connections
> in the 10s to 30s on commonplace hardware. I'd want to use "hundreds" -
> because mailing list posts etc suggest that people start running into
> problems under load
2011/5/27 Tom Lane :
> Craig Ringer writes:
>> On 05/26/2011 09:48 PM, Tom Lane wrote:
>>> Craig Ringer writes:
max_connections = 100 # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a con
Craig Ringer writes:
> On 05/26/2011 09:48 PM, Tom Lane wrote:
>> Craig Ringer writes:
>>> max_connections = 100 # (change requires restart)
>>> # WARNING: If you're about to increase max_connections above 100, you
>>> # should probably be using a connection pool instead. See:
>
On 05/26/2011 09:48 PM, Tom Lane wrote:
Craig Ringer writes:
max_connections = 100 # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a connection pool instead. See:
# http://wiki.postgresql.org/max_
Craig Ringer writes:
> max_connections = 100 # (change requires restart)
> # WARNING: If you're about to increase max_connections above 100, you
> # should probably be using a connection pool instead. See:
> # http://wiki.postgresql.org/max_connections
This gives the impress
On Wed, May 25, 2011 at 10:58 PM, Craig Ringer
wrote:
> There might be a very cheap and simple way to help reduce the number of
> people running into problems because they set massive max_connections values
> that their server cannot cope with instead of using pooling.
>
> In the default postgresq
There might be a very cheap and simple way to help reduce the number of
people running into problems because they set massive max_connections
values that their server cannot cope with instead of using pooling.
In the default postgresql.conf, change:
max_connections = 100 # (c
12 de Novembro de 2008 14:41:06
Assunto: Re: [ADMIN] [GENERAL] MAX_CONNECTIONS ??
paulo matadr wrote:
> I need help to alter max_connections em my database, this parameter
> stay in defalt MAX_CONNECTIONS=100
> I want to change for MAX_CONNECTIONS=300. about parameters below,
> n
paulo matadr wrote:
> I need help to alter max_connections em my database, this parameter
> stay in defalt MAX_CONNECTIONS=100
> I want to change for MAX_CONNECTIONS=300. about parameters below,
> need to change anything?
>
> 1 -sysctl.conf
>
> kernel.shmmax = 68719476736
> kernel.shmall = 429496
I need help to alter max_connections em my database, this parameter stay in
defalt MAX_CONNECTIONS=100
I want to change for MAX_CONNECTIONS=300.
about parameters below, need to change anything?
1 -sysctl.conf
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
# - Memory -
2-Postgresql.conf
Hello,
we are using SCO OpenServer6 and Postgresql 8.1.4.
We increased the parameter max_connections in the postgresql.conf to 300.
In Section 16.4.1 of the dokumentation we try to find out how to adjust
depending parameters. But we can't figure it out.
What would be reasonable values for the
"John D. Burger" <[EMAIL PROTECTED]> writes:
> I'm now fiddling with some of the performance parameters, and I'm
> wondering about max_connections. The default appears to be 100 - this
> is at least an order of magnitude higher than I need. Would much be
> saved by dropping this down to 10 or
I've recently succeeded in lobbying my sysadmins to upgrade from 7.2.0
to 7.4.8 (thanks to everyone for the advice on how to leverage this).
I'm now fiddling with some of the performance parameters, and I'm
wondering about max_connections. The default appears to be 100 - this
is at least an o
53 matches
Mail list logo
