Since I see vmware-guestd running, I'll assume that this is a VM. Assuming ESX, go into the VIC and right-click the machine. Click Edit Settings...
and select the Resources
tab. Click Memory
and ensure that Unlimited
is check under Limit
.
What is likely happening is that you have a limit on the memory, and when the machine uses lots of memory (approaches or exceeds the limit), the vmware guest tools keep the memory "used" rather than releasing it back to ESX, in case it's needed again.
UPDATE:
"The server allows you to power on a virtual machine only if the CPU and memory reservation is
available... When resources are not used, the ESX Server host makes them available to other virtual machines."
http://www.vmware.com/pdf/vi3_esx_resource_mgmt.pdf
It does this by way of the "balloon" driver (vmmemctl) which is part of the guest tools. Say your machine is using 100MB of ram, then you run some program and it jumps up to 500MB used. Now you stop that program and expect the RAM to go back down to 100MB. However, it doesn't. This is because, in order for ESXi to reclaim the memory back from the guest OS (which it does even when there is a reservation) it must use the balloon driver. To make the OS "act" as though it has less memory, the balloon driver "uses" the memory that ESXi wants, so that the OS can't use it.
IOW, even with a reservation the guest is only using as much host RAM as it is using. When it uses more, ESX allocates more host RAM which the guest now thinks it always has available. To "convince" the guest that the new ram is gone again, the balloon driver uses it up. The reservation simply means "Don't start the VM unless the physical machine has 1GB free to load the guest into" and not "Give the guest 1GB whether it uses it or not."
Check out this article from the March issue of Linux Journal.
It explains many different ways of finding out what exactly is slowing down your system.
It shows you how to examine the CPU use, RAM/swap issues and I/O.
Best Answer
The 57.6% means that mysqld is using .576 of one cpu. The discrepancy is likely to be a race condition between data collection for the system as a whole and collecting the per-process data.
EDIT: Based on your update looks like you have 16 cores.
So that's where your 3% is coming from.
If you sum all the idle percentages and subtract from 1600%, that also comes out to about 57.5%.