On Mar 15, 2015, at 13:45, Josh Krupka jkru...@gmail.com wrote:
Hmm that's definitely odd that it's swapping since it has plenty of free
memory at the moment. Is it still under heavy load right now? Has the
output of free consistently looked like that during your trouble times?
And it
Hi!
We at MusicBrainz have been having trouble with our Postgres install for the
past few days. I’ve collected all the relevant information here:
http://blog.musicbrainz.org/2015/03/15/postgres-troubles/
http://blog.musicbrainz.org/2015/03/15/postgres-troubles/
If anyone could provide tips,
On Mar 15, 2015, at 12:13 PM, Josh Krupka jkru...@gmail.com wrote:
It sounds like you've hit the postgres basics, what about some of the linux
check list items?
what does free -m show on your db server?
total used free sharedbuffers cached
Mem:
On 2015-03-15 13:08:13 +0100, Robert Kaye wrote:
On Mar 15, 2015, at 12:41 PM, Andreas Kretschmer
akretsch...@spamfence.net wrote:
just a wild guess: raid-controller BBU faulty
We don’t have a BBU in this server, but at least we have redundant power
supplies.
In any case, how
pls check this if it helps:
http://ubuntuforums.org/showthread.php?t=2258734
在 2015/3/15 18:54, Robert Kaye 写道:
Hi!
We at MusicBrainz have been having trouble with our
Postgres install for the past few days. I’ve
On Sun, Mar 15, 2015 at 8:07 AM, Robert Kaye r...@musicbrainz.org wrote:
what does free -m show on your db server?
total used free sharedbuffers cached
Mem: 48295 31673 16622 0 5 12670
-/+ buffers/cache:
On 15.3.2015 13:07, Robert Kaye wrote:
If the load problem really is being caused by swapping when things
really shouldn't be swapping, it could be a matter of adjusting your
swappiness - what does cat /proc/sys/vm/swappiness show on your server?
0
We adjusted that too, but no effect.
On 2015-03-15 13:07:25 +0100, Robert Kaye wrote:
On Mar 15, 2015, at 12:13 PM, Josh Krupka jkru...@gmail.com wrote:
It sounds like you've hit the postgres basics, what about some of the linux
check list items?
what does free -m show on your db server?
total
On Mar 15, 2015, at 12:41 PM, Andreas Kretschmer akretsch...@spamfence.net
wrote:
just a wild guess: raid-controller BBU faulty
We don’t have a BBU in this server, but at least we have redundant power
supplies.
In any case, how would a fault batter possibly cause this?
--
--ruaok
Hi!
What shows your pg_stat_bgwriter for one day?
On Mar 15, 2015, at 11:54, Robert Kaye r...@musicbrainz.org wrote:
Hi!
We at MusicBrainz have been having trouble with our Postgres install for the
past few days. I’ve collected all the relevant information here:
Robert Kaye r...@musicbrainz.org wrote:
Hi!
We at MusicBrainz have been having trouble with our Postgres install for the
past few days. I’ve collected all the relevant information here:
http://blog.musicbrainz.org/2015/03/15/postgres-troubles/
If anyone could provide tips,
It sounds like you've hit the postgres basics, what about some of the linux
check list items?
what does free -m show on your db server?
If the load problem really is being caused by swapping when things really
shouldn't be swapping, it could be a matter of adjusting your swappiness -
what does
On Sun, Mar 15, 2015 at 11:09 AM, Scott Marlowe scott.marl...@gmail.com wrote:
Clarification:
64MB work mem AND max_connections = 500 is a recipe for disaster. No
db can actively process 500 queries at once without going kaboom, ad
having 64MB work_mem means it will go kaboom long before it
On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
shared_mem of 12G is almost always too large. I'd drop it down to ~1G or so.
I think that's a outdated wisdom, i.e. not generally true. I've now seen
a significant number of systems where a larger shared_buffers can help
quite massively. The
On 2015-03-15 20:42:51 +0300, Ilya Kosmodemiansky wrote:
On Sun, Mar 15, 2015 at 8:20 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
shared_mem of 12G is almost always too large. I'd drop it down to ~1G or
so.
I think that's a
On Sun, Mar 15, 2015 at 8:46 PM, Andres Freund and...@2ndquadrant.com wrote:
That imo doesn't really have anything to do with it. The primary benefit
of a BBU with writeback caching is accelerating (near-)synchronous
writes. Like the WAL.
My point was, that having no proper raid controller
On Sun, Mar 15, 2015 at 7:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-15 13:07:25 +0100, Robert Kaye wrote:
On Mar 15, 2015, at 12:13 PM, Josh Krupka jkru...@gmail.com wrote:
It sounds like you've hit the postgres basics, what about some of the
linux check list items?
On 03/15/2015 09:43 AM, Scott Marlowe wrote:
* Consider installing perf (linux-utils-$something) and doing a
systemwide profile.
3.2 isn't the greatest kernel around, efficiency wise. At some point you
might want to upgrade to something newer. I've seen remarkable
differences around this.
On Sun, Mar 15, 2015 at 10:43 AM, Scott Marlowe scott.marl...@gmail.com wrote:
On Sun, Mar 15, 2015 at 7:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-15 13:07:25 +0100, Robert Kaye wrote:
On Mar 15, 2015, at 12:13 PM, Josh Krupka jkru...@gmail.com wrote:
It sounds like
On Sun, Mar 15, 2015 at 11:46 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-15 20:42:51 +0300, Ilya Kosmodemiansky wrote:
On Sun, Mar 15, 2015 at 8:20 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
shared_mem of 12G is almost
On 03/15/2015 05:08 AM, Robert Kaye wrote:
On Mar 15, 2015, at 12:41 PM, Andreas Kretschmer akretsch...@spamfence.net
wrote:
just a wild guess: raid-controller BBU faulty
We don’t have a BBU in this server, but at least we have redundant power
supplies.
In any case, how would a fault
On Sun, Mar 15, 2015 at 8:20 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
shared_mem of 12G is almost always too large. I'd drop it down to ~1G or so.
I think that's a outdated wisdom, i.e. not generally true.
Quite agreed. With note, that
Why is 500 connections insane. We got 32 CPU with 96GB and 3000 max
connections, and we are doing fine, even when hitting our max concurrent
connection peaks around 4500. At a previous site, we were using 2000
max connections on 24 CPU and 64GB RAM, with about 1500 max concurrent
On 15.3.2015 23:47, Andres Freund wrote:
On 2015-03-15 12:25:07 -0600, Scott Marlowe wrote:
Here's the problem with a large shared_buffers on a machine that's
getting pushed into swap. It starts to swap BUFFERs. Once buffers
start getting swapped you're not just losing performance, that huge
(please quote properly)
On 2015-03-15 19:55:23 -0400, mich...@sqlexec.com wrote:
Why is 500 connections insane. We got 32 CPU with 96GB and 3000 max
connections, and we are doing fine, even when hitting our max concurrent
connection peaks around 4500. At a previous site, we were using 2000
On 16/03/15 13:07, Tomas Vondra wrote:
On 16.3.2015 00:55, mich...@sqlexec.com wrote:
Why is 500 connections insane. We got 32 CPU with 96GB and 3000
max connections, and we are doing fine, even when hitting our max
concurrent connection peaks around 4500. At a previous site, we were
using 2000
On 2015-03-15 20:54:51 +0300, Ilya Kosmodemiansky wrote:
On Sun, Mar 15, 2015 at 8:46 PM, Andres Freund and...@2ndquadrant.com wrote:
That imo doesn't really have anything to do with it. The primary benefit
of a BBU with writeback caching is accelerating (near-)synchronous
writes. Like the
On 16.3.2015 00:55, mich...@sqlexec.com wrote:
Why is 500 connections insane. We got 32 CPU with 96GB and 3000
max connections, and we are doing fine, even when hitting our max
concurrent connection peaks around 4500. At a previous site, we were
using 2000 max connections on 24 CPU and 64GB
How many CPUs in play here on the PG Cluster Server,
cat /proc/cpuinfo | grep processor | wc -l
I see you got pg_stat_statements enabled, what are the SQL you
experience during this heavy load time? And does explain on them show a
lot of sorting activity that requires more work_mem.
On 15.3.2015 18:54, Ilya Kosmodemiansky wrote:
On Sun, Mar 15, 2015 at 8:46 PM, Andres Freund and...@2ndquadrant.com wrote:
That imo doesn't really have anything to do with it. The primary
benefit of a BBU with writeback caching is accelerating
(near-)synchronous writes. Like the WAL.
My
I agree with your counter argument about how high max_connections can
cause problems, but max_connections may not part of the problem here.
There's a bunch of depends stuff in there based on workload details, #
cpus, RAM, etc.
I'm still waiting to find out how many CPUs on this DB server.
On 2015-03-15 12:25:07 -0600, Scott Marlowe wrote:
Here's the problem with a large shared_buffers on a machine that's
getting pushed into swap. It starts to swap BUFFERs. Once buffers
start getting swapped you're not just losing performance, that huge
shared_buffers is now working against you
On 3/15/2015 6:54 AM, Robert Kaye wrote:
Hi!
We at MusicBrainz have been having trouble with our Postgres install
for the past few days. I’ve collected all the relevant information here:
http://blog.musicbrainz.org/2015/03/15/postgres-troubles/
If anyone could provide tips, suggestions or
I wasn't sure whether to post this in general, admin or performance but
since it is basically a performance question I went with performance.
I'm about to launch a new a website that is written using the Django web
framework and has PostgreSQL as the database server. Unfortunately I
can't
34 matches
Mail list logo
