这是一个示例输出：
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]
解决方法
根据Mike Heffner(Librato的Silverline)：
During conversations with other tech
companies we learned of an issue when
running the Ubuntu 10.04 LTS release
on certain Amazon EC2 servers — the
same environment as our backend
servers. The issue appeared to be
triggered when launching the Ubuntu
10.04 LTS release on hypervisors running on Intel Xeon Series 55xx
(Nehalem) cpus. For example,some
Cassandra users were reporting that
nodes would completely freeze up for
extended periods of time. We
identified that we only saw the large
cpu spikes in our backend system cpu
graphs when we had launched an E5507
backed instance.
对于Ubuntu 10.01的内核补丁,Mike建议采用以下解决方法：
用户可以采取多种方法来避免受此影响：
>更新到更新的Ubuntu版本,
例如,Ubuntu 10.10.以来
Ubuntu 10.04,Xen补丁是
更好地集成到内核中
避免要求后退
他们到2.6.32.用户已报道
原始进程锁定
不要与Ubuntu 10.10一起出现
图片.
>适用于有环境的用户
目前依赖于Ubuntu
10.04环境(我们还有一些自己)我们修改了我们的
OPS脚本抛出实例
用Nehalem cpu启动
重新配置,直到我们得到E5430
机.我们注意到了
一些亚利桑那州我们看到更多的Nehalem比
在其他可能指向AZ的人
使用更新的硬件
部署.显然这种方法
整体上是不可持续的
更多用户寻找旧款E5430
cpu和亚马逊进一步投资
Nehalem建筑,我们是
积极努力迁移我们的
10.04系统到10.10.
>对于高级用户,构建自定义2.6.32
包含补丁集的内核
从bug report是一个选项.还有一些自定义内核和错误的AMI报告用户报告成功.
