On Mon, Nov 2, 2015 at 7:32 AM, Tom Dearman wrote:
> Thanks for the prompt replies so far, I have done some more investigation to
> be able to clearly answer some of the question.
>
> The original shared-buffers was 8G and I have done another run on Friday
> using this old value instead of my more
On 11/2/15 9:32 AM, Tom Dearman wrote:
My system under load is using just over 500M of the shared_buffer at
usage count >= 3. Our system is very write heavy, with all of the big
tables written to but not read from (at least during the load test run).
Although our db will grow (under load) to 1
Thanks for the prompt replies so far, I have done some more investigation to be
able to clearly answer some of the question.
The original shared-buffers was 8G and I have done another run on Friday using
this old value instead of my more recent 1G limit. There was no noticeable
improvement. I
On Wed, Oct 28, 2015 at 8:43 AM, Tom Dearman wrote:
> We have a performance problem when our postgres is under high load. The CPU
> usage is very low, we have 48 cores for our postgres and the idle time
> averages at 90%. The problem is we get spikes in our transaction times
> which don’t appear
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Tom Dearman
Sent: Wednesday, October 28, 2015 11:44 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Waiting on ExclusiveLock on extension 9.3, 9.4 and 9.5
We have a performance problem when
On 10/28/15 12:11 PM, Tom Dearman wrote:
It is also interesting that a later attempt to get the exclusive lock by
process 41911 says it is waiting for id 41907 even though according to
the log other processes have already acquired the lock.
Those would be different acquisitions of the same lock
l-general@postgresql.org>
> Subject: [GENERAL] Waiting on ExclusiveLock on extension 9.3, 9.4 and 9.5
>
> We have a performance problem when our postgres is under high load. The CPU
> usage is very low, we have 48 cores for our postgres and the idle time
> averages at 90
