一、确认是卡顿的原因

1、异常现象

1. lsblk命令执行卡顿
2. df -Th执行卡顿
3. 分析后所有和io相关的命令执行均缓慢
4. load值正常，top，ls等命令执行正常。
5. docker启动停止某个容器夯住，超时。

2、通过strace追踪

在Linux系统中，strace是一个常用的命令行工具，用于跟踪进程执行过程中的系统调用和信号。下面是使用strace命令的一些常见方法和选项：

1. 基本语法

strace command

其中command是要跟踪的进程或命令。例如，要跟踪ls命令的系统调用，可以使用以下命令：

strace ls

2. 跟踪进程
   如果要跟踪正在运行的进程，可以使用-p选项，后跟进程ID。例如，要跟踪进程ID为1234的进程，可以使用以下命令：

strace -p 1234

3. 显示系统调用
   默认情况下，strace将显示跟踪进程执行期间所有的系统调用。可以使用-e选项，后跟系统调用名称或数字，只跟踪指定的系统调用。例如，要跟踪进程执行期间所有的read和write系统调用，可以使用以下命令：

strace -e trace=read,write command

4. 输出到文件
   可以使用-o选项将跟踪结果输出到文件。例如，要将跟踪结果输出到文件trace.log，可以使用以下命令：

strace -o trace.log command

5. 显示调用时间
   可以使用-T选项显示每个系统调用的耗时。例如，要显示每个系统调用的耗时，可以使用以下命令：

strace -T command

6. 显示系统调用参数
   可以使用-v选项显示每个系统调用的参数。例如，要显示每个系统调用的参数，可以使用以下命令：

strace -v command

这些是strace命令的一些常见用法和选项，可以根据需要进行调整。strace是一个强大的调试工具，可以帮助我们诊断应用程序中的问题和错误。

3、开始定位

首先我们通过 strace df -Th 以及 strace lsblk 两个命令去查看，到底是什么原因导致命令执行结果久久不能输出：
通过strace发现，不是简单的卡顿，而是挂载的文件系统太多了导致输出很多，具体如下：

[root@rg13-test-control001 mmwei3]# strace df -Th
......
......
......
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
[root@rg13-test-control001 mmwei3]# strace lsblk
...
...
...
/run
/run/user/0
/run/docker/netns/default

4、分析结果

1、这里我们简单分析下这几个目录是干什么的？

1）、关于/run/docker/netns/default

当 Docker 容器运行在一台宿主机上时，Docker 使用 Linux 的网络命名空间来隔离不同的网络栈，以确保 Docker 容器之间的网络隔离。网络命名空间允许多个进程在同一台主机上共享网络设备，但是每个进程都有自己独立的网络栈。
当 Docker 创建一个新的容器时，它会创建一个新的网络命名空间并将容器的网络接口添加到该命名空间中。Docker 使用 ip netns 命令来管理网络命名空间。在 ip netns 的帮助下，Docker 可以将容器的网络接口添加到正确的网络命名空间中，并确保容器与宿主机以及其他容器之间的网络隔离。
/run/docker/netns/default 文件包含网络命名空间的标识符。Docker 使用这个标识符来查找命名空间并将容器的网络接口添加到正确的命名空间中。如果该文件不存在，则 Docker 无法找到网络命名空间，容器的网络接口将无法正确配置，从而导致容器之间的网络通信问题。
因此，/run/docker/netns/default 文件是 Docker 网络命名空间的关键组成部分。它确保了 Docker 容器之间的网络隔离，并使 Docker 容器可以在同一主机上运行，同时确保它们之间的网络通信彼此独立。

2）、关于/run/user/0

/run/user/0 目录是 Linux 系统中的一个临时文件系统，它的主要作用是为当前用户提供一个私有的、快速访问的临时存储空间。在 CentOS 系统中，每个用户都有自己的 /run/user/ 目录，用于存储当前用户的运行时文件和套接字。

临时文件系统是一种在内存中创建的文件系统，它不会在磁盘上持久化存储文件。在 Linux 中，临时文件系统通常基于 tmpfs 技术实现，它将一部分内存用作文件系统的存储空间，这些存储空间的大小取决于系统内存的大小和使用情况。

在 CentOS 系统中，/run/user/0 目录是只有当前用户可以访问的，这意味着其他用户无法访问该目录中的文件。当用户登录到系统时，系统会自动为其创建一个 /run/user/ 目录，该目录由系统管理员设置为一个私有目录，只有该用户可以读取和写入其中的文件。

/run/user/0 目录中通常存储一些运行时文件，如 UNIX 套接字、共享内存和进程 ID 文件等。这些文件是在程序运行期间由程序动态创建的，它们只在程序运行期间存在，并在程序退出时被自动删除。

• 这里我们简单举个例子：

例如，当用户在终端中打开一个新的 shell 会话时，系统会在 /run/user/0 目录中创建一个套接字文件，该文件用于与新 shell 会话通信。当用户退出该 shell 会话时，系统会自动删除该套接字文件。
/run/user/0 目录是 CentOS 系统中一个重要的临时文件系统，它为当前用户提供了一个私有的、快速访问的临时存储空间。它通常用于存储程序的运行时文件和套接字等临时文件，这些文件在程序运行期间被动态创建，并在程序退出时被自动删除。

3）、关于/run

在 CentOS 系统中，/run 目录是一个临时文件系统（tmpfs），用于存储系统运行期间需要保存的运行时数据和状态信息。
/run 目录中存储了系统在运行期间需要保留的各种文件和目录，例如进程 ID 文件、锁文件、套接字文件、网络接口文件、udev 设备文件等等。这些文件和目录通常在系统启动时由各种服务和守护进程创建，并在系统关闭时被清理和删除。
/run 目录是一个临时文件系统，这意味着它不是在硬盘上持久化存储数据，而是在内存中创建的，它的存储空间大小取决于系统内存的大小和使用情况。这种设计可以提高文件系统的读写速度和响应速度，并且避免了在硬盘上频繁写入数据导致的性能问题。

5、为什么以上三者的挂载点突然增多？

主要是跟我们的环境业务有关，我们把该服务器安装了iscsi-initiator-utils ，作为客户端去连接后段存储，链路出现异常，导致无效链接数增多，进而出现n个tmpfs文件系统，且被挂载。

二、最终解决方案

1、强制卸载无效tmpfs

这里说明下，为什么没有先停止服务呢，比如正在运行的docker服务，或者其他服务？

1. 因为机器但凡涉及到io类的操作，均无法执行，比如df -Th . lsblk docker restart xxx 等因为异常的tmpfs太多了导致。
2. 机器即使重启后，仍然会出现该问题
3. 最终采用强制卸载，然后重启docker 相关服务

[root@rg13-test-control001 mmwei3]#  umount -l /run/docker/netns/default
[root@rg13-test-control001 mmwei3]#  umount -l /run/user/0
[root@rg13-test-control001 mmwei3]#  umount -l /run
[root@rg13-test-control001 mmwei3]#  systemctl restart docker

2、为什么会出现这么多异常tmpfs?

根据以上分析，tmpfs 文件系统是用于存储临时文件和运行时数据的一种内存文件系统。它可以提供快速的读写速度和低延迟，因此在一些需要快速处理大量数据的场景下得到广泛应用。
然而，如果系统中出现了大量的 tmpfs 文件系统挂载，可能会导致 lsblk 命令执行缓慢的情况。这是因为 lsblk 命令需要遍历系统中的所有块设备和文件系统，并且在每个挂载点检查文件系统类型和容量等信息，如果存在大量的 tmpfs 文件系统挂载，将会导致 lsblk 命令的执行时间大大延长。

• 这里一个小技巧

lsblk
使用 -P 参数：lsblk 命令可以使用 -P 参数以 JSON 格式输出块设备和文件系统信息，这样可以减少输出内容并且加快命令执行速度。也使用 ip netns del 命令来删除不需要的网络命名空间。---docker
以及systemd-tmpfiles 命令来清理临时文件

三、业务替换

1、最终还是需要使用iscsi

后来升级了iscsi-initiator-utils的版本，iscsi链接数异常，就再也没有出现了。这个具体为什么还未来得及定位。
Centos升级到了 iscsi-initiator-utils-iscsiuio-6.2.0.874-22.el7.x86_64

[root@rg13-test-control001 ~]# rpm -qa | grep iscsi
iscsi-initiator-utils-6.2.0.874-22.el7_9.x86_64
iscsi-initiator-utils-iscsiuio-6.2.0.874-22.el7_9.x86_64
[root@rg13-test-control001 ~]#

后续会继续更新该问题。