# Thesqld constant CPU usage when absolutly nothing is connected and no queries

MySQL

I'm using mysql on a windows development machine, and all was good for a long time.

But today my PC was running slowly, and I noticed mysqld.exe is using between 25% and 40% CPU.

I've tried rebooting and giving it some time, but the CPU usage is fairly constant even when idleing on the desktop.
I've noticed the hard drive is working quite hard too, probably because of mysqld

I'm certain nothing is using the server as the only thing that would connect to it is the application on my local machine that I am developing, and that is not running.

But, just to be sure I ran the following statements

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysqladmin -u root -p status
Uptime: 995  Threads: 1  Questions: 2  Slow queries: 0  Opens: 67  Flush tables: 1
Open tables: 60  Queries per second avg: 0.002

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysqladmin -u root -p processlist
+----+------+----------------+----+---------+------+-------+------------------+
| Id | User | Host           | db | Command | Time | State | Info             |
+----+------+----------------+----+---------+------+-------+------------------+
| 2  | root | localhost:1775 |    | Query   | 0    | init  | show processlist |
+----+------+----------------+----+---------+------+-------+------------------+


which also seem to show the sever isn't doing anything.

So, what gives? What is mysqld doing?

Edit: I did recently kill an update statement that was taking a long time. Could this have anything to do with it?

It's probably good that you added that afterthought, because that's very likely what you're experiencing... the server is rolling back the work it had already done before you killed the large update.

If a big transaction is slowing down server performance, rolling it back can make the problem worse, potentially taking several times as long to perform as the original DML operations.

Even after a reboot? Yes...

Killing the database process does not help, because the rollback starts again on server startup.

http://dev.mysql.com/doc/refman/5.6/en/optimizing-innodb-transaction-management.html

InnoDB saved the data in the rows it was changing, and queries against that changes that are still being rolled back should be answered transparently using the data that's still in the undo log.

You'll probably also find the large amount of disk activity is associated with mysqld:

$sudo apt-get install iotop$ sudo iotop


There is a way to dispense with a runaway rollback, also explained at the link I've cited for the quotes, above... but your safest bet is to just let it churn for a while.