EC2 Amazon Linux AMI MySQL CPU @ 62% When Idle?

问题:

I am running MySQL on an Amazon Linux AMI. There is nothing connected to it. There are no connections and no other applications running that use MySQL. It is completely idle, but yet, top is reporting that mysql is using 62% of the CPU? Why is this happening and how do I fix it?

Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 97.8%id,  0.0%wa,  0.0%hi,  0.0%si,  1.7%st
Mem:   1738504k total,   390708k used,  1347796k free,    56888k buffers
Swap:   917500k total,        0k used,   917500k free,   229804k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2959 mysql     20   0  466m  39m 5244 S 62.2  2.3   4:00.67 mysqld
    1 root      20   0 19252 1504 1212 S  0.0  0.1   0:00.20 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd

There are no connections...

mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
|  5 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+

UPDATE: My issue was definitely related to the Lead Second bug. Kudos to nico-ekito. Thanks!

回答1:

The only thing I can think of is to inspect what mysqld is really doing using strace, as user root:

 strace -p 2959

Normally, strace should block immediately and show you a call to select(), because mysqld should be waiting for connections.

The call should be something like:

 select(SOCKETNO, [OTHER_FDs], NULL, NULL, NULL)

especially important is the fourth parameter, which is a timeout timeval. If NULL, it means that mysqld will sleep until someone connects. If not NULL, it means that mysqld will wait for the specified time and then do some maintenance work. A very small timeval might explain the CPU consumption.

I believe that MySQL always employs a NULL (infinite) timeout. It makes sense and this is how the mysqlds I'm able to reach now are behaving.

However, there might be some connection handling issues that prevent select from sleeping again. Check whether this behaviour appears as soon as mysqld starts, or after someone connects.

回答2:

Closing out this question. My issue was indeed related to the Leap Second fiasco.