launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Fri, 2010-11-12 at 16:03 +0100, Danilo Šegan wrote:
> > There is a lot of disk activity on the database server I think. I'm
> > seeing %wait time at up to 10%, when it normally is low. poimport
> and
> > one of the karma seem to be where the load is coming from, but it
> > doesn't seem that unusual. It might just be are batch jobs having
> > trouble on a database server with a fraction of the production RAM
> and
> > probably slower disk.
> 
> Isn't part of the problem that we are running both qastaging and
> staging
> DBs on the same server as well?  Is there some cache contention there
> as
> well?  Before we set-up qastaging, DB cache behaviour was much more
> predictable (i.e. for +translate pages, I knew that I need to load it
> once and expect it to time out, and it gets all the relevant indexes
> into RAM, with further refreshes on any other +translate pages
> working:
> today, caches get purged much more frequently).

I to expected that my first load would timeout, and subsequent loads
would be fine, but that is not the case when looking at an SP page. I
can load the SP pages on staging, but not qastaging:
    https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1777QS88

The execution path is on production, staging and qastaging, only
qastaging has an issue with calling
distroseries.getCurrentSourceReleases(). Is it possible that qastaging
is being starved?


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part