Your htop graph shows PHP is using most of the cpu, check your web server access logs see if you're being crawled by a bot or something more malicious.

Hi,

Thank you for the reply. Since I am a newbie, I don't know much about it. Any command to see log file?

Look in your server logs (probably /var/log/nginx/access.log) and see if there are lots of POST requests to /xmlrpc. If so, try googling for solutions. I'm not a php or wordpress guy so just learning about this myself… a client linode running wordpress was getting hammered yesterday and CPU usage was really high all day.

@Ox-:

Look in your server logs (probably /var/log/nginx/access.log) and see if there are lots of POST requests to /xmlrpc. If so, try googling for solutions. I'm not a php or wordpress guy so just learning about this myself… a client linode running wordpress was getting hammered yesterday and CPU usage was really high all day.

THIS! I just had this happen the other week on a LAMP server that I had at another provider…CPU Usage was going nuts and was even higher then yours OP, turns out it was XMLRPC getting pounded, there's Wordpress plugins to disable it or you can disable access to it via nginx configuration/htaccess for apache.

I just had a similar problem to this today, and with research discovered that it indeed was due to a DOS xmlrpc attack. For now, I've added the following to the impacted site's .htaccess file, and it immediately fixed the problem, which was consuming all CPU resources even with all other traffic relatively low…

begin fix for xmlrpc exploits

Order allow,deny

Deny from all

end fix for xmlrpc exploits

I have found that the allow,deny doesn't work in all cases and have opted to use a rewrite rule to point XMLRPC POST calls to 0.0.0.0 - this has helped with my high IO rates and CPU Usage immensely with Wordpress sites being attacked.

RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

That would work if the OS was windows.

@derfy:

That would work if the OS was windows.

That is why the OP should check logs because it may be something similar but probably not identical.