6.5. 使用 GFS2 锁定转储对 GFS2 性能进行故障排除
如果由于使用 GFS2 缓存而导致集群性能增加，您可能会看到大量和增长的 I/O 等待时间。您可以使用 GFS2 的锁定转储信息来确定问题的原因。
GFS2 锁定转储信息可以从 debugfs 文件中收集，该文件可在以下路径名称中找到，假设 debugfs 被挂载到 /sys/kernel/debug/ 中：
/sys/kernel/debug/gfs2/fsname/glocks文件的内容是一系列行。每行以 G: 表示一个 glock，下面一行使用单个空格缩进，代表在文件中立即与 glock 相关的信息项目。
使用 debugfs 文件的最佳方法是，在应用程序遇到问题时，使用 cat 命令获取文件内容副本（如果您有大量 RAM 和大量缓存的内节点，可能需要很长时间），然后在以后查看得到的数据。
为 debugfs 文件创建两个副本会很有用，一次需要几秒钟甚至一两分钟。通过比较与同一 glock 号相关的两个 trace 的拥有者信息，您可以告诉工作负载是否进行进度（只是缓慢）或者它是否被卡住（始终是一个程序错误，应该立即报告给红帽支持）。
debugfs 文件中的行以 H:（拥有者）代表赋予或等待被授予的锁定请求。拥有者行 f 中的 flags 字段显示：'W' 标志指的是等待的请求，"H"标记指的是授予的请求。有大量等待请求的 glock 可能是遇到特定争用的请求。
下表显示了 glock 标记和 glock 拥有者标记的含义。
| 标志 | 名称 | 含义 |
|---|---|---|
| b | Blocking | 在设置 locked 标记时有效，并指示从 DLM 请求的操作可能会被阻断。对于演示操作和"try"锁定，这个标记会被清除。这个标志的目的是允许收集 DLM 响应时间的统计数据，与其他节点与降级锁无关。 |
| d | Pending demote | 推迟（远程）降级请求 |
| D | Demote | 降级请求（本地或者远程） |
| f | Log flush | 释放这个 glock 前需要提交该日志 |
| F | Frozen | 回复忽略的远程节点 -- 恢复正在进行。这个标志与文件系统冻结无关，它使用不同的机制，但仅在恢复中使用。 |
| i | Invalidate in progress | 这个 glock 下无效页面的进程中 |
| I | Initial | 设定何时将 DLM 锁定与这个 glock 关联 |
| l | Locked | 这个 glock 处于更改状态中 |
| L | LRU | glock 出现在 LRU 列表中时设置 |
| o | Object | 设置 glock 何时与对象关联（即类型为 2 glocks 的内节点，以及类型为 3 的 glock 的资源组） |
| p | Demote in progress | glock 正在响应降级请求 |
| q | Queued | 设定当拥有者排队到 glock 时，并在 glock 保留时清除，但没有剩余所有者。作为算法的一部分使用，计算 glock 的最小保留时间。 |
| r | Reply pending | 从远程节点接收的回复正在等待过程中 |
| y | Dirty | 释放这个 glock 前需要冲刷到磁盘中的数据 |
| 标志 | 名称 | 含义 |
|---|---|---|
| a | Async | 不要等待 glock 结果（以后轮询结果） |
| A | Any | 接受任意兼容锁定模式 |
| c | No cache | 取消锁定时，立即降级 DLM 锁定 |
| e | No expire | 忽略随后的锁定取消请求 |
| E | exact | 必须有准确的锁定模式 |
| F | First | 设定赋予这个锁定的第一个拥有者 |
| H | Holder | 表示赋予请求的锁定 |
| p | Priority | 在队列头启用 ENQUEUE 拥有者 |
| t | Try | "try" 锁定 |
| T | Try 1CB | 发送回调的 "try" 锁定 |
| W | Wait | 等待请求完成的设置 |
在确定会导致问题的 glock 后，下一步就是找出它所相关的内节点。glock 号 (n: on the G: line) 表示这个值。它是格式 type/number，如果 type 为 2，则 glock 是一个内节点 glock，number 是一个内节点号。要跟踪内节点，运行 find -inum number，其中 number 是从 glocks 文件中的十六进制格式转换为十进制格式的索引节点编号。
如果您在有锁定冲突的文件系统中运行 find 命令，可能会让问题更加严重。当您查找冲突的内节点时，最好在运行 find 命令前停止应用程序。
下表显示了不同 glock 类型的含义。
| 类型号 | 锁定类型 | 使用 |
|---|---|---|
| 1 | Trans | 事务锁定 |
| 2 | Inode | 内节点元数据和数据 |
| 3 | Rgrp | 源组群元数据 |
| 4 | Meta | 超级块 |
| 5 | Iopen | 内节点最近探测 |
| 6 | Flock |
|
| 8 | Quota | 配额操作 |
| 9 | Journal | Journal mutex |
如果识别出的 glock 是不同的类型，那么最可能是类型 3（资源组）。如果您在正常负载时看到大量进程正在等待其它 glock 类型，请向红帽支持提交报告。
如果您看到在资源组锁定中排队了大量等待的请求,，那么可能有很多原因。一个原因可能是，在文件系统中，相对于资源组有大量的节点。另一个可能的原因是，文件系统可能接近完全被使用（平均来讲，需要较长的搜索时间）可以通过添加更多存储并使用 gfs2_grow 命令来扩展文件系统来提高这种情况。
