On Sat, Nov 13, 2010 at 4:03 AM, Danilo Šegan <[email protected]> wrote: > 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).
Probably. We knew there might be - and we can look into how to best address this long term. It is a bit annoying. OTOH efficient queries *should* be able to serve many LP pages out of disk: much of LP is inefficient. > Also, if we are indeed seeing big load from poimport on qastaging, are > we perhaps running this script on both staging and qastaging? Perhaps > it's a script that's best run on demand (I'd instead suggest cleaning up > the import queue, but having it duplicated on staging is such a useful > debugging tool that I'd hate to lose that). We need such debugging tools; we'll be moving some machines around (logically, not physically ;)) to get a dedicated scripting test box which will remove some contention from the appserver (but not the db). -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
