ilto:t...@sss.pgh.pa.us]
Sent: Sunday, 27 September 2009 2:42 PM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> Makes sense to me. Seems to be happening rarely now.
>
"Brendan Hill" writes:
> I think I've confirmed the fix. Using a dirty disconnect generator, I was
> able to reliably recreate the problem within about 30-60 seconds. The
> symptoms were the same as before, however it occurred around SSL_write
> instead of SSL_read - I assume this was due to the a
"Brendan Hill" writes:
> Bit of a catch 22 - since it happens rarely, there's no definitive
> confirmation that it's fixed the problem.
> Also, not sure if I'm comfortable applying the change and recompiling
> myself, wouldn't have a clue where to start.
Uh, so you haven't actually tested it at a
though, seems like a good idea
regardless, what do you think?
Regards,
-Brendan
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Sunday, 27 September 2009 2:42 PM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle p
> Cc: 'Craig Ringer'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Idle processes chewing up CPU?
> "Brendan Hill" writes:
>> My best interpretation is that an SSL client dirty disconnected while
>> running a request. This caused an infinite loop
5:25 AM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> My best interpretation is that an SSL client dirty disconnected while
> running a request. This caused an infinit
"Brendan Hill" writes:
> My best interpretation is that an SSL client dirty disconnected while
> running a request. This caused an infinite loop in pq_recvbuf(), calling
> secure_read(), triggering my_sock_read() over and over. Calling
> SSL_get_error() in secure_read() returns 10045 (either conne
Hi Craig, I've debugged the runaway process, though I'm not sure of the
solution yet.
My best interpretation is that an SSL client dirty disconnected while
running a request. This caused an infinite loop in pq_recvbuf(), calling
secure_read(), triggering my_sock_read() over and over. Calling
SSL_g
On 19/08/2009 1:34 PM, Brendan Hill wrote:
Hi Craig, thanks for the analysis. If I attach a debugger on the runaway
child process, will this halt execution for all the other child processes
(ie. freeze the server)? And, can I attach Visual Studio C++ 2008, or is
there a recommended debugger for W
endan Hill
Cc: pgsql-general@postgresql.org; 'Tom Lane'
Subject: Re: [GENERAL] Idle processes chewing up CPU?
On 19/08/2009 12:31 PM, Brendan Hill wrote:
> Hi Craig/Tom,
>
> I've managed to trap the full stack trace this time
The common part of those traces is:
&g
On 19/08/2009 12:31 PM, Brendan Hill wrote:
Hi Craig/Tom,
I've managed to trap the full stack trace this time
The common part of those traces is:
> ntdll.dll!KiFastSystemCallRet
> WS2_32.dll!WSARecv+0x65
> WSOCK32.dll!recv+0x31
> LIBEAY32.dll!BIO_sock_should_retry+0x57
> postgres.exe!my_soc
papers.com.au]
Sent: Wednesday, 5 August 2009 5:44 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-05 at 16:44 +1000, Brendan Hill wrote:
> Hi Craig,
>
> Sorry, I had the stack trace so I th
siveness is terrific.
-Brendan
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Wednesday, 5 August 2009 5:44 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-0
PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-05 at 15:26 +1000, Brendan Hill wrote:
> I copied a few of the stack traces (at the end of this email), it kept
> changing each time I looked.
Yep, that
On Wed, 2009-08-05 at 16:44 +1000, Brendan Hill wrote:
> Hi Craig,
>
> Sorry, I had the stack trace so I thought it was enough. I'll make sure the
> debug environment is set up and post the full stack traces again.
No worries. Sorry it cost you time.
I've extended the wiki article on win32 debug
On Wed, 2009-08-05 at 15:26 +1000, Brendan Hill wrote:
> I copied a few of the stack traces (at the end of this email), it kept
> changing each time I looked.
Yep, that's to be expected. If the process is busy, unless it's in a
_REALLY_ simple infinite loop, it'll be looping through some non-triv
ould_retry+0x57
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Wednesday, 29 July 2009 8:09 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
Craig Ringer wrote:
> Brendan Hill w
On Wed, Jul 29, 2009 at 12:08, Craig Ringer wrote:
> Craig Ringer wrote:
>>
>> Brendan Hill wrote:
>>>
>>> Hi Tom,
>>>
>>> Given it's on Windows, any suggestion for how I would get hold of this?
>>> (Process Monitor tool perhaps?)
>>
>> I think you can get stack traces from Process Monitor using "T
Craig Ringer wrote:
Brendan Hill wrote:
Hi Tom,
Given it's on Windows, any suggestion for how I would get hold of this?
(Process Monitor tool perhaps?)
I think you can get stack traces from Process Monitor using "Tools ->
Stack Summary". I find it a bit hard to interpret this data, though, a
Brendan Hill wrote:
Hi Tom,
Given it's on Windows, any suggestion for how I would get hold of this?
(Process Monitor tool perhaps?)
I think you can get stack traces from Process Monitor using "Tools ->
Stack Summary". I find it a bit hard to interpret this data, though, and
I'm not sure how
On Tue, Jul 28, 2009 at 7:17 PM, Brendan Hill wrote:
> Hi Tom,
>
> Given it's on Windows, any suggestion for how I would get hold of this?
> (Process Monitor tool perhaps?)
I'd bet there's a windows faq somewhere on system monitoring (googles)
Is this at all helpful, or is this problem beyond:
htt
l.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> Using the Process Explorer tool, I've noticed that a child postgres.exe is
> chewing up 25% of the CPU usage each (we have two dual-core CPUs,
presumably
> it's chewing up one core). Using
"Brendan Hill" writes:
> Using the Process Explorer tool, I've noticed that a child postgres.exe is
> chewing up 25% of the CPU usage each (we have two dual-core CPUs, presumably
> it's chewing up one core). Using SELECT * FROM pg_stat_activity, I located
> the process id (#3884), and it showed:
>
I recently migrated from MSSQL2000 to Postgres 8.3 for Windows, and overall
it's running great.
Using the Process Explorer tool, I've noticed that a child postgres.exe is
chewing up 25% of the CPU usage each (we have two dual-core CPUs, presumably
it's chewing up one core). Using SELECT * FROM
24 matches
Mail list logo
