centos 查看io centos8和9的区别

大家好，今天来为大家分享centos 查看io的一些知识点，和centos8和9的区别的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！

linux查看磁盘io的几种方法

怎样才能快速的定位到并发高是由于磁盘io开销大呢?可以通过三种方式：

第一种：用 top命令中的cpu信息观察

Top可以看到的cpu信息有：

Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si

具体的解释如下：

Tasks: 29 total进程总数

1 running正在运行的进程数

28 sleeping睡眠的进程数

0 stopped停止的进程数

0 zombie僵尸进程数

Cpu(s):

0.3% us用户空间占用CPU百分比

1.0% sy内核空间占用CPU百分比

0.0% ni用户进程空间内改变过优先级的进程占用CPU百分比

98.7% id空闲CPU百分比

0.0% wa等待输入输出的CPU时间百分比

0.0% hi

0.0% si

0.0% wa的百分比可以大致的体现出当前的磁盘io请求是否频繁。如果 wa的数量比较大，说明等待输入输出的的io比较多。

第二种：用vmstat

vmstat命令报告关于线程、虚拟内存、磁盘、陷阱和 CPU活动的统计信息。由 vmstat命令生成的报告可以用于平衡系统负载活动。系统范围内的这些统计信息(所有的处理器中)都计算出以百分比表示的平均值，或者计算其总和。

输入命令：

vmstat 2 5

如果发现等待的进程和处在非中断睡眠状态的进程数非常多，并且发送到块设备的块数和从块设备接收到的块数非常大，那就说明磁盘io比较多。

vmstat参数解释：

Procs

r:等待运行的进程数 b:处在非中断睡眠状态的进程数 w:被交换出去的可运行的进程数。此数由 linux计算得出，但 linux并不耗尽交换空间

Memory

swpd:虚拟内存使用情况，单位：KB

free:空闲的内存，单位KB

buff:被用来做为缓存的内存数，单位：KB

Swap

si:从磁盘交换到内存的交换页数量，单位：KB/秒

so:从内存交换到磁盘的交换页数量，单位：KB/秒

IO

bi:发送到块设备的块数，单位：块/秒

bo:从块设备接收到的块数，单位：块/秒

System

in:每秒的中断数，包括时钟中断

cs:每秒的环境(上下文)切换次数

CPU

按 CPU的总使用百分比来显示

us: CPU使用时间

sy: CPU系统使用时间

id:闲置时间

准测

更多vmstat使用信息

第二种：用iostat

安装:

Iostat是 sysstat工具集的一个工具，需要安装。

Centos的安装方式是：

yum install sysstat

Ubuntu的安装方式是：

aptitude install sysstat

使用：

iostat-dx显示磁盘扩展信息

root@fileapp:~# iostat-dx

r/s和 w/s分别是每秒的读操作和写操作，而rKB/s和wKB/s列以每秒千字节为单位显示了读和写的数据量

如果这两对数据值都很高的话说明磁盘io操作是很频繁。

如何让CentOS服务器磁盘io性能翻倍

如何让CentOS服务器磁盘io性能翻倍

这一期我们来看一下有哪些办法可以减少linux下的文件碎片。主要是针对磁盘长期满负荷运转的使用场景（例如http代理服务器）；另外有一个小技巧，针对互联网图片服务器，可以将io性能提升数倍。如果为服务器订制一个专用文件系统，可以完全解决文件碎片的问题，将磁盘io的性能发挥至极限。对于我们的代理服务器，相当于把io性能提升到3-5倍。

在现有文件系统下进行优化linux内核和各个文件系统采用了几个优化方案来提升磁盘访问速度。但这些优化方案需要在我们的服务器设计中进行配合才能得到充分发挥。

文件系统缓存linux内核会将大部分空闲内存交给虚拟文件系统，来作为文件缓存，叫做page cache。在内存不足时，这部分内存会采用lru算法进行淘汰。通过free命令查看内存，显示为cached的部分就是文件缓存了。

如果能找到当前使用场景下，文件被访问的统计特征，针对性的写一个淘汰算法，可以大幅提升文件缓存的命中率。对于http正向代理来说，一个好的淘汰算法可以用1GB内存达到lru算法100GB内存的缓存效果。如果不打算写一个新的淘汰算法，一般不需要在应用层再搭一个文件cache程序来做缓存。

最小分配

最小分配的副作用是会浪费一些磁盘空间（分配了但是又没有使用）

如果当前使用场景下小文件很多，把预分配改大就会浪费很多磁盘空间，所以这个数值要根据当前使用场景来设定。似乎要直接改源代码才能生效，不太记得了，09年的时候改的，有兴趣的同学自己google吧。

io访问调度

如何针对性优化：io访问调度能大幅提升io性能，前提是应用层同时发起了足够的io访问供linux去调度。怎样才能从应用层同时向内核发起多个io访问呢？方案一是用aio_read异步发起多个文件读写请求。

小提示：将文件句柄设置为非阻塞时，进程还是会睡眠等待磁盘io，非阻塞对于文件读写是不生效的。在正常情况下，读文件只会引入十几毫秒睡眠，所以不太明显；而在磁盘io极大时，读文件会引起十秒以上的进程睡眠。详见内核源代码do_generic_file_read会调用lock_page_killable进入睡眠，但是不会判断句柄的非阻塞标志。

预读取linux内核可以预测我们“将来的读请求”并提前将数据读取出来。通过预读取可以减少读io的次数，并且减小读请求的延时。

当文件扩大，需要分配磁盘空间时，可以不立即进行分配，而是暂存在内存中，将多次分配磁盘空间的请求聚合在一起后，再进行一次性分配。

延迟分配的副作用有几个：1如果应用程序每次写数据后都通过fsync等接口进行强制刷新，延迟分配将不起作用2延迟分配有可能间歇性引入一个较大的磁盘IO延时（因为要一次性向磁盘写入较多数据）

如何针对性优化：

“让每个目录下的文件连续存储”是一个极有价值的功能。假设一个网页上有10张图片，这10张图片虽然存在10个文件中，但其实是几乎同时被用户访问的。如果能让这10张图片存储在连续的磁盘空间中，就能把io性能提升10倍（一次寻道就可以读10个文件了）传统的做法是通过拼接图片来将这10张图片合并到一张大图中，再由前端将大图切成10张小图。有了e4defrag后，可以将需连续访问的文件放在同一个文件夹下，再定期使用e4defrag进行磁盘整理。

实现自己的文件系统我们曾经写过一款专用文件系统，针对代理服务器，将磁盘io性能提升到3-5倍。在大部分服务器上，不需要支持“修改文件”这个功能。一旦文件创建好，就不能再做修改操作，只支持读取和删除。在这个前提下，我们可以消灭所有文件碎片，把磁盘io效率提升到理论极限。

大于16MB的文件，服务器创建文件时告诉文件系统分配16MB磁盘空间。后续每次扩大文件大小时，要么是16MB，要么就是文件终结。不允许在文件未终结的情况下分配非16MB的空间。读写文件时，每次读写16MB或者直到文件末尾。

在我们的文件系统中，小文件完全无碎片，一次寻道就能搞定一个文件，达到了理论上最佳的性能。大文件每次磁头定位读写16MB，性能没有达到100%，但已经相当好了。有一个公式可以衡量磁盘io的效率：磁盘利用率=传输时间/（平均寻道时间+传输时间）对我们当时采用的磁盘来说（1T 7200转sata)，16MB连续读写已经可以达到98%以上的磁盘利用率。

CentOS系统中跟踪高IO等待详解

高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 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的价格正在逐步下降。