我刚刚开始使用ami-fa01f193 AMI的大型实例。 当我使用ps aux时，一堆随机进程将显示CPU使用时间的巨大数字。 看起来像某种溢出。 有人看到这个之前，我该如何解决这个问题？
这是一个示例输出：
PID TTY STAT TIME COMMAND 1 ? Ss 0:00 /sbin/init 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [migration/0] 4 ? S 17179869:11 [ksoftirqd/0] 5 ? S 0:00 [watchdog/0] 6 ? S 17179869:11 [events/0] 7 ? S 0:00 [cpuset] 8 ? S 0:00 [khelper] 9 ? S 0:00 [netns] 10 ? S 0:00 [async/mgr] 11 ? S 0:00 [xenwatch] 12 ? S 0:00 [xenbus] 14 ? S 0:00 [migration/1] 15 ? S 17179869:11 [ksoftirqd/1] 16 ? S 0:00 [watchdog/1] 17 ? S 17179869:11 [events/1] 18 ? S 0:00 [sync_supers] 19 ? S 0:00 [bdi-default] TL / DR：在Amazon EC2 Nehalem实例上使用Ubuntu 10.04 LTS的已知问题
根据Librato的Silverline的Mike Heffner的说法：
在与其他科技公司对话期间，我们在某些Amazon EC2服务器上运行Ubuntu 10.04 LTS发行版时遇到了问题 – 与后端服务器的环境相同。 在Intel Xeon Series 55xx（Nehalem）CPU上运行的虚拟机pipe理程序上启动Ubuntu 10.04 LTS版本后，问题似乎就被触发了。 例如，一些Cassandra用户报告说，节点会长时间完全冻结。 我们发现，当我们启动一个E5507支持的实例时，我们只能看到后端系统CPUgraphics中的CPU高峰。
Mikebuild议采取以下解决方法，同时为Ubuntu 10.01提供内核修补程序：用户可以采取多种方法避免受到此影响：
更新到较新的Ubuntu发行版，例如Ubuntu 10.10。 自Ubuntu 10.04以来，Xen补丁更好地集成到内核中，避免将它们回传到2.6.32。 用户已经报告，Ubuntu 10.10镜像不会出现原始进程locking。
对于当前依赖于Ubuntu 10.04环境的环境（我们还有一些自己的环境）的用户，我们修改了我们的OPS脚本，以抛出使用Nehalem CPU启动并重新configuration的实例，直到获得E5430机器。 我们已经注意到，在一些AZ中，我们看到了更多的Nehalem，而不是其他的可能指向最近硬件部署的AZ的Nehalem。 显然这种方法在整体上是不可持续的，因为越来越多的用户在寻找旧的E5430处理器，而亚马逊进一步投资于Nehalem架构，所以我们正在积极地将我们的10.04系统迁移到10.10。
对于高级用户，构build一个包含bug报告中的补丁集的自定义2.6.32内核是一个选项。 这个bug报告中还有一些自定义的内核和AMI，用户已经报告成功了。
在Centos服务器上发生了类似的事情。 一个完整的，冷重启解决了这个问题。 当然，我不知道你会怎么去虚拟机上冷启动，但…
在刚刚重新启动的服务器上，为什么CPU运行时间很长？