er is handling
> the
> load from the queries and database. So far we don't notice any issues with
> stuck commits on the new server, but it's only handling minimal load
> outside
> of amavis queries. We would like to run this on the original system,
> because
>
status data to reach at
> conclusion.
>
Okay. This is not during a time of incident. Another server is handling the
load from the queries and database. So far we don't notice any issues with
stuck commits on the new server, but it's only handling minimal load outside
of amavis
Hi Scott,
I believe something wrong with innodb parameters. It should be optimum. In
your case it might be too high or too low. Take a look at log file size.
Please send your show variables and show status data to reach at conclusion.
On Tue, Jan 13, 2009 at 3:35 AM, Scott Edwards wrote:
> All
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 wha
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 | am
