1 概述

浪潮信息KOS是浪潮信息基于Linux Kernel、OpenAnolis等开源技术自主研发的一款服务器操作系统，支持x86、ARM等主流架构处理器，性能和稳定性居于行业领先地位，具备成熟的 CentOS 迁移和替换能力，可满足云计算、大数据、分布式存储、人工智能、边缘计算等应用场景需求。详细介绍见官网链接https://www.ieisystem.com/kos/product-kos-xq.thtml?id=12126

典型故障排查

2 文件系统损坏修复全流程（xfs_repair）

目前网上出现大量的主机输入输出错误，原因是由于主机文件系统损坏。一线人员大部分采用的是umont 和 mount的方式恢复，这种恢复方式不能真正修复已经损坏的文件系统，在后续使用过程中，仍然会再次出现主机端输入输出错误。

2.1 需要修复的场景

1	主机侧发现存在文件系统不可读写的情况，也可以通过查看主机端日志来确认是否有文件系统异常发生： xfs_force_shutdown 、I/O error
2	出现异常停电，供电恢复正常，主机和阵列系统重起之后
3	存储介质故障：出现LUN失效、RAID失效、以及IO超时或者出现慢盘，对慢盘进行更换，系统恢复正常之后
4	传输介质故障：如光纤、网线等损坏等，数据传输链路断开后又恢复正常之后

2.2 检查文件系统

注：检查文件系统必须保证将文件系统umount成功。

在根目录下输入“xfs_ncheck /dev/sdd（盘符）；echo $?”（注意：在执行 此命令之前，必须将文件系统umount，否则会出现警告信 “xfs_ncheck: /dev/sdd contains a mounted and writable filesystem ”）敲回车键，查看命令执行返回值：0表示正常，其他为不正常，说明文件系统 损坏，需要修复。

例如：xfs_ncheck /dev/vdc3; echo $?

2.3 修复过程

注：修复时需要暂停主机侧的业务，umount 和 mount 无法修复文件系统 。

先umount要修复的文件系统的分区

然后输入 “xfs_repair /dev/sdd（盘符）”执行修复命令。

xfs_ncheck /dev/sdd; echo $?

如果为0===》成功修复。

如果不为0===》没有成功：请执行xfs_repair –L /dev/sdd命令，再执 行xfs_repair（反复多修复几次）

2.4 xfs常用命令

xfs_admin	调整 xfs 文件系统的各种参数
xfs_copy	拷贝 xfs 文件系统的内容到一个或多个目标系统（并行方式）
xfs_db	调试或检测 xfs 文件系统（查看文件系统碎片等）
xfs_check	检测 xfs 文件系统的完整性
xfs_bmap	查看一个文件的块映射
xfs_repair	尝试修复受损的 xfs 文件系统
xfs_fsr	碎片整理
xfs_quota	管理 xfs 文件系统的磁盘配额
xfs_metadump	将 xfs 文件系统的元数据 (metadata) 拷贝到一个文件中
xfs_mdrestore	从一个文件中将元数据 (metadata) 恢复到 xfs 文件系统
xfs_growfs	调整一个 xfs 文件系统大小（只能扩展）
xfs_logprint	print the log of an XFS filesystem
xfs_mkfile	create an XFS file
xfs_info	expand an XFS filesystem
xfs_ncheck	generate pathnames from i-numbers for XFS
xfs_rtcp	XFS realtime copy command
xfs_freeze	suspend access to an XFS filesystem
xfs_io	debug the I/O path of an XFS filesystem

2.5 具体应用

查看文件块状况: xfs_bmap -v sarubackup.tar.bz2

查看磁盘碎片状况: xfs_db -c frag -r /dev/vdc3

文件碎片整理: xfs_fsr sarubackup.tar.bz2

磁盘碎片整理: xfs_fsr /dev/vdc3

2.6 最后方法

损失部分数据的修复方法

根据打印消息，修复失败时：
先执行xfs_repair -L /dev/sdd(清空日志，会丢失文件)，再执行xfs_repair /dev/sdd，再执行xfs_check /dev/sdd 检查文件系统是否修复成功。

说明：-L是修复xfs文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文件。

备注：

在执行xfs_repair操作前，最好使用xfs_metadump工具保存元数据，一旦修复失败，最起码可以恢复到修复之前的状态。

3 inode耗尽问题的预防与处理

在 Linux 操作系统中，inode 是文件系统中的一个重要概念，它用于唯一标识文件系统中的每个文件或目录。inode 的耗尽通常会导致系统无法创建新的文件或目录，这对于系统的正常运行是至关重要的。本章节将探讨导致 inode 耗尽的原因，并提出一些可能的解决策略，以及预防方案，以帮助系统管理员更好地管理和维护文件系统。

3.1 inode的定义

Linux系统下文件数据储存在"块"中，文件的元信息，例如文件的创建者、文件的创建日期、文件的大小等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。

inode也占用硬盘空间，硬盘格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区（inode table），存放inode所包含的信息。

每个inode节点的大小，一般是128字节或256字节。inode节点的总数，在格式化时就给定，一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中，每个inode节点的大小为128字节，每1KB就设置一个inode，那么inode table的大小就会达到128MB，占整块硬盘的12.8%。

3.2 inode 的组成

inode 通常包含以下信息：

inode号	文件在文件系统中的唯一标识符。
文件类型	指出是文件还是目录。
权限	文件或目录的访问权限，如读、写、执行。
链接数	指向该 inode 的硬链接数量。
所有者ID	文件所有者的用户 ID。
组ID	文件所有者的组 ID。
大小	文件大小，以字节为单位。
块大小	文件系统分配给文件的数据块的大小。
时间戳	文件的创建时间、最后访问时间和最后修改时间。
数据块指针	指向文件数据实际存储位置的数据块指针。

3.3 inode 的作用

inode 是文件系统高效管理文件的关键。当用户访问文件时，系统通过 inode 号快速定位到文件的数据块，而不需要遍历整个文件系统。这样可以显著提高文件访问速度，尤其是在大型文件系统中。此外，inode 还允许实现文件的硬链接，因为硬链接实际上是指向相同 inode 的多个文件名。

3.4 inode 耗尽的原因分析

inode 耗尽通常是由于文件系统的设计和管理不当导致的。以下是一些常见的导致 inode 耗尽的原因：

文件数量过多	在文件系统中，每个文件或目录都需要一个 inode。如果一个文件系统中有大量的文件或目录，那么 inode 的数量可能会迅速耗尽。特别是在一些用于存储大量小文件的系统中，如邮件服务器或版本控制系统，这个问题尤为突出。
硬链接的使用	硬链接是指向同一 inode 的多个文件名。每个硬链接都会增加 inode 的链接数。如果一个文件被频繁地创建硬链接，而没有相应的删除，那么即使文件被删除，其 inode 仍然被占用，导致 inode 无法被回收。
文件系统类型	不同的文件系统类型对 inode 的分配和管理策略不同。例如，ext4 文件系统在格式化时会预先分配一定数量的 inode。如果分配的 inode 数量不足，那么在文件系统使用过程中可能会出现 inode 耗尽的情况。
系统漏洞或错误配置	系统漏洞或错误配置也可能导致 inode 的异常使用。例如，某些应用程序可能会因为编程错误而创建大量临时文件，或者配置错误导致文件系统参数设置不当，从而加速 inode 的消耗。
文件系统损坏	文件系统损坏可能会破坏 inode 的分配记录，导致无法正确释放已删除文件的 inode，或者错误地分配 inode，从而引起 inode 耗尽的问题。

3.5 检测与诊断 inode 耗尽的方法

为了有效管理和维护 Linux 文件系统，系统管理员需要能够及时检测和诊断 inode 耗尽的问题。以下是一些常用的方法和命令，用于检测和诊断 inode 的使用情况。

查看磁盘空间使用情况，使用 df 命令

查看inodess使用情况，使用df -i命令

这条命令会显示系统中每个文件系统的 inode 总数、已使用 inode 数、可用 inode 数以及使用百分比。

使用 find 命令

find 命令可以用来查找文件系统中占用大量 inode 的文件或目录。例如，以下命令会查找当前目录及其子目录下所有大于 10MB 的文件：

find . -type f -size +10M -exec ls -lh {} \;

检查日志文件

系统日志文件（如 /var/log/syslog 或 /var/log/messages）可能会记录关于文件系统的错误信息，包括 inode 耗尽的警告或错误。定期检查这些日志文件可以帮助诊断问题。

3.6 预防与解决 inode 耗尽的策略

inodes的大小在磁盘格式化分区时确定，跟分区的大小相关，分区越大，inodes越大，反之亦然。

linux操作系统根目录一般分区比较小，如果有定时性的小文件产生而又未及时清理，则很容易造成inodes占满。

inodes占满解决步骤：

查看文件最多的目录

for i in /*; do echo $i; find $i | wc -l; done

如果确定目录范围，把/*写的具体点

最终发现是/var/spool/postfix/maildrop目录下小文件过多，原因如下：

由于linux在执行cron时，会将cron执行脚本中的output和warning信息，都会以邮件的形式发送给cron所有者。由于客户环境中的sendmail和postfix没有正常运行，邮件发送不成功，导致全部小文件都堆积在maildrop目录下，另由于缺乏自动清理的机制，故此目录下堆积了大量的文件。

经过排查root用户下发现有个每分钟进行一次时钟同步的定时任务，该定时任务每分钟产生一个小文件。

删除大量文件

ls | xargs -n 1000 rm -rf

需要使用xargs命令，不然会删除失败。

设置方面

在crontab -e 第一行增加MAILTO="" ，就没有文件产生啦

重定向

对定时任务设置定向输出文件，不需要日志输出的定时任务可以将日志重定向到/dev/null，如下：

*/10 * * * * /tmp/test.sh >/dev/null 2>&1

定时清理文件

find 目录 -type f -mtime +30 | xargs -n 1000 rm -f

监控inodes的使用

备注：应注意crontab的写法和产生的文件的定时清理

3.7 实际案例分析

邮件服务器 inode 耗尽

背景：一个邮件服务器在运行过程中遇到了 inode 耗尽的问题，导致无法接收和发送邮件。

原因分析：邮件服务器在处理大量邮件时，会在特定的目录下生成大量的临时文件。如果这些临时文件没有被正确删除，或者邮件服务器软件存在 bug 导致不断生成新文件，inode 的数量就会迅速减少。

解决策略：

清理临时文件	定期检查邮件服务器生成的临时文件目录，并清理这些文件。
优化邮件服务器配置	调整邮件服务器配置，减少临时文件的使用，或者确保文件在不再需要时被正确删除。
监控和告警	实施监控系统，当 inode 使用率达到一定阈值时发送告警，以便及时处理。

版本控制系统 inode 耗尽

背景：一个使用版本控制系统（如 Git）的项目组发现，随着项目的发展，版本控制库所在的文件系统 inode 数量逐渐减少。

原因分析：版本控制系统在处理版本变更时，会生成大量的元数据文件。如果项目组频繁进行提交和分支操作，文件系统中会产生大量的文件和目录，从而导致 inode 的快速消耗。

解决策略：

定期清理旧版本	定期删除不再需要的旧版本和分支，以释放 inode。
使用更高效的存储策略	考虑使用支持 inode 高效管理的文件系统，或者优化版本控制系统的存储策略。
迁移到更大的文件系统	如果 inode 数量确实不足，可以考虑迁移到具有更多 inode 的文件系统。

通过上述案例分析，我们可以看到，inode 耗尽的问题通常是由于文件系统的使用模式和管理策略不当导致的。通过合理规划、监控、优化配置和及时清理，可以有效地避免和解决 inode 耗尽的问题。

4 处理僵尸IO请求的实战步骤

4.1 僵尸进程

当 iowait 升高时，进程很可能因为得不到硬件的响应，而长时间处于不可中断状态。从 ps 或者 top 命令的输出中，你可以发现它们都处于 D 状态，也就是不可中断状态（Uninterruptible Sleep）。既然说到了进程的状态，进程有哪些状态你还记得吗？我们先来回顾一下。

top 和 ps 是最常用的查看进程状态的工具，我们就从 top 的输出开始。下面是一个 top 命令输出的示例，S 列（也就是 Status 列）表示进程的状态。从这个示例里，你可以看到 R、D、Z、S、I 等几个状态，它们分别是什么意思呢？

R	Running 或 Runnable 的缩写，表示进程在 CPU 的就绪队列中，正在运行或者正在等待运行
D	Disk Sleep 的缩写，也就是不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断
Z	Zombie 的缩写，如果你玩过“植物大战僵尸”这款游戏，应该知道它的意思。它表示僵尸进程，也就是进程实际上已经结束了，但是父进程还没有回收它的资源（比如进程的描述符、PID 等）
S	Interruptible Sleep 的缩写，也就是可中断状态睡眠，表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时，它会被唤醒并进入 R 状态
I	Idle 的缩写，也就是空闲状态，用在不可中断睡眠的内核线程上。前面说了，硬件交互导致的不可中断进程用 D 表示，但对某些内核线程来说，它们有可能实际上并没有任何负载，用 Idle 正是为了区分这种情况。要注意，D 状态的进程会导致平均负载升高， I 状态的进程却不会

第一个是 T 或者 t，也就是 Stopped 或 Traced 的缩写，表示进程处于暂停或者跟踪状态。

向一个进程发送 SIGSTOP 信号，它就会因响应这个信号变成暂停状态（Stopped）；再向它发送 SIGCONT 信号，进程又会恢复运行（如果进程是终端里直接启动的，则需要你用 fg 命令，恢复到前台运行）。

而当你用调试器（如 gdb）调试一个进程时，在使用断点中断进程后，进程就会变成跟踪状态，这其实也是一种特殊的暂停状态，只不过你可以用调试器来跟踪并按需要控制进程的运行。另一个是 X，也就是 Dead 的缩写，表示进程已经消亡，所以你不会在 top 或者 ps 命令中看到它。

如果系统或硬件发生了故障，进程可能会在不可中断状态保持很久，甚至导致系统中出现大量不可中断进程。这时，你就得注意下，系统是不是出现了 I/O 等性能问题。

再看僵尸进程，这是多进程应用很容易碰到的问题。正常情况下，当一个进程创建了子进程后，它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束，回收子进程的资源；而子进程在结束时，会向它的父进程发送 SIGCHLD 信号，所以，父进程还可以注册 SIGCHLD 信号的处理函数，异步回收资源。

如果父进程没这么做，或是子进程执行太快，父进程还没来得及处理子进程状态，子进程就已经提前退出，那这时的子进程就会变成僵尸进程。换句话说，父亲应该一直对儿子负责，善始善终，如果不作为或者跟不上，都会导致“问题少年”的出现。

通常，僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程退出后，由 init 进程回收后也会消亡。

一旦父进程没有处理子进程的终止，还一直保持运行状态，那么子进程就会一直处于僵尸状态。大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建，所以这种情况一定要避免。

4.2 分析

ps aux | grep /app #查看启动的APP

状态分别是 Ss+ 和 D+。其中，

S 表示可中断睡眠状态，D 表示不可中断睡眠状态，

s 表示这个进程是一个会话的领导进程，而 + 表示前台进程组。（也可通过命令查询man ps ）

进程组表示一组相互关联的进程，比如每个子进程都是父进程所在组的成员

而会话是指共享同一个控制终端的一个或多个进程组。

4.3 汇总

第一点，iowait 太高了，导致系统的平均负载升高，甚至达到了系统 CPU 的个数。

第二点，僵尸进程在不断增多，说明有程序没能正确清理子进程的资源。

大量不可中断进程和僵尸进程的处理方法

现象：

iowait太高，导致平均负载升高，并且达到了系统CPU的个数

僵尸进程不断增多

分析过程：

1.先分析iowait升高的原因

一般iowait升高，可能的原因是i/o问题

用dstat 命令同时查看cpu和i/o对比情况（如 dstat 1 10 间隔1秒输出10组数据），通过结果可以发现iowait升高时，磁盘读请求（read）升高

所以推断iowait升高是磁盘读导致

定位磁盘读的进程，使用top命令查看处于不可中断状态（D）的进程PID

查看对应进程的磁盘读写情况，使用pidstat命令，加上-d参数，可以看到i/o使用情况（如 pidstat -d -p 1 3）,发现处于不可中断状态的进程都没有进行磁盘读写

继续使用pidstat命令，但是去掉进程号，查看所有进程的i/o情况（pidstat -d 1 20），可以定位到进行磁盘读写的进程。我们知道进程访问磁盘，需要使用系统调用

下面的重点就是找到该进程的系统调用

使用strace查看进程的系统调用 strace -p

ps aux | grep 如果发现进程处于Z状态，说明已经变成了僵尸进程，不能进行系统调用分析了

既然top和pidstat都不能找出问题，使用基于事件记录的动态追踪工具

操作：

系统上运行 perf record -g ，执行一会儿按ctrl+c停止

执行perf report进一步分析，看有没有I/O操作

僵尸进程出现的原因是父进程没有回收子进程的资源出现的。解决办法是找到父进程，在父进程中处理，使用pstree查父进程，然后查看父进程的源码检查wait()/waitpid()的调用或SIGCHLD信号处理函数的注册

性能问题诊断与优化

5 识别IOwait的十八种姿势

5.1 什么是 iowait 以及它如何影响 Linux 性能

I/O 等待或者 iowait、wait、wa、%iowait 或 wait% 通常由 top、sar、atop 等 Linux 命令行系统监控工具显示。就其本身而言，它是让我们深入窥探 Linux 系统性能的众多性能统计数据之一。

什么是 I/O 等待？

I/O 等待适用于 Unix 和所有基于 Unix 的系统，包括 macOS、FreeBSD、Solaris 和 Linux。

I/O 等待 (iowait) 是 CPU（或多个 CPU）空闲的时间百分比，在此期间系统有待处理的磁盘 I/O 请求。（来源：man sar）top man 手册页给出了这个简单的解释："I/O 等待 = 等待 I/O 完成的时间。" 换句话说，I/O 等待的存在告诉我们系统空闲时它可以处理未完成的请求。

在使用 Linux top 和其他工具时，你会注意到 CPU（及其核心）在以下状态下运行：us（用户态）、sy（内核态）、id（空闲）、ni（nice）、si（软中断）、hi（硬中断）、st（steal）和 wa（等待）。其中，用户态、内核态、空闲状态和等待状态的值加起来应为 100%。请注意，"idle" 和 "wait" 是不同的。"idle" CPU 表示没有工作负载存在，而另一方面，"wait" (iowait) 表示 CPU 何时处于空闲状态等待未完成的请求。

如果 CPU 空闲，内核将确定任何来自 CPU 的未完成 I/O 请求（比如 SSD 或 NFS）。如果有，则 "iowait" 计数器递增。如果没有任何待处理的请求，则 "idle" 计数器会增加。

I/O 等待和 Linux 服务器性能

值得注意的是， iowait 有时可以指示吞吐量瓶颈，而在其他时候，iowait 可能完全没有意义。有可能拥有高 iowait 的健康系统，但也可能有完全没有 iowait 的存在瓶颈的系统。

I/O 等待只是 CPU / CPU 核心的指示状态之一。高 iowait 意味着你的 CPU 正在等待请求，但你需要进一步调查以确认来源和影响。

例如，服务器存储（SSD、NVMe、NFS 等）几乎总是比 CPU 性能慢。因此，I/O 等待可能会产生误导，尤其是涉及到随机读/写工作负载时。这是因为 iowait 仅测量 CPU 性能，而不测量存储 I/O。

虽然 iowait 表明 CPU 可以处理更多的工作负载，但根据服务器的工作负载以及负载如何执行计算或使用存储 I/O，并不总是可以解决 I/O 等待。或者实现接近于零的值是不可行的。

根据最终用户体验、数据库查询健康状况、事务吞吐量和整体应用程序健康状况，你必须决定报告的 iowait 是否表明 Linux 系统性能不佳。

例如，如果你看到 1% 到 4% 的低 iowait，然后将 CPU 升到 2 倍的性能，iowait 也会增加。具有相同存储性能的 2 倍更快的 CPU = ~ 2 倍的等待时间。你需要考虑你的工作负载来确定应该首先关注哪些硬件。

监控和减少 I/O 等待相关问题

让我们看看一些用于监视 Linux 上的 I/O 等待的有价值的工具。

5.2 减少 I/O 等待相关问题

采取以下步骤减少与 I/O 等待相关的问题：

1	优化应用程序的代码和数据库查询。这可以大大降低磁盘读/写的频率。这应该是你的第一个方法，因为应用程序越高效，在硬件上的长期花费就越少。
2	使 Linux 系统和软件版本保持最新。这不仅对安全性更好，而且通常情况下，最新支持的版本会提供显着的性能改进，无论是 Nginx、Node.js、PHP、Python 还是 MySQL。
3	确保有空闲的可用内存。足够的空闲内存，以便大约一半的服务器内存用于内存缓冲区和缓存，而不是交换和换页到磁盘。当然，这个比例会因情况而异。因此，请确保你没有交换，并且内核缓存压力不会因缺少可用内存而变高。
4	调整系统、存储设备和 Linux 内核以提高存储性能和使用寿命。
5	如果一切都失败了：将存储设备升级到更快的 SSD、NVMe 或其他高吞吐量存储设备。

5.3 top命令显示iowait (wa)非常高时怎么排查

当 top 命令显示 iowait (wa) 非常高时，表示系统正在等待 I/O 操作完成。要确定是磁盘 I/O 还是网络 I/O 导致的等待，可以使用以下工具和方法进行进一步排查。

使用 iostat 检查磁盘 I/O

iostat 是一个专门用于监控磁盘 I/O 的工具，可以显示磁盘的读写速度和等待时间。

安装 iostat（如果未安装）：

yum install sysstat

使用 iostat 查看磁盘 I/O：

iostat -x 1

-x：显示扩展统计信息。

1：每秒刷新一次。

关键指标：

%util	磁盘利用率。如果接近 100%，表示磁盘 I/O 是瓶颈。
await	平均 I/O 等待时间（毫秒）。如果较高，表示磁盘响应慢。
r/s 和 w/s	每秒的读写操作数。

如果 %util 和 await 较高，说明磁盘 I/O 是导致 iowait 高的原因。

使用 iotop 检查磁盘 I/O

iotop 是一个实时监控磁盘 I/O 的工具，可以显示每个进程的磁盘读写情况。

安装 iotop（如果未安装）：

yum install iotop

使用 iotop：

查看哪些进程正在大量读写磁盘。

如果某些进程的磁盘读写量（DISK READ 和 DISK WRITE）非常高，说明它们可能是导致磁盘 I/O 瓶颈的原因。

使用 dstat 综合检查

dstat 是一个多功能工具，可以同时监控 CPU、磁盘、网络等资源。

安装dstat：

yum install dstat

使用 dstat：

查看 CPU、磁盘、网络等资源的实时使用情况。

如果磁盘或网络的使用率非常高，说明它们可能是导致 iowait 高的原因。

5.4 总结

iowait 统计数据是一个有用的性能统计数据，可用于监控 CPU 利用率健康状况。当 CPU 空闲并且可以执行更多计算时，它会通知系统管理员。然后，我们可以使用可观察性、基准测试和跟踪工具（例如上面列出的那些工具）来综合了解系统的整体 I/O 性能。你的主要目标应该是消除因等待磁盘、NFS 或其他与存储相关的 I/O 而直接导致的任何 iowait。

6 使用SystemTap分析锁竞争

6.1 SystemTap简介

SystemTap 是一个强大的工具，用于在不修改内核源代码的情况下，对 Linux 内核进行监控和调试。它允许你编写脚本（通常是使用 Stap 语言），来监视和分析系统运行时的行为。想使用 SystemTap 来分析 Linux 文件系统的锁竞争问题，可以按照以下步骤进行：

安装 SystemTap

安装依赖

yum install gcc make elfutils-libelf-devel rpm-devel nss-devel python3-devel

下载软件包

https://sourceware.org/systemtap/ftp/releases/下载systemtap-4.8.tar.gz

https://sourceware.org/elfutils/ftp/0.176/下载elfutils-0.176.tar.bz2

上传至服务器并解压

tar -zxvf systemtap-4.8.tar.gz

tar -xjf elfutils-0.176.tar.bz2

cd到systemtap-4.8目录开始编译安装

./configure --with-elfutils=./elfutils-0.176

make all

make install

mv /usr/bin/stap /usr/bin/stap.bak

mv stap /usr/bin/

stap -V

6.2 理解文件系统锁

在分析之前，需要了解 Linux 文件系统的锁机制，了解哪些操作会触发锁的获取和释放是非常重要的。

Linux文件系统的锁机制主要包括建议性锁和强制性锁‌。建议性锁要求进程显式地检查锁的存在并尊重已有的锁，而强制性锁则由内核强制执行，当一个文件被上锁进行写入操作时，内核会阻止其他进程对该文件进行读写操作‌。

强制性锁

强制性锁是由内核执行的锁，当一个进程对文件设置了强制性锁后，其他进程试图对该文件进行读写操作时会被阻塞，直到锁被释放。这种锁主要用于保护文件的完整性，防止数据损坏。在Linux中，实现强制性锁的函数主要有fcntl和lockf。fcntl函数提供了细粒度的文件锁控制，可以用来实现强制性锁。其函数原型如下：

其中，cmd参数可以取以下值：

F_SETLKW	设置锁并等待，如果无法立即获取锁，则阻塞直到锁可用。
F_SETLK	设置锁但不等待，如果无法立即获取锁，则返回错误。
F_GETLK	获取锁状态‌。

建议性锁

建议性锁要求每个使用上锁文件的进程都要检查是否有锁存在，并且尊重已有的锁。在一般情况下，内核和系统不使用建议性锁，而是依靠程序员遵守这个规定。实现建议性锁的函数有lockf()和fcntl()。lockf函数用于对文件施加建议性锁，其函数原型如下：

其中，operation参数可以取以下值：

LOCK_SH	共享锁，允许多个进程对同一文件读取，不允许写入。
LOCK_EX	排他锁（写锁），确保只有一个进程能够写入文件。
LOCK_UN	解锁操作，释放锁。
LOCK_NB	非阻塞锁标志，与LOCK_SH或LOCK_EX组合使用，如果无法立即加锁，则返回错误并设置errno为EWOULDBLOCK‌。

6.3 编写 SystemTap 脚本

创建一个 SystemTap 脚本来跟踪文件系统的锁操作。以下是一个基本的示例，用于探测通用VFS锁调用：

global lock_acquires, lock_releases

probe kernel.function("__lock_buffer").entry {

lock_acquires++

}

probe kernel.function("unlock_buffer").entry {

lock_releases++

}

probe timer.ms(1000) {

printf("Lock Acquires: %d\n", lock_acquires)

printf("Lock Releases: %d\n", lock_releases)

lock_acquires = 0

lock_releases = 0

}

这个脚本会监控__lock_buffer和unlock_buffer函数的调用次数，并每秒打印一次这些次数。

6.4 运行 SystemTap 脚本

保存你的脚本到一个文件中，例如 fs_locks.stp，然后使用以下命令运行它：

stap fs_locks.stp

运行之前需要先下载一个内核devel包并安装，如我们这里下载安装kernel-devel-4.19.91-26.6.26.kos5.x86_64.rpm

再运行脚本

6.5 分析输出

观察输出的锁获取和释放次数，以识别是否存在频繁的锁竞争。如果发现锁竞争非常高，可能需要进一步分析哪些操作导致了这些锁的频繁获取和释放。

6.6 深入分析

如果你发现某些特定的函数或操作导致锁竞争，你可以进一步细化你的 SystemTap 脚本，例如跟踪特定函数的调用路径或参数：

probe kernel.function("some_specific_function").call {

printf("Function called: %s\n", probefunc())

}

7 文件系统性能优化

由于各种的I/O负载情形各异，Linux系统中文件系统的缺省配置一般来说都比较中庸，强调普遍适用性。然而在特定应用下，这种配置往往在I/O性能方面不能达到最优。因此，如果应用对I/O性能要求较高，除了采用性能更高的硬件（如磁盘、HBA卡、CPU、MEM等）外，我们还可以通过对文件系统进行性能调优，来获得更高的I/O性能提升。总的来说，主要可以从三个方面来做工作：

1	Disk相关参数调优
2	文件系统本身参数调优
3	文件系统挂载(mount)参数调优

当然，负载情况不同，需要结合理论分析与充分的测试和实验来得到合理的参数。下面以SATA磁盘上的EXT3文件系统为例，给出Linux文件系统性能优化的一般方法。请根据自身情况作适合调整。

7.1 Disk相关参数

Cache mode:启用WCE=1(Write Cache Enable), RCD=0(Read Cache Disable)模式

启用写缓存

hdparm -W 1 /dev/sda

禁用读缓存

hdparm -R 0 /dev/sda

Linux I/O scheduler算法

经过实验，在重负载情形下，deadline调度方式对squidI/O负载具有更好的性能表现。其他三种为noop(fifo), as, cfq，noop多用于SAN/RAID存储系统，as多用于大文件顺序读写， cfq适于桌面应用。

echo deadline > /sys/block/vdc/queue/scheduler

deadline调度参数

对于redhat linux建议 read_expire = 1/2 write_expire，对于大量频繁的小文件I/O负载，应当这两者取较小值。更合适的值，需要通过实验测试得到。

echo 500 > /sys/block/vdc/queue/iosched/read_expire

echo 1000 > /sys/block/vdc/queue/iosched/write_expire

readahead 预读扇区数

预读是提高磁盘性能的有效手段，目前对顺序读比较有效，主要利用数据的局部性特点。比如在我的系统上，通过实验设置通读256块扇区性能较优。

blockdev --setra 256 /dev/vdc

7.2 EXT3文件系统参数

block size = 4096 (4KB)

mkfs.ext3 -b指定，大的数据块会浪费一定空间，但会提升I/O性能。EXT3文件系统块大小可以为1KB、2KB、4KB。

如：

inode size

这是一个逻辑概念，即一个inode所对应的文件相应占用多大物理空间。mkfs.ext3 -i指定，可用文件系统文件大小平均值来设定，可减少磁盘寻址和元数据操作时间。

推荐值：

如:

reserved block

mkfs.ext3 -m指定，缺省为5%，可调小该值以增大部分可用存储空间。

如：

disable journal

对数据安全要求不高的应用（如web cache），可以关闭日志功能，以提高I/O性能。

tune2fs -O^has_journal /dev/vdc3

7.3 mount参数

noatime, nodirtime	访问文件目录，不修改访问文件元信息，对于频繁的小文件负载，可以有效提高性能。
async	异步I/O方式，提高写性能。
data=writeback (if journal)	日志模式下，启用写回机制，可提高写性能。数据写入顺序不再保护，可能会造成文件系统数据不一致性，重要数据应用慎用。
barrier=0 (if journal)	barrier=1，可以保证文件系统在日志数据写入磁盘之后才写commit记录，但影响性能。重要数据应用慎用，有可能造成数据损坏。

可依据以上三块调优方向的方法并根据自身情况进行调整，来获得更高的I/O性能提升。