我有一台定制的 Ubuntu 11.04 服务器，带有 6 磁盘软件 RAID 10 主驱动器。我主要在服务器上运行 PostgreSQL 和一些其他从网络传输数据的实用程序。我经常发现，在正常运行几个小时后，服务器开始因各种进程而滞后。例如，登录后可能需要 10-15 秒才能获得 shell 提示。可能需要 5-10 秒才能top启动。ls可能需要一两秒钟。
当我查看 top 时，几乎没有 CPU 使用率。PostgreSQL 服务器使用了相当多的内存，但不足以占用交换空间。
我不知道接下来该怎么办，除了怀疑 RAID10（我以前只用过软件 RAID 1）。
编辑：从顶部输出：
top - 11:56:03 up 1:46, 3 users, load average: 0.89, 0.73, 0.72
Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 93.5%id, 6.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16325596k total, 3478248k used, 12847348k free, 20880k buffers
Swap: 19534176k total, 0k used, 19534176k free, 3041992k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1747 woodsp 20 0 109m 10m 4888 S 1 0.1 0:42.70 python
357 root 20 0 0 0 0 S 0 0.0 0:00.40 jbd2/sda3-8
1 root 20 0 24324 2284 1344 S 0 0.0 0:00.84 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.24 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/0
8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
10 root 20 0 0 0 0 S 0 0.0 0:00.02 ksoftirqd/1
12 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/1
13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2
14 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/2:0
15 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2
16 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/2
17 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3
18 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/3:0
19 root 20 0 0 0 0 S 0 0.0 0:00.02 ksoftirqd/3
20 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/3
21 root 0 -20 0 0 0 S 0 0.0 0:00.00 cpuset
22 root 0 -20 0 0 0 S 0 0.0 0:00.00 khelper
23 root 20 0 0 0 0 S 0 0.0 0:00.00 kdevtmpfs
24 root 0 -20 0 0 0 S 0 0.0 0:00.00 netns
26 root 20 0 0 0 0 S 0 0.0 0:00.00 sync_supers
DF-H
rpsharp@ncp-skookum:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 1.8T 549G 1.2T 32% /
udev 7.8G 4.0K 7.8G 1% /dev
tmpfs 3.2G 492K 3.2G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 7.8G 0 7.8G 0% /run/shm
/dev/sda2 952M 128K 952M 1% /boot/efi
/dev/md0 5.5T 562G 4.7T 11% /usr/local
免费-m
psharp@ncp-skookum:~$ free -m
total used free shared buffers cached
Mem: 15942 3409 12533 0 20 2983
-/+ buffers/cache: 405 15537
Swap: 19076 0 19076
tail -50 /var/log/syslog
Jul 3 06:31:32 ncp-skookum rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="1070" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jul 3 06:39:01 ncp-skookum CRON[14211]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 06:40:01 ncp-skookum CRON[14223]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:00:01 ncp-skookum CRON[14328]: (woodsp) CMD (/home/woodsp/bin/mail_tweetupdate # email an update)
Jul 3 07:00:01 ncp-skookum CRON[14327]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:00:28 ncp-skookum sendmail[14356]: q63E0SoZ014356: from=woodsp, size=2328, class=0, nrcpts=2, msgid=<[email protected]>, relay=woodsp@localhost
Jul 3 07:00:29 ncp-skookum sm-mta[14357]: q63E0Si6014357: from=<[email protected]>, size=2569, class=0, nrcpts=2, msgid=<[email protected]>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Jul 3 07:00:29 ncp-skookum sendmail[14356]: q63E0SoZ014356: to=Spencer Wood <[email protected]>,Martin Lacayo <[email protected]>, ctladdr=woodsp (1004/1005), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=62328, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (q63E0Si6014357 Message accepted for delivery)
Jul 3 07:00:29 ncp-skookum sm-mta[14359]: STARTTLS=client, relay=mx3.stanford.edu., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 3 07:00:29 ncp-skookum sm-mta[14359]: q63E0Si6014357: to=<[email protected]>,<[email protected]>, ctladdr=<[email protected]> (1004/1005), delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=152569, relay=mx3.stanford.edu. [171.67.219.73], dsn=2.0.0, stat=Sent (Ok: queued as 8F3505802AC)
Jul 3 07:09:08 ncp-skookum CRON[14396]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 07:17:01 ncp-skookum CRON[14438]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 3 07:20:01 ncp-skookum CRON[14453]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:39:01 ncp-skookum CRON[14551]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 07:40:01 ncp-skookum CRON[14562]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:00:01 ncp-skookum CRON[14668]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:09:01 ncp-skookum CRON[14724]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 08:17:01 ncp-skookum CRON[14766]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 3 08:20:01 ncp-skookum CRON[14781]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:39:01 ncp-skookum CRON[14881]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 08:40:01 ncp-skookum CRON[14892]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
hdparm -t /dev/sd{a,b,c,d,e,f} 的输出 这看上去很可疑？
/dev/sda:
Timing buffered disk reads: 2 MB in 4.84 seconds = 423.39 kB/sec
/dev/sdb:
Timing buffered disk reads: 420 MB in 3.01 seconds = 139.74 MB/sec
/dev/sdc:
Timing buffered disk reads: 390 MB in 3.00 seconds = 129.87 MB/sec
/dev/sdd:
Timing buffered disk reads: 416 MB in 3.00 seconds = 138.51 MB/sec
/dev/sde:
Timing buffered disk reads: 422 MB in 3.00 seconds = 140.50 MB/sec
/dev/sdf:
Timing buffered disk reads: 416 MB in 3.01 seconds = 138.26 MB/sec
答案1
您实际上同时使用了将磁盘暴露给 Linux 内核的物理存储控制器（无论您是否使用其内置的 RAID 功能）和软件 RAID。您不能排除存储控制器支持不佳的可能性。使用 hdparm -t /dev/sd{a,b,c,d,e,f} 的输出来诊断问题（此命令需要一段时间）。
由于您发现 /dev/sda 速度过慢，我怀疑是磁盘故障或控制器故障。请仔细检查您的存储控制器是否得到良好支持，并尽快更换 /dev/sda。
答案2
我有个主意。正如你发布的 hdparm 的输出所示，它表示 SDA 驱动器非常慢。可能是因为：
a) 您的 / 和（部分） RAID 10 位于同一个磁盘上，或者...
b) 某些驱动程序有问题。
如果您升级了内核，请尝试使用 Ubuntu 自带的默认内核。
正如@Oneiroi 指出的那样，您应该尝试 iotop，并在后台运行程序。您可以在安装了 RAID 的地方单独运行 ls；然后在 / 和 RAID 上运行 ls。如果它变慢了，那么可能是原因 a。
尝试使用 grep 在 /var/log/dmesg、syslog 和消息中搜索诸如 hdd、kernel、raid 或 postgresql 之类的词。
另外，我会尝试让 sda 发生故障并从 RAID 中卸载。然后再次尝试 hdparm。如果成功，则问题出在 sda 磁盘上。
另一种可能的情况是问题出在 PostgreSQL 上。如果可能的话，你可以启动没有 PostgreSQL 的服务器，看看问题是否仍然存在。如果问题仍然存在，请关闭你可能拥有的任何其他服务。你也可以尝试关闭除 PostgreSQL 之外的所有服务。如果你能做到这一点，你可能知道问题是否是由
一）PostgreSQL
b) 其他服务
c) 处理大量数据
d) 系统本身。
根据您之前尝试过的方法，您可以指定您遇到的问题（a、b、c 或 d），并获得更好的帮助。
另外，如果@SilverbackNet 有机会，他可以告诉我们有关他的服务器的信息；这样我们现在就知道两个服务器之间的相似之处并有一个解决方案。
PD：抱歉，我的英语不好。请编辑并更正错误；肯定有很多。
PD2：我希望这会有所帮助，但这只是一些我认为可以提供帮助的理论：）
答案3
另外两种可能性：
记录过多，或者日志文件没有得到正确清理。如果日志文件变得非常大，则在常规操作期间加载/保存它们会花费时间。
网络连接或 SSH 问题。我在使用 Ubuntu 11 时也遇到过类似的问题，当我通过 SSH 进入机器时，即使过了很短的时间，SSH 连接似乎也会挂起或响应非常缓慢。但是，直接连接显示器似乎和以往一样快。使用 Ubuntu 12 服务器后，问题就消失了。
答案4
看起来你已经检查过一些显而易见的事情——这有点令人费解。
您没有在任何地方使用 LVM 吧？（我在这里没有看到任何像 LVM 设备的东西）快照会降低 LVM 的性能。
检查你的 irqbalance 是否正在运行，并合理地分配中断身体的核心（不是超线程核心）。
您使用的是哪个 io 调度程序？假设您没有具有大量内存的硬件 RAID 控制器，那么 deadline 可能是最明智的选择，但如果您目前已配置 deadline，请尝试 CFQ。
文件系统和挂载选项是什么？您如何配置磁盘（对于 ide/data，hdparm 告诉您什么 - 检查声学设置、DMA、预读和缓存）？