☰

亚马逊 EC2 下的 Ubuntu 上奇怪的进程 CPU 时间输出

tag-icon • tag-icon linux ubuntu amazon-ec2 ps
亚马逊 EC2 下的 Ubuntu 上奇怪的进程 CPU 时间输出

我刚刚使用 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]

答案1

TL/DR：Ubuntu 10.04 LTS 在 Amazon EC2 Nehalem 实例上的已知问题

根据麦克·赫夫纳（Librato 的 Silverline）：

在与其他技术公司的交流中，我们了解到在某些 Amazon EC2 服务器（与我们的后端服务器相同的环境）上运行 Ubuntu 10.04 LTS 版本时会出现问题。在运行 Intel Xeon Series 55xx (Nehalem) CPU 的虚拟机管理程序上启动 Ubuntu 10.04 LTS 版本时似乎会触发此问题。例如，一些 Cassandra 用户报告说节点会在较长时间内完全冻结。我们发现，只有在启动 E5507 支持的实例时，我们才会在后端系统 CPU 图表中看到较大的 CPU 峰值。

Mike 建议在为 Ubuntu 10.01 安装内核补丁时采用以下解决方法：用户可以采取多种方法来避免受到此影响：

  1. 更新到较新的 Ubuntu 版本，例如 Ubuntu 10.10。自 Ubuntu 10.04 以来，Xen 补丁已更好地集成到内核中，无需将其反向移植到 2.6.32。用户报告称，Ubuntu 10.10 映像不会发生原始进程锁定。

  2. 对于目前环境依赖于 Ubuntu 10.04 环境的用户（我们自己也有一些），我们修改了 OPS 脚本，以丢弃使用 Nehalem CPU 启动的实例并重新配置，直到我们获得 E5430 机器。我们注意到，在某些可用区中，我们看到的 Nehalem 比其他可用区多，这可能表明可用区具有较新的硬件部署。显然，这种方法在整体上是不可持续的，因为越来越多的用户寻求较旧的 E5430 CPU，而亚马逊进一步投资于 Nehalem 架构，因此我们正在积极努力将我们的 10.04 系统迁移到 10.10。

  3. 对于高级用户，构建一个包含来自错误报告是一个选项。此错误报告中还包含一些自定义内核和 AMI，用户报告称这些内核和 AMI 成功了。

答案2

我在 Centos 服务器上也遇到过类似的事情。完全冷重启解决了这个问题。当然，我不知道你会如何在虚拟机上进行冷重启……

在刚刚重启的服务器上，为什么进程的 CPU 运行时间会很长？

相关内容