IO负载探讨

接下来，再说说IO出现瓶颈时故障，这里分析原理对CPU，内存有类似情况，

肯定是系统运行比较慢，这时来查IO使用情况，首先讲一下命令

linux # iostat -x -k -d 1

Linux 2.6.16.60-0.21-smp (linux)06/13/12

 

……

Device:rrqm/swrqm/sr/sw/srkB/swkB/s avgrq-sz avgqu-szawaitsvctm%util

sda0.009915.001.0090.004.0034360.00755.2511.79120.576.3357.60

以上各列的含义如下：

·rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并

·wrqm/s: 每秒对该设备的写请求被合并次数

·r/s: 每秒完成的读次数

·w/s: 每秒完成的写次数

·rkB/s: 每秒读数据量(kB为单位)

·wkB/s: 每秒写数据量(kB为单位)

·avgrq-sz:平均每次IO操作的数据量(扇区数为单位)

·avgqu-sz: 平均等待处理的IO请求队列长度

·await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)

·svctm: 平均每次IO请求的处理时间(毫秒为单位)

·%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率

·

参数	英文说明	说明
rrqm/s	read request merge	每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s	write request merge	每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s	read	每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s	write	每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s	read section	每秒读扇区数。即  delta(rsect)/s
wsec/s	write section	每秒写扇区数。即  delta(wsect)/s
rkB/s	read kilo byte	每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s	write kilo byte	每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz	average request size	平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz	average queue size	平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)
await	average wait	平均每次设备I/O操作的等待时间 (毫秒)。即  delta(ruse+wuse)/delta(rio+wio)
		await：每一个IO请求的处理的平均时间（单位是毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。
svctm	service time	%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。
			%util	utilty	一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

·如果%util接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈，idle小于70% IO压力就较大了,一般读取速度有较多的wait。同时可以结合vmstat（virtual memory status）查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

·另外还可以参考svctm，由于它一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

对于发出硬盘瓶颈，分两步走，

1 频繁访问的文件系统和裸设备尽可能放置在不同的磁盘上. 

2 在建立逻辑卷时尽可能使用mklv的命令开关给不同的文件系统和裸设备赋予不同的内策略.

3 使用磁盘设备驱动器的功能属性构建合适的RAID方式, 以获得更高的数据安全性和存取性能. 一般考虑采用RAID5或者RAID10的方式, 对于写要求比较高的系统, 一般建议采用RAID10方式.

4 尽可能利用内存读写带宽远比直接磁盘IO操作性能优越的特点, 使频繁访问的文件或数据置于内存中进行操作处理

二找到占用磁盘的文件最大的进程，找出来进行分析优化。

这是主要AIX下

公司的一个生产应用发生异常，无法正常运行。当时应用系统异常后，登录主机发现/tmp文件系统写满了，删除了一些不用的文件后，应用正常，但df -k 查看后发现 /tmp 剩余空间仍然在不断增长，而且速度很快。看来没有找到问题的实质。最后应用开发人员的协助下，发现是一个应用进程在不断的向 /tmp 中写一个临时文件，这个临时文件不断增大，最终将 /tmp 撑爆了。总结了如下：

1. 先看看 /tmp 下哪些文件大小不正常呢？
  find /tmp -size +100000000c -ls (查看/tmp下大于100M的文件)
2. 那么是哪个文件在频繁的写入呢？
  filemon -o filemon.out -O all; sleep 30; trcstop (使用filemon查看文件系统的IO)。
分析生成的filemon.out文件可以判断是哪个文件的IO最大。
3. 那么是谁,又是哪个进程在写这个文件呢？
  fuser -u filename (查看filename是被谁的什么进程（pid）使用)

找到了文件和进程，kill掉进程，删除文件就可以解决问题了。

有的时候在没有kill进程的情况下，删除了文件，这是空间是不会释放的，使用
fuser -d /tmp 
可以看到那个仍然在写已删除文件的进程。kill掉进程，空间释放。

Linux下

最近测试一项目，性能非常不理想。老版本逻辑和功能都简单时，性能是相当的好！接口点击率是万级的。谁知修改后上不了百。

架设Jboss服务器，业务逻辑用Java处理，核心模块使用C++处理，使用JNI衔接。

本应用对CPU和硬盘第三非常敏感，因为有压缩解压和大量数据交互。起初作压力测试时，发现服务器各资源使用都有剩余，而点击率曲线波动却非常大，简单看似乎是应用程序有问题。

使用top查看Cpu各核的使用情况，发现一个非常诡异的现象：

         1. 经常只有部分核是满载的，另外一部分基本空闲；

         2. 在CPU满载时，%wa 的波动比较大，有时会占到较大比例。

所以，监控整个CPU时会发现CPU使用率不高，实际上任务总是分派到某个核上且导致对应核满载。无法有效使用CPU，其它资源自然也难以有效调度。

废话不多说，%wa指CPU等待磁盘写入完成的时间。莫非是磁盘忙，怎样证明是磁盘在忙？

首先看下%wa的解释：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

起初用`lsof | less`查看文件的读写情况，发现/tmp目录下有大量文件读写。经查证，是Jboss处理上传文件会默认写入到/tmp文件夹，然后再执行了一次拷贝到程序读取的目录。修改Jboss配置直接写入到程序读写目录，性能没有本质上的改变。

关于CPU使用波动大，我们也在程序内部加了很多计时器，发现某些模块在处理并发时会有响应时间很长的情况，这点证实了为什么点击率波动很大。

但此模块进行单进程串行测试时，每秒完成事务数是相当可观的。一个进程每秒完成的事务数都比当前测试点击率要高很多！使用多进程来测试此模块时，发现“进程数=核数”时效果最佳。于是在Java层控制同时进入此模块的数量，毕竟Java是调用JNI来使用此模块，使用全局锁来控制并发，最终结果没有想象的那么理想，但明显可以看出：通过控制并发数，能有效提高CPU的使用率，点击率也上升了一些。

另外一个问题就是，CPU会出现一会满载，一会空闲的情况，导致点击率曲线仍然波动大的问题。商讨后决定在C++代码中加入“释放CPU控制权”的逻辑，这样就在代码层来作了一个负载均衡。点击率波动的问题得到了好转，但点击率仍然不理想，预期瓶颈是网络而实际变成了CPU。

优化了压缩解决的处理后，性能没有明显提升。这时我才想起%wa，我还没有进一步证明是磁盘的闲忙程度。使用了一些监控工具，诸如：vmstat、sar、dstat、sysstat没有发现对磁盘作非常详细的监控。最后试了下iostat，搞定！

    iostat的编译非常简单，就一个c文件，MakeFile里作者写了一句话“Cann't be simpler”。直接make install就在目录下生成了iostat的可执行文件，看一下帮助，执行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盘的闲忙程序，简单直接。另外还有详细的磁盘IO读写数据，帮助里也解释得非常清楚。

再进行一次压力测试，拿着这份数据，已经绝对性的说明问题了。此时那些大牛把代码改了一下，性能立马就上去了，千兆网络直接成为系统瓶颈。并于Java的控制问题，改用Apache直接编译程序模块调用，完成变为可控，问题瞬间解决！

实例分析

$$iostat -d -k 1 |grep sda10

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

sda1060.7218.9571.53395637647 1493241908

sda10299.024266.67129.414352132

sda10483.844589.904117.1745444076

sda10218.003360.00100.003360100

sda10546.008784.00124.008784124

sda10827.0013232.00136.0013232136

上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。

iostat -d -x -k 1

Device:rrqm/s wrqm/sr/sw/srsec/swsec/srkB/swkB/s avgrq-sz avgqu-szawaitsvctm%util

sda1.5628.317.84 31.5043.653.1621.821.581.190.030.802.6110.29

sda1.9824.75 419.806.93 13465.35253.476732.67126.7332.152.004.702.0085.25

sda3.0641.84 444.90 54.08 14204.08 2048.987102.041024.4932.572.104.211.8592.24

可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。

最近一台linux服务器出现异常，系统反映很慢，相应的应用程序也无法反映，而且还出现死机的情况，经过几天的观察了解，发现服务器压力很大，主要的压力来自硬盘的IO访问已经达到100%

　　为了方便各位和自己今后遇到此类问题能尽快解决，我这里将查看linux服务器硬盘IO访问负荷的方法同大家一起分享：

　　首先 、用top命令查看

　　top - 16:15:05 up 6 days,  6:25,  2 users,  load average: 1.45, 1.77, 2.14

　　Tasks: 147 total,   1 running, 146 sleeping,   0 stopped,   0 zombie

　　Cpu(s):  0.2% us,  0.2% sy,  0.0% ni, 86.9% id, 12.6% wa,  0.0% hi,  0.0% si

　　Mem:   4037872k total,  4003648k used,    34224k free,     5512k buffers

　　Swap:  7164948k total,   629192k used,  6535756k free,  3511184k cached

　　查看12.6% wa

　　IO等待所占用的CPU时间的百分比,高过30%时IO压力高

　　其次、 用iostat -x 1 10

　　如果 iostat 没有，要  yum install sysstat

　　avg-cpu:  %user   %nice    %sys %iowait   %idle

　　0.00       0.00     0.25    33.46    66.29

　　Device:    rrqm/s  wrqm/s   r/s    w/s     rsec/s   wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util

　　sda          0.00    0.00      0.00   0.00    0.00    0.00         0.00     0.00     0.00           0.00    0.00    0.00   0.00

　　sdb          0.00   1122  17.00  9.00  192.00 9216.00    96.00  4608.00   123.79   137.23 1033.43  13.17 100.10

　　sdc          0.00    0.00     0.00   0.00     0.00     0.00      0.00     0.00     0.00             0.00    0.00      0.00   0.00

　　查看%util 100.10 %idle 66.29

　　如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

　　idle小于70% IO压力就较大了,一般读取速度有较多的wait.

　　同时可以结合vmstat 查看查看b参数(等待资源的进程数)

　　vmstat -1

　　如果你想对硬盘做一个IO负荷的压力测试可以用如下命令

　　time dd if=/dev/zero bs=1M count=2048 of=direct_2G

　　此命令为在当前目录下新建一个2G的文件

　　我们在新建文件夹的同时来测试IO的负荷情况

　　再通过如下脚本查看高峰的进程io情况

　　monitor_io_stats.sh

　　#!/bin/sh

　　/etc/init.d/syslog stop

　　echo 1 > /proc/sys/vm/block_dump

　　sleep 60

　　dmesg | awk '/(READ|WRITE|dirtied)/ {process[$1]++} END {for (x in process) \

　　print process[x],x}' |sort -nr |awk '{print $2 " " $1}' | \

　　head -n 10

　　echo 0 > /proc/sys/vm/block_dump

　　/etc/init.d/syslog start

　　或者用iodump.pl脚本

 

 

关于Linux系统指令 top 之 %wa 占用高，用`iostat`探个究竟 

最近测试一项目，性能非常不理想。老版本逻辑和功能都简单时，性能是相当的好！接口点击率是万级的。谁知修改后上不了百。

    架设Jboss服务器，业务逻辑用Java处理，核心模块使用C++处理，使用JNI衔接。

    本应用对CPU和硬盘第三非常敏感，因为有压缩解压和大量数据交互。起初作压力测试时，发现服务器各资源使用都有剩余，而点击率曲线波动却非常大，简单看似乎是应用程序有问题。

    使用top查看Cpu各核的使用情况，发现一个非常诡异的现象：

         1. 经常只有部分核是满载的，另外一部分基本空闲；

         2. 在CPU满载时，%wa 的波动比较大，有时会占到较大比例。

    所以，监控整个CPU时会发现CPU使用率不高，实际上任务总是分派到某个核上且导致对应核满载。无法有效使用CPU，其它资源自然也难以有效调度。

    废话不多说，%wa指CPU等待磁盘写入完成的时间。莫非是磁盘忙，怎样证明是磁盘在忙？

   首先看下%wa的解释：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

    起初用`lsof | less`查看文件的读写情况，发现/tmp目录下有大量文件读写。经查证，是Jboss处理上传文件会默认写入到/tmp文件夹，然后再执行了一次拷贝到程序读取的目录。修改Jboss配置直接写入到程序读写目录，性能没有本质上的改变。

    关于CPU使用波动大，我们也在程序内部加了很多计时器，发现某些模块在处理并发时会有响应时间很长的情况，这点证实了为什么点击率波动很大。

    但此模块进行单进程串行测试时，每秒完成事务数是相当可观的。一个进程每秒完成的事务数都比当前测试点击率要高很多！使用多进程来测试此模块时，发现“进程数=核数”时效果最佳。于是在Java层控制同时进入此模块的数量，毕竟Java是调用JNI来使用此模块，使用全局锁来控制并发，最终结果没有想象的那么理想，但明显可以看出：通过控制并发数，能有效提高CPU的使用率，点击率也上升了一些。

    另外一个问题就是，CPU会出现一会满载，一会空闲的情况，导致点击率曲线仍然波动大的问题。商讨后决定在C++代码中加入“释放CPU控制权”的逻辑，这样就在代码层来作了一个负载均衡。点击率波动的问题得到了好转，但点击率仍然不理想，预期瓶颈是网络而实际变成了CPU。

    优化了压缩解决的处理后，性能没有明显提升。这时我才想起%wa，我还没有进一步证明是磁盘的闲忙程度。使用了一些监控工具，诸如：vmstat、sar、dstat、sysstat没有发现对磁盘作非常详细的监控。最后试了下iostat，搞定！

    iostat的编译非常简单，就一个c文件，MakeFile里作者写了一句话“Cann't be simpler”。直接make install就在目录下生成了iostat的可执行文件，看一下帮助，执行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盘的闲忙程序，简单直接。另外还有详细的磁盘IO读写数据，帮助里也解释得非常清楚。

   再进行一次压力测试，拿着这份数据，已经绝对性的说明问题了。此时那些大牛把代码改了一下，性能立马就上去了，千兆网络直接成为系统瓶颈。并于Java的控制问题，改用Apache直接编译程序模块调用，完成变为可控，问题瞬间解

 

 

 

踪大型分布式系统的性能问题，从本质上来讲是复杂的。应用为什么慢？瓶颈在哪里？以我的经验，最主要的罪魁祸首之一是高IO等待（即high IO wait）。换一个地方用Dr. Seuss的话来说：每个人都只是在等待[翻译参考文献1]。

高IO等待问题的第一个征兆通常是系统平均负载。负载均衡的计算都是基于CPU利用率的，即使用或等待CPU的进程数目，当然，在Linux平台上，进程几乎都处于不可中断的睡眠状态。负载均衡的基线可以解释为，在一个CPU核的机器上上，该CPU得到充分利用。因此，对于4核机器中，如果系统平均复杂为4，表示该机器有足够的资源来处理它需要做的工作，当然只是勉强。在相同的4核系统，如果平均复杂是8，那么以为这将意味着服务器系统需要8个core才能处理所要做的工作，但现在只有4个核，所以已经超载。

如果系统显示平均负载较高，但是CPU的系统(system)和用户(user)利用率较低，那么就需要观察IO 等待(即IO wait)。在linuc系统上，IO wait对系统负载有较大的影响，主要因为一个或多个核都可能被磁盘IO或网络IO所阻塞，只有当磁盘IO或网络IO完成后，这些核上的任务(即进程)才能进行下去。而这些进程使用ps aux来查看均处于”D”状态，即不可中断的睡眠状态。

发现进程在等待IO完成是一回事，验证高IO wait的原因是另一回事。使用”iostat –x 1”能够显示正在使用的物理存储设备的IO情况：

[username@server~]$ iostat -x 1

Device:        rrqm/s  wrqm/s  r/s  w/s  rsec/s  wsec/s avgrq-sz avgqu-sz  await  svctm  %util

cciss/c0d0        0.08    5.94  1.28  2.75    17.34    69.52    21.60    0.11  26.82  4.12  1.66

cciss/c0d0p1      0.00    0.00  0.00  0.00    0.00    0.00    5.30    0.00    8.76  5.98  0.00

cciss/c0d0p2      0.00    0.00  0.00  0.00    0.00    0.00    58.45    0.00    7.79  3.21  0.00

cciss/c0d0p3      0.08    5.94  1.28  2.75    17.34    69.52    21.60    0.11  26.82  4.12  1.66

由上可知，很明显，设备/dev/cciss/c0d0p3的等待时间很长。然而，我们并没有挂载找个设备，实际上，它是个LVM设备。如果您使用的是LVM作为存储，那么，您应该发现iostat应该有那么一点混乱。LVM使用device mapper子系统将文件系统映射到物理设备，因此，iostat可能显示多个设备，比如/ dev/dm-0和/ dev/dm-1。而”df –h”的输出却不会显示device mapper路径，而是打印了LVM路径。最简单的方法是在iostat参数中添加选项”-N”。

[username@server~]$ iostat -xN 1

Device:        rrqm/s  wrqm/s  r/s  w/s  rsec/s  wsec/s avgrq-sz avgqu-sz  await  svctm  %util

vg1-root          0.00    0.00  0.09  3.01    0.85    24.08    8.05    0.08  24.69  1.79  0.55

vg1-home          0.00    0.00  0.05  1.46    0.97    11.69    8.36    0.03  19.89  3.76  0.57

vg1-opt          0.00    0.00  0.03  1.56    0.46    12.48    8.12    0.05  29.89  3.53  0.56

vg1-tmp          0.00    0.00  0.00  0.06    0.00    0.45    8.00    0.00  24.85  4.90  0.03

vg1-usr          0.00    0.00  0.63  1.41    5.85    11.28    8.38    0.07  32.48  3.11  0.63

vg1-var          0.00    0.00  0.55  1.19    9.21    9.54    10.74    0.04  24.10  4.24  0.74

vg1-swaplv        0.00    0.00  0.00  0.00    0.00    0.00    8.00    0.00    3.98  1.88  0.00

为简便起见，裁剪上面iostat命令的输出信息。列出的每个文件系统所显示出的IO等待都是不可接受的，观察第十栏标有“await”的数据。相比而言，文件系统/usr的await时间要高一些。我们先来分析一下这个文件系统，使用命令” fuser -vm /opt ”查看哪些进程在访问这个文件系统，进程列表如下。

root@server:/root > fuser -vm /opt

USER        PID ACCESS COMMAND            /opt:                db2fenc1  1067 ....m db2fmp                                db2fenc1  1071 ....m db2fmp                                db2fenc1  2560 ....m db2fmp                                db2fenc1  5221 ....m db2fmp

当前服务器上有112个DB2进程正在访问/opt文件系统，为简便起见，列出四项。看来已经找到导致问题的原因，在服务器上，数据库配置为可使用速度更快的SAN访问，操作系统可以使用的是本地磁盘。可以打电话问问DBA(数据库管理员)怎么做才能这样配置。

最后一个组要的注意的是LVM和device mapper。 “Iostat –xN”命令的输出显示的是逻辑卷名，但它是可以通过命令”ls –lrt / dev /mapper”查到映射关系表。输出信息的第六列中的dm-是与iostat中的设备名相对应的。    有时候，在操作系统或应用层是没有什么可以做的，除了选择速度更快的磁盘，并没有其他的选择。幸运的是，快速磁盘访问，如SAN或SSD的价格正在逐步下降。  

 

记一次磁盘IO高故障排查经历 - [编程]

最初是用户反馈codefs部署代码速度很慢。用dstat 1观察磁盘IO在10～20M左右。iostat -x 1 10观察util接近100%，说明已经达到磁盘性能极限，同时显示数据写入集中在sda5。 
最初怀疑是codefs的问题，但是dstat观察显示磁盘IO很高，网络IO很低。因为codefs写入磁盘的数据来自网络，网络IO远小于磁盘IO，说明不是codefs的问题。同时strace -f -p pid -e trace=write也显示没有写入，更确定不是codefs的问题。剩下只有httpd进程了。我们的httpd禁用了磁盘IO，更不可能是它导致的，并且strace -f -p pid -e trace=write显示只有少量的磁盘IO。但是，停掉httpd进程后，磁盘IO马上就降下来。两者相互矛盾。用mount命令查看/tmp分区挂在sda5，于是lsof | grep tmp发现只有APC的临时文件处于打开状态，但是不知道APC用临时文件干什么。禁用APC之后，磁盘IO降了下来，基本确认是APC的问题。 
APC是php加速器，完全使用内存，怎么会涉及到磁盘呢？原来APC有个选项apc.mmap_file_mask指定的是tmp分区下的文件。看到这个选项的名字，马上就明白是怎么回事了。APC通过mmap的方式使用共享内存，mmap映射到磁盘，而在mmap修改文件时，操作系统会将修改的内容刷到磁盘。APC开了1G的共享内存，大量的小应用导致APC经常的修改mmap的内容，从而导致频繁的将mmap的内容刷到磁盘。解决办法是将apc.mmap_file_mask设置为/dev/shm下的文件，/dev/shm是tmpfs，tmpfs是内存磁盘，没有刚才mmap刷磁盘的问题。 
磁盘IO高是前天就发现的现象，直到今天才引起足够重视并解决。首先被很多的现象所迷惑，1. 最近修改了codefs，而codefs是写磁盘的，怀疑它有道理，但是从它身上没找出问题。2. 前天就发现httpd停掉后，磁盘IO降下来，应该怀疑是它的问题，但这个又和strace的结果矛盾，就没有进一步查找。3. strace只盯着write系统调用，误导了我们，其实很多系统调用都会写磁盘writev，mmap等。其次是排查方法有问题，其实最直接的方法是查看挂载在sda5上的tmp分区，用lsof观察有哪些文件打开，通过文件名获取更详细的信息。最后是，用户不再反馈codefs部署慢，就自我麻痹，不再深究这个问题，逃避现实。 

 

转载于:https://blog.51cto.com/startliu/1386768