DanM2

In an update to this situation, I ran a check and auto-repair on the database itself in case of any issues, where a few row counts were altered slightly.  Manual maintenance didn't seem to help much after, but it appears that I had success with the republish.php script which I saw referenced in another thread, used as follows:
 
php /home/xxxxxxx/live/scripts/maintenance/tools/republish.php hostname '2014-11-26 00:00:00' '2014-12-02 23:59:59'
 
For a period of time, yesterday's stats weren't coming up nor were today's save for what appears to have been an hour's worth.  But as I ran scripts one more time before posting, they all came as well.  This appears like it can be chalked up to a database table issue that likely occurred after the reboot.  I just wanted to update this with what happened in case anyone comes across this in the future, as well as bring the above script to light since save the post I came across randomly from a few years ago on a Google search, there doesn't appear to be any information on it outside of that post.

Thanks for the response!  It was certainly an oddity, and unfortunately I don't have any detailed server logs from before October to determine if the CPU usage was occurring as I described before moving it to a fresh AWS instance at that point.  I agree about the asynchronous tags causing a change to the performance level which made it noticeable, however it does seem like the irregular CPU usage was happening at a smaller scale prior.  In any case, I'm just glad that it's gone now, with the server seeming to operate closer to what I would expect (CPU system usage is a bit higher than other servers, but the CPU steal time is practically zero which was the big worry).  It could've just been that the usage we get needed a bit more power, we'll probably never know sadly.  Hopefully I'm the only one who has this weird issue, but if not, then maybe this can help someone in the future.  Thanks again!