You didn't say much about your workload, tuning or table, but... Looks like you have a configuration problem, or slow disks, or InnoDB contention problems.
You can get faster hardware, or make your log files or log buffer bigger (but first figure out whether they're too small!), or figure out what the contention problem is. If you can figure it out yourself, that might be a fun exercise; otherwise let me know and I can suggest someone who can help ;-) You might just need a RAID controller with a battery-backed write cache set to write-through policy. Aborting isn't possible once it gets to this stage, AFAIK. On Mon, Jan 12, 2009 at 5:05 PM, Scott Edwards <my...@foss.daxal.com> wrote: > All too frequently, I see commits stuck in this database. What can I do to > speed that up? Or, abort if it takes more than 40 seconds? This query here > for example appears to take 443 seconds so far. > > From mysqladmin processlist: > > Id | User | Host | db | Command |Time | State | Info > 14010 | amavis | mx:53008 | amavis | Query | 443 | | commit > > mysqld Ver 5.0.32-Debian_7etch8-log for pc-linux-gnu on x86_64 (Debian etch > distribution) > > I recompiled it once, but the debug symbols are still missing. The build > transcript didn't include -g during compile. I'm looking into redoing that > now. > > Thanks in advance, > > > Scott Edwards > > ------------------------------------------------------- > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=ba...@xaprb.com > > -- Baron Schwartz, Director of Consulting, Percona Inc. Our Blog: http://www.mysqlperformanceblog.com/ Our Services: http://www.percona.com/services.html -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
