http://drupal.

org/node/155850
I am wondering how the MySQL slaves would help now, as we don't have a way to channel writes to the master, and reads to slaves. There is a patch in the queue, but it has not been committed yet. We are moving to auto increment which are known to have issues with master/slave and therefore this patch is necessary. David Strauss can fill us in with a summary. I am also wondering if converting the database to InnoDB made matters worse. Although row locking happens rather than table locking, InnoDB still locks the entire table on an autoincrement insert (which we will have in the future, see above). The other thing is a suggestion: since the slowness is from a few queries, how about a drastic temporary solution: remove the functionality temporarily. For example the tracker we have now is semi functional after a patch hit Drupal 5 for it. We miss a lot of the old functionality but can live without it. So how about a review for identifying heavy queries, and then cutting down functionality for some of them? -MySQL tuning: We need to add this line to my.cnf: log-slow-queries = /var/log/mysql/mysql-slow.log , and then restart MySQL. Tune queries first: MySQL slow log parser Then tune your engine: Show InnoDB status walk through Then tune your settings: MySQL-Server-Settings-Tuning In particular we should do "show variables" 1. 2. 3. innodb_thread_concurrency can cause thrashing innodb_log_file_size dramatically effects performance innodb_commit_concurrency - Number of threads allowed at commit stage at the same time