Looks like that was the problem - got a day under the belt now with the
8.2.4 rev and all is back to normal.
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Karl Denninger wrote:
Aha!
BIG difference. I won't know for sure until the biz day tomorrow but
the "first blush" look
"Karl Denninger" <[EMAIL PROTECTED]> writes:
> Not sure where to start here. It appears that I'm CPU limited and the problem
> may be that this is a web-served application that must connect to the Postgres
> backend for each transaction, perform its queries, and then close the
> connection down -
Karl Denninger skrev:
> I've got an interesting issue here that I'm running into with 8.2.3
>
> This is an application that has run quite well for a long time, and has
> been operating without significant changes (other than recompilation)
> since back in the early 7.x Postgres days. But now we'r
Aha!
BIG difference. I won't know for sure until the biz day tomorrow but
the "first blush" look is that it makes a HUGE difference in system
load, and I no longer have the stats collector process on the top of the
"top" list..
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Karl Denninger <[EMAIL PROTECTED]> writes:
> Hm. now that's interesting. Stats collector IS accumulating
> quite a bit of runtime. me thinks its time to go grab 8.2.4.
I think Merlin might have nailed it --- the "stats collector bug" is
that it tries to write out the stats file way m
Hm. now that's interesting. Stats collector IS accumulating
quite a bit of runtime. me thinks its time to go grab 8.2.4.
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Merlin Moncure wrote:
On 7/25/07, Karl Denninger <[EMAIL PROTECTED]> wrote:
Yeah, the problem
On 7/25/07, Karl Denninger <[EMAIL PROTECTED]> wrote:
Yeah, the problem doesn't appear to be there. As I said, if I look at the
PS of the system when its bogging, there aren't a whole bunch of processes
stuck doing these, so while this does take a second or two to come back,
that's not that ba
Yeah, the problem doesn't appear to be there. As I said, if I look at
the PS of the system when its bogging, there aren't a whole bunch of
processes stuck doing these, so while this does take a second or two to
come back, that's not that bad.
Its GENERAL performance that just bites - the syst
Karl Denninger <[EMAIL PROTECTED]> writes:
> But here's the query that has a habit of taking the most time
> select forum, * from post where toppost = 1 and (replied > (select
> lastview from forumlog where login='theuser' and forum=post.forum and
> number is null)) is not false AND (rep
I've got an interesting issue here that I'm running into with 8.2.3
This is an application that has run quite well for a long time, and has
been operating without significant changes (other than recompilation)
since back in the early 7.x Postgres days. But now we're seeing a LOT
more load tha
10 matches
Mail list logo
