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/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
