Centos – kblockd and kjournald high cpu

Four things come to mind when store.exe is seeing high usage.

1. Third-party applications on the Exchange server. It could be anti-virus (that's usually the case) that checks the mailbox database. Perhaps some form of special indexing or archiving tool. If you have non of those, move on.
2. The Exchange server itself has a virus. This happens sometimes. Sad, but true. To me, it seems that SBS machines are more prone to this, not because of anything about SBS itself, but more because of the culture surrounding the small deployment scenarious that SBS usually fits in.
3. The mailbox databases are experiencing some form of corruption that isn't enough to take the database offline completely. You need to research the "Information Store Integrity Checker (ISinteg)". If you have SP1 of Exchange 2010, ISinteg is no longer a standalone app, but has been turned into the followin two PowerShell / EMS cmdlets: New-MailboxRepairRequest and New-PublicFolderDatabaseRepairRequest
4. The Exchange server needs to be updated. I know, this one is kinda lame. However, plenty of update rollups, hotfixes and patches have been released that address spiking store.exe issues. Make double sure that you have all pertinent patches. Double check WSUS or whatever you use to manage patches. Make sure everything is approved and then wait to make sure that wuau.exe presents the updates to the SBS machine itself.

VERY IMPORTANT UPDATE:

Your server may have been hacked. It’s not redis that is causing the high CPU usage, but a separate command called yam (take a look at the far right of your htop, I missed it the first time). The yam command is used in a well-known exploit of redis and often results in high CPU usage. You’ll want to double-check to make sure your server is secure.

Here are some articles and links you can refer to if you want to learn more about the vulnerability and how to secure yourself:

• https://gist.github.com/lokielse/d4e62ae1bb2d5da50ec04aadccc6edf1 (a sample lady hack script, in the comments you can see where an original version downloaded yam)
• https://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.zkreading.com/article/879816.html&prev=search (a translation of a chinese article on the exploit and how to exploit it)
• https://translate.google.com/translate?hl=en&sl=zh-CN&u=http://blog.csdn.net/u012573259/article/details/51803447&prev=search (another chinese post more focused on next steps and clean up)
• http://antirez.com/news/96 an opinionated blog post on redis security describing the means of intrusion that may have been the source of ingress into the OP's server
• https://www.riskbasedsecurity.com/2016/07/redis-over-6000-installations-compromised/ (an overview of how many servers have been affected by poor redis security)
• https://news.ycombinator.com/item?id=13053647 (a thread reporting the bitcoin flavor of the hack)

Here is my checklist for magento/redis, er, performance issues:

1. Make sure you are on a newish version of redis, like 3.2, I personally prefer redis32u from the IUS repository if on CentOS.
2. Check the size of your redis database, it should be in /var/lib/redis, and make sure it is relatively small.
3. Verify that you have have enough ram for redis. You’ve specified a maxmemory of 15GB, which is really overkill for magento. I typically use something closer to 256mb. If you are using redis that much (!!!!!!), you likely have other problems in your magento stack.
4. Make sure you have vm overcommit setting set in syscntl. https://redis.io/topics/admin (see this link for more details on what you need)
5. Make sure you have sufficient open file limits to handle the number of connections to redis.

Generally speaking, the log file isn’t suspicious because your redis save settings tell redis to save every minute if there have been > 10000 write, every five minutes if there have been > 10 writes, and every 15 minutes if there have been > 1 write. So it is essentially persisting the info back to disk every minute, which shouldn’t be that burdensome.