On 6/25/10 9:41 AM, Kevin Grittner wrote:
Craig James wrote:
I always just assumed that lots of backends that would be harmless
if each one was doing very little.
Even if each is doing very little, if a large number of them happen
to make a request at the same time, you can have problems. T
Craig James writes:
> On 6/25/10 7:47 AM, Tom Lane wrote:
>> Any chance of going to 8.4? If this is what I suspect, you really need
>> this 8.4 fix:
>> http://archives.postgresql.org/pgsql-committers/2008-06/msg00227.php
>> which eliminated the thundering-herd behavior that previous releases
>> e
Craig James wrote:
if I upgrade a bloated database using the upgrade-in-place feature,
will 8.4.4 recover the bloat and return it to the OS, or do I still
have to recover the space manually (like vacuum-full/reindex, or
cluster, or copy/drop a table)?
There's no way for an upgrade in place to
Craig James wrote:
> I always just assumed that lots of backends that would be harmless
> if each one was doing very little.
Even if each is doing very little, if a large number of them happen
to make a request at the same time, you can have problems. This is
exactly where a connection pool c
On 6/25/10 7:47 AM, Tom Lane wrote:
Craig James writes:
On 6/24/10 9:04 PM, Tom Lane wrote:
sinval queue overflow comes to mind ... although that really shouldn't
happen if there's "no real load" on the server. What PG version is
this?
8.3.10. Upgraded based on your advice when I first as
Dear Criag,
also check for the possibility of installing sysstat in our system.
it goes a long way in collecting the system stats. you may
consider increasing the frequency of data collection by
changing the interval of cron job manually in /etc/cron.d/
normally its */10 , you may make it */2 for
Craig James writes:
> On 6/24/10 9:04 PM, Tom Lane wrote:
>> sinval queue overflow comes to mind ... although that really shouldn't
>> happen if there's "no real load" on the server. What PG version is
>> this?
> 8.3.10. Upgraded based on your advice when I first asked this question.
Any chanc
On 6/24/10 9:04 PM, Tom Lane wrote:
Craig James writes:
So what is it that will cause every single Postgres backend to come to life at
the same moment, when there's no real load on the server? Maybe if a backend
crashes? Some other problem?
sinval queue overflow comes to mind ... although
Craig James writes:
> So what is it that will cause every single Postgres backend to come to life
> at the same moment, when there's no real load on the server? Maybe if a
> backend crashes? Some other problem?
sinval queue overflow comes to mind ... although that really shouldn't
happen if t
Craig James wrote:
Now the question has narrowed down to this: what could trigger EVERY
postgres backend to do something at the same time? See the attached
output from "top -b", which shows what is happening during one of the
CPU spikes.
By the way: you probably want "top -b -c", which will
On Thu, 2010-06-24 at 17:50 -0700, Craig James wrote:
> I'm reviving this question because I never figured it out. To summarize: At
> random intervals anywhere from a few times per hour to once or twice a day,
> we see a huge spike in CPU load that essentially brings the system to a halt
> for
I'm reviving this question because I never figured it out. To summarize: At random
intervals anywhere from a few times per hour to once or twice a day, we see a huge spike
in CPU load that essentially brings the system to a halt for up to a minute or two.
Previous answers focused on "what is
Craig James wrote:
> On 4/7/10 5:47 PM, Robert Haas wrote:
> > On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
> >>> max_fsm_pages = 1600
> >>> max_fsm_relations = 625000
> >>> synchronous_commit = off
> >>
> >> You are playing with fire here. You should never turn this off unless
> >> you
On Wednesday 07 April 2010, Craig James wrote:
> I thought so too, except that I can't login during the flood. If the
> CPUs were all doing iowaits, logging in should be easy.
Busying out the drives is about the most reliable way to make logging in
very slow (especially, but not only, if it's d
David Rees wrote:
You need to find out what all those Postgres processes are doing. You
might try enabling update_process_title and then using ps to figure
out what each instance is using.
That's what the addition of "-c" to top I suggested does on Linux; it
shows the updated process titles w
On Wed, Apr 7, 2010 at 10:50 PM, David Rees wrote:
> On Wed, Apr 7, 2010 at 7:06 PM, Craig James
> wrote:
>> On 4/7/10 5:47 PM, Robert Haas wrote:
>>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
> synchronous_commit = off
You are playing with fire here. You should never tur
On Wed, Apr 7, 2010 at 7:06 PM, Craig James wrote:
> On 4/7/10 5:47 PM, Robert Haas wrote:
>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
synchronous_commit = off
>>>
>>> You are playing with fire here. You should never turn this off unless
>>> you do not care if your data becomes irr
On 4/7/10 5:47 PM, Robert Haas wrote:
On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
max_fsm_pages = 1600
max_fsm_relations = 625000
synchronous_commit = off
You are playing with fire here. You should never turn this off unless
you do not care if your data becomes irrecoverably corrup
On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
>> max_fsm_pages = 1600
>> max_fsm_relations = 625000
>> synchronous_commit = off
>
> You are playing with fire here. You should never turn this off unless
> you do not care if your data becomes irrecoverably corrupted.
That is not correct.
Craig James writes:
> On 4/7/10 3:36 PM, Joshua D. Drake wrote:
>> To have your CPUs so flooded that they are the cause of an inability to
>> log in is pretty suspect.
> I thought so too, except that I can't login during the flood. If the CPUs
> were all doing iowaits, logging in should be easy
On Wed, Apr 7, 2010 at 3:57 PM, Craig James wrote:
> On 4/7/10 3:36 PM, Joshua D. Drake wrote:
>> My guess is that it is not CPU, it is IO and your CPU usage is all WAIT
>> on IO.
>>
>> To have your CPUs so flooded that they are the cause of an inability to
>> log in is pretty suspect.
>
> I thoug
...Can you
correlate the spikes with anything like that?
Not that I know of. Just regular web traffic. On the backup server
these events happen occasionally even when there is little or no web
traffic, and nobody logged in doing maintenance.
What, if anything, are you logging in the Postgr
On 4/7/10 2:59 PM, Tom Lane wrote:
Craig James writes:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
events.
On 4/7/10 3:36 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:45 -0700, Craig James wrote:
On 4/7/10 2:40 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU lo
On Wed, Apr 7, 2010 at 2:37 PM, Craig James wrote:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> events.
On Wed, 2010-04-07 at 14:45 -0700, Craig James wrote:
> On 4/7/10 2:40 PM, Joshua D. Drake wrote:
> > On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
> >> Most of the time Postgres runs nicely, but two or three times a day we get
> >> a huge spike in the CPU load that lasts just a short time
Craig James writes:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> events. During these spikes, the sys
Craig James wrote:
I managed to capture one such event using top(1) with the "batch"
option as a background process. See output below
You should add "-c" to your batch top capture, then you'll be able to
see what the individual postmaster processes are actually doing when
things get stuck.
On 4/7/10 2:40 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Som
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> even
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
events. During these spikes, the system is completely unresponsi
31 matches
Mail list logo
