On Sun, Jul 25, 2010 at 2:47 AM, Robert Collins <[email protected]> wrote:
> - We have interlinked performance problems; the DB is a choke point > for writes, and we write a lot - enough that when a backup goes wrong, > we have a timeout spike on lpnet and edge, because we have little I don't follow this. What backups go wrong? writes are generally not a problem, except when they are done in bulk. Importing a translation can do a lot of writes. Making a new branch can do a lot of writes. Spreading these into multiple transactions could ease pain. > headroom. Queries that take 6000ms on staging (when in cache) take > 14000ms on prod slaves, and 24000ms or more on prod main : we're I've seen situations where this is false btw - people trying to diagnose slow queries on production using staging, but staging has data that is a week out of date and the performance problem does not exist there. But yes, an idle staging will perform better than a loaded production (production dbs have more ram and cores, but shared over orders of magnitude more connections). One of my focuses is to get people using the slave databases much more aggressively. The more the slave databases are used, the faster and more scalable we get. The master database is not running on the server with 16 cores because of the write load, but because of its read load. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
