简要说明：
我最近开始尝试在我们的数据中心设置/管理 Linux（Ubuntu 10.04.2 LTS）服务器（所有其他服务器都是 Windows 机器）。服务器会定期挂起并变得无响应，我在任何日志中都找不到任何表明具体原因的信息。有时它会挂起几个小时，有时几天（最长 14 天）。挂起后将显示器插入机器，什么也没有显示。为了解决问题，我们尝试禁用 APIC，这更多是出于“有根据的绝望”，而不是其他原因。不幸的是，我们能做的一些故障排除工作有限，因为我们在机器上托管了一个客户端网站（我们设置它的原因），因此任何涉及大量停机的事情都是问题。
由于这是我们首次尝试设置 Linux 机器，因此我们使用“装备精良”的台式机，而不是我所说的“服务器级”硬件。这是一个独立的机器，而不是 VPS。我们使用硬件（而不是软件）RAID 阵列，并且机器中有足够的内存。
注意事项/背景：
- 总体来说，我对 Linux 还比较陌生。
- 我花在编写代码上的时间比管理服务器上的时间多得多。我习惯于在机器上工作，但我并不是一个真正的系统管理员。
- 我对命令行很熟悉，但对 OS X（BSD）有更多经验。
- 尽管我尽力彻底检查我所知道的内容，但我不确定可能可用的所有工具/信息/日志。
- 我没有物理配置硬件，所以我不确定所有的规格，但我可以获得排除故障所需的任何信息。
- 我可能会在不知情的情况下跳过非常基本的步骤或错过了寻找信息的明显的地方。
更详细一点：
- 实际内存：8GB
- Ubuntu 10.04.2 LTS
- 硬件 RAID 10
- 使用 Webmin 1.550 版管理网站
- 服务器位于远程数据中心。手动排除故障很困难。
到目前为止，我们尝试了两次 Linux 设置。第一次是在与此相同的硬件配置上进行的，但没有重复使用任何硬件。那次尝试使用的是 CentOS，我们试图设置 CPanel。由于同样的问题（周期性崩溃/挂起），我们放弃了那次安装。
第二次尝试（这次）也出现了同样的情况。我唯一能看到的共同点是硬件配置（尽管 CentOS 和 Ubuntu 的共同点可能比我想象的要多）。
该盒子可以正常运行数小时、数天甚至数周，然后就完全停止响应。我检查了我知道要检查的所有日志（主要是消息、系统日志和 kern.log），但我没有看到任何对我来说似乎是错误的东西。我确实看到了一些我不理解的行，它们可能是也可能不是问题，例如：
rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="814" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
我们的大多数系统日志条目似乎都是正在运行的与 webmin 相关的 cron 作业的日志。我的直觉告诉我，我们的配置中可能有一些 Linux 不喜欢的组件或需要更新驱动程序（例如 raid 卡），但我不确定如何做更多来追踪或确定可能是什么。猜测和检查的成本很高。
我的另一个想法是，正在运行的一个或多个 cron 作业出了问题，但这种情况似乎无法按需重现，而且，我不知道如何进一步验证这一理论。每次服务器宕机时，似乎都不会运行相同的 cron 作业。
这是我们最后一次挂起之前日志的一部分：
Aug 8 11:00:01 linhost01 CRON[10771]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null)
Aug 8 11:00:01 linhost01 CRON[10772]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:01:01 linhost01 CRON[10799]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
Aug 8 11:05:01 linhost01 CRON[10898]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:06:01 linhost01 CRON[10924]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
Aug 8 11:09:01 linhost01 CRON[11007]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Aug 8 11:10:01 linhost01 CRON[11023]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null)
Aug 8 11:10:01 linhost01 CRON[11024]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:11:01 linhost01 CRON[11063]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
Aug 8 11:15:01 linhost01 CRON[11149]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:16:01 linhost01 CRON[11176]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
Aug 8 11:17:01 linhost01 CRON[11243]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 8 11:20:01 linhost01 CRON[11279]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null)
Aug 8 11:20:01 linhost01 CRON[11280]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:21:01 linhost01 CRON[11307]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
Aug 8 11:25:01 linhost01 CRON[11392]: (root) CMD (/etc/webmin/status/monitor.pl)
Aug 8 11:26:01 linhost01 CRON[11432]: (root) CMD (/etc/webmin/virtual-server/collectinfo.pl)
[SERVER DOWN AFTER THIS POINT]
如果有人能帮我阐明任何道理，或者给我提供任何可能有用的信息，我将不胜感激。我完全赞成边做边学，但在这方面我已经筋疲力尽了。
很高兴发布任何可能有助于提供建议的具体日志信息或信息。
答案1
为了完整起见，我想我应该就此打住。经过一年多的这种行为，服务器终于死机了。只有在尝试（并失败）重建 RAID 时，我们才发现不是一块硬盘坏了，而是两块硬盘坏了。
该服务器问题的确切原因仍然未知，但（由于我对 Linux 的了解仍然有限）我怀疑这两个驱动器出现问题已有一段时间，而尝试使用损坏的驱动器会间歇性地导致服务器崩溃/重启。
我们的最终解决方案是使用几乎完全相同的配置但使用全新的硬件从头开始重建服务器。我们所做的唯一重大配置更改是使用 ext4 而不是 xfs 作为文件系统。该机器已经运行了几个月，没有出现任何问题。
我之所以回答这个问题，是因为对我们来说，驱动器故障似乎是原因，更换所有硬件是解决问题的最佳方法。话虽如此，我不知道这个答案对大多数人来说是否太有帮助。
答案2
我本想将此作为评论发布，但我缺乏声誉。
话虽如此，但从随意查看日志中唯一能脱颖而出的就是 nouveau。如果是我，我会禁用 nouveau。这些说明应该可以带你到那里。
您可能还会发现以下 severfault 帖子很相关，而且可能很有帮助，即使只是为了向您展示一些可用于帮助排除故障的工具。
Ubuntu 10.10 Maverick Server 系统会随机锁定（i7 930；12GB RAM）
祝你好运！
答案3
目前还不清楚宕机的具体含义。我知道您提到了远程控制，因此动手操作比较困难。但是，对于此类崩溃，了解机器是否完全冻结至关重要。当机器崩溃时，控制台是否还能工作（我说的“工作”是指您能否按 Enter 键，是否显示密码提示，您是否能登录）？对于数据中心的机器，将某种控制台放入其中确实是一个好主意。以下是便宜的选择：
http://international.opengear.com/SD4001_Single_Port_Advanced_Device_Server_p/sd4001.htm
这需要一些设置来配置串行控制台部分。更简单但更昂贵的解决方案是 KVM。一旦您确定物理控制台在这些中断期间是否冻结，它应该有助于确定后续步骤。如果物理控制台也冻结，则很可能是您的硬件存在问题。如果盒子还没有 ECC 内存，您应该考虑测试或更换它。如果问题只是 RAID 卡等子系统的驱动程序错误，控制台不太可能锁定。如果控制台在这些中断期间确实有响应并且您可以登录，您应该尝试运行一些命令。如果问题相当频繁，您可能只想设置一个 cron 作业来每分钟捕获这些输出：
lsof -n # 将列出系统上所有打开的 FD，希望显示是否有东西正在使用所有资源
netstat -an ; netstat -s # 任何由网络引起的问题都应显示在这里，例如缓冲区不足
ps -eaf # 一般进程堆积？
为输出添加日期标记，然后尝试找到崩溃前的最后一个输出。如果是子系统的问题，从此处的输出中可以看出。