Re: Just to give an idea ...

> -----Original Message-----
> From: Marc G. Fournier [mailto:scrappy(at)postgresql(dot)org]
> Sent: 05 June 2004 22:35
> To: Dave Page
> Cc: Marc G. Fournier; pgsql-www(at)postgresql(dot)org
> Subject: RE: [pgsql-www] Just to give an idea ...
>
> On Sat, 5 Jun 2004, Dave Page wrote:
>
> k, www.* is on pluto, not on mars or jupiter, and tends to
> stay pretty constant (occasional spikes) ...

OK, wrong planet - never was much good at astronomy...

> jupiter isn't web related load, but mail ...
>
> mars is a combination of things ...
>
> note that the point of my point was that Josh's opinion
> appears to be that "hub clients" are causing load issues on
> the servers, which is not accurate ...

Yeah, I got that and don't disagree. I'm having *very* hard job
understanding what we're doing that is maxing out such a server. I could
understand it if it was neptune (where the DBs are for those that don't
know). Remember a few days back I pointed you to
http://www.postgresql.org/index.php which just timed out after 5 minutes
or so whilst http://www.postgresql.org/index.html loaded in a couple of
seconds? Well, at the same time, the admin pages which access the DB and
are written in PHP were also working just fine. The major differences
between index.php and the admin pages are the styling, the number of db
accesses (1 for an admin page, maybe 4 for index.php), and the banner
ads (which aren't affecting it as the page will load even if they are
broken). None of that *should* cause such a massive performance problem
on a dual xeon or even PIII server, especially when the vast majority of
load is users accessing static HTML (which works just fine).

So it seems to me that there is something broken in PHP causing these
load problems that we are only hitting in certain circumstances.

BTW, index.php is working just fine right now :-(

> most of our "big
> clients" are running on neptune, where no postgresql.org VM
> is running, and the load on that machine *rarely* goes above
> 5, and when it does, I just need to kill off one of the
> aspseek processes and it drops back down again :)

Don't kill the indexer processes unless absolutely necessary - that can
screw the database up. Use '/usr/local/aspseek/bin/indexer -E' to safely
terminate the running indexers. It can take a little while to shut them
down...

Regards, Dave.