![网站杀硬盘I/O,如何预防?](https://linux22.com/image/569712/%E7%BD%91%E7%AB%99%E6%9D%80%E7%A1%AC%E7%9B%98I%2FO%EF%BC%8C%E5%A6%82%E4%BD%95%E9%A2%84%E9%98%B2%EF%BC%9F.png)
情况:我有一台服务器,上面有 2-3 个项目。不久前,服务器开始挂断(我们无法通过 ssh 连接它,并且连接的客户端必须等待 20 分钟才能得到结果)
今天早些时候我成功执行了状态当它处于这种状态时,它就会停留在100%在 da0、da0s1 和 da0s1f 上。我不太清楚这些 ID 是什么意思,但我知道有些进程会通过向 HD 发送大量请求来将其关闭。
我请求大家提出一些建议。我不知道如何找到罪魁祸首,也无法阻止这种情况发生。
我的服务器上有 freebsd。
答案1
如果你的 FreeBSD 版本比较新,则top
可以-m
选择显示排名靠前的 I/O 使用者(如果你为其提供“ io
”参数):
top -m io
在这种情况下,我还会使用-S
选项(显示系统进程,以防其中一个是罪魁祸首)。为了在负载下表现更好,我会使用-q
(重新调整优先级以在更高优先级运行)和-u
(跳过阅读/etc/passwd
,这应该有助于它加载得更快)。
由于运行时间太长top
,我会告诉它只显示两次输出(-d 2
),然后以批处理模式运行(-b
),这样它就会自动退出。
第一次以这种方式运行top
,其输出的第一部分将显示一段时间以来(可能是从启动时开始?我对此不太确定)多个进程的累计 I/O 计数。在第一个显示中,您可以看到一段时间内使用量最大的进程是谁。在第二个显示中,您可以看到过去两秒内使用量最大的进程。
因此,将所有内容放在一起并运行,find
以便发生一些实际的 I/O:
# top -S -m io -qu -b -d 2 10
last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:29 11:28:28
125 processes: 2 running, 104 sleeping, 19 waiting
Mem: 96M Active, 668M Inact, 122M Wired, 25M Cache, 104M Buf, 17M Free
Swap: 2048M Total, 96K Used, 2048M Free
PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
11 0 0 81032823 0 0 0 0 0.00% idle: cpu0
39554 105 129857 556534 74894 0 0 74894 13.62% find
39533 105 443603 614796 0 0 0 0 0.00% sshd
36 0 1793393 0 0 0 0 0 0.00% irq23: vr0
24 0 2377710 2680 0 0 0 0 0.00% irq20: atapci0
50 0 533513 3415672 66 345350 0 345416 62.81% syncer
13 0 78651569 7230 0 0 0 0 0.00% swi4: clock sio
5 0 1911601 20905 0 0 0 0 0.00% g_down
4 0 2368511 12100 0 0 0 0 0.00% g_up
37 0 53308 313 0 0 0 0 0.00% acpi_thermal
last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:31 11:28:30
125 processes: 2 running, 104 sleeping, 19 waiting
CPU: 1.9% user, 0.0% nice, 6.0% system, 2.2% interrupt, 89.9% idle
Mem: 96M Active, 671M Inact, 123M Wired, 25M Cache, 104M Buf, 14M Free
Swap: 2048M Total, 96K Used, 2048M Free
PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
11 0 0 1115 0 0 0 0 0.00% idle: cpu0
39554 105 606 651 501 0 0 501 100.00% find
39533 105 616 695 0 0 0 0 0.00% sshd
36 0 1251 0 0 0 0 0 0.00% irq23: vr0
24 0 501 20 0 0 0 0 0.00% irq20: atapci0
50 0 2 2 0 0 0 0 0.00% syncer
13 0 313 3 0 0 0 0 0.00% swi4: clock sio
5 0 501 26 0 0 0 0 0.00% g_down
4 0 501 8 0 0 0 0 0.00% g_up
37 0 0 0 0 0 0 0 0.00% acpi_thermal
一旦您缩小了执行所有 I/O 的进程的范围,您就可以使用truss
或devel/strace
或sysutils/lsof
端口来查看占用大量磁盘空间的进程正在做什么。(当然,如果您的系统非常繁忙,您将无法轻松安装端口):
例如,查看我的ntpd
进程正在使用哪些文件和其他资源:
# lsof -p 890
ntpd 890 root cwd VDIR 0,93 1024 2 /
ntpd 890 root rtd VDIR 0,93 1024 2 /
ntpd 890 root txt VREG 0,98 340940 894988 /usr/sbin/ntpd
ntpd 890 root txt VREG 0,93 189184 37058 /libexec/ld-elf.so.1
ntpd 890 root txt VREG 0,93 92788 25126 /lib/libm.so.5
ntpd 890 root txt VREG 0,93 60060 25130 /lib/libmd.so.4
ntpd 890 root txt VREG 0,98 16604 730227 /usr/lib/librt.so.1
ntpd 890 root txt VREG 0,93 1423460 25098 /lib/libcrypto.so.5
ntpd 890 root txt VREG 0,93 1068216 24811 /lib/libc.so.7
ntpd 890 root 0u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 1u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 2u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 3u unix 0xc46da680 0t0 ->0xc4595820
ntpd 890 root 5u PIPE 0xc4465244 0 ->0xc446518c
ntpd 890 root 20u IPv4 0xc4599190 0t0 UDP *:ntp
ntpd 890 root 21u IPv6 0xc4599180 0t0 UDP *:ntp
ntpd 890 root 22u IPv4 0xc4599400 0t0 UDP heffalump.prv.tycho.org:ntp
ntpd 890 root 23u IPv4 0xc4599220 0t0 UDP ns0.prv.tycho.org:ntp
ntpd 890 root 24u IPv4 0xc45995c0 0t0 UDP imap.prv.tycho.org:ntp
ntpd 890 root 25u IPv6 0xc4599530 0t0 UDP [fe80:4::1]:ntp
ntpd 890 root 26u IPv6 0xc45993b0 0t0 UDP localhost:ntp
ntpd 890 root 27u IPv4 0xc4599160 0t0 UDP localhost:ntp
ntpd 890 root 28u rte 0xc42939b0 0t0
...以及它正在进行的系统调用(请注意,这可能会耗费大量资源):
# truss -p 890
SIGNAL 17 (SIGSTOP)
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
^C
sysutils/strace
与类似truss
,但您需要/proc
挂载文件系统:
# strace -p 890
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file
# grep ^proc /etc/fstab
proc /proc procfs rw,noauto 0 0
# mount /proc
# mount | grep /proc
procfs on /proc (procfs, local)
...然后它就会起作用:
# strace -p 890
Process 890 attached - interrupt to quit
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10) = -1 (errno 4)
select(29, [?], NULL, NULL, NULL) = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10) = -1 (errno 4)
select(29, [?], NULL, NULL, NULL^C <unfinished ...>
Process 890 detached
祝你好运 - 让我们知道你发现了什么!一旦你确定了流程,我可能会提供进一步的帮助。
编辑:请注意,运行lsof
、truss
和strace
本身可能非常耗时。我做了一些小更新,试图减少它们的影响。此外,如果某个进程正在快速产生许多子进程,您可能必须使用参数告诉truss
或strace
跟踪子进程-f
。
答案2
过了一段时间我发现真正的问题。正如我在上一条评论中所说,这是一个记忆力不足的问题。
罪魁祸首是ZODB 的 ZEO 服务器。它非常依赖系统磁盘 IO 缓存,当可用内存不足时,它就会适得其反500 MB它开始减速,300 MB它占用了太多的磁盘空间,导致系统停止响应,甚至一些服务也开始崩溃(比如sshd)。
改变缓存结构并释放2 GB可用内存,问题已解决。