7.3.2.2. XFS 的高级调节
更改 XFS 参数前，您需要理解为什么默认 XFS 参数会造成性能问题。这包括理解您的程序在做什么，以及该文件系统如何应对那些操作。
可观察到的性能问题可以通过一般由文件碎片或者文件系统中到资源限制造成的调整修正或者减少。处理这些问题有不同的方法，但在有些情况下修复问题需要修改程序配置，而不是修改文件系统配置。
如果您以前没有处理过这个进程，建议您咨询您到本地红帽支持工程师。
优化大量文件
XFS 引入文件系统可以拥有的文件数随机限制。通常这个限制会高到根本无法达到的高度。如果您知道默认限制无法满足未来的需要，您可以使用 mkfs.xfs 命令增加可使用的内节点文件系统空间的百分比。如果您在创建文件系统后达到文件限制（通常在尝试创建文件或者目录时出现 ENOSPC 错误信息，即使有可用空间），您可以使用 xfs_growfs 命令调整该限制。
最单一目录中优化大量文件
文件系统的目录块是固定的，且无法更改，除非最初使用 mkfs 格式化。最小目录块时文件系统块大小，默认为 MAX（4 KB，文件系统块大小）。通常没有理由减少目录块大小。
因为该目录结构是基于 b-tree，更改块大小影响每个物理 I/O 可检索或者修改的命令信息量。目录越大，在给定块大小的每个操作需要的 I/O 就更多。
但当使用较大的目录块时，相比使用较小目录块到文件系统，同样的修改操作可能要消耗更多的 CPU。就是说相比小目录，大目录块的修改性能较差。当目录达到 I/O 的性能-限制因数，大块目录性能更佳。
默认配置的 4 KB 文件系统块大小和 4 KB 目录块大小是最多有 1-2 百万条目，每个条目名称最 20-40 字节之间到目录到最佳选择。如果您的文件系统需要更多条目，更大的目录块以便有更佳性能，则 16 KB 块大小时有 1-10 百万目录条目文件系统的最佳选择，64 KB 块大小是超过 1 千万目录条目到文件系统的最佳选择。
如果负载使用随机目录查询而不是修改（即目录读取比目录写入更常用或者重要），那么以上增加块大小的幅度就要减少一个数量级。
并行优化
与其他文件系统不同，XFS 可以最非共享对象中同时执行很多种类的分配和取消分配操作。扩展的分配或者取消分配可同时进行，即可在不同的分配组中同时进行。同样，内节点的分配和取消分配也可以同时进行，即同时进行的操作影响不同的分配组。
使用有多个 CPU 的机器以及多线程程序尝试同时执行操作时分配组的数量就变得很重要。如果只有 4 个分配组，那么可持续的、平行元数据操作将只限于那四个 CPU（该系统提供的并发性限制）。对小文件系统，请确保该系统提供的并发性支持分配组的数量。对于大文件系统（10TB 以上），默认格式化选项通常可生成足够多的分配组以避免限制并发性。
应用程序必须意识到限制点以便使用 XFS 文件系统结构中固有的并行性。不可能同时进行修改，因此创建和删除大量文件的应用程序应避免最一个目录中保存所有文件。应将每个创建的目录放在不同的分配组，这样类似哈希文件的计数就可以最多个子目录中提供比使用单一大目录更灵活的存储形式。
使用扩展的属性优化程序
如果内节点中有可用空间，则 XFS 可以直接在内节点中保存小属性。如果该属性符合该内节点的要求，那么可以最不需要额外 I/O 检索独立属性块的情况下检索并修改它。内嵌属性和外部属性之间的性能差异可以简单归结为外部属性的数量级要低。
对于默认的 256 字节内节点，约有 100 字节属性空间可用，具体要看也保存最内节点中的数据扩展指针数。默认内节点大小只在保存少量小属性时有用。
在执行 mkfs 时增加内节点的大小可以增大用来保存内嵌属性的可用空间量。512 字节的内节点约可增加用于保存属性的空间 350 字节，2 KB 的内节点约有 1900 字节的空间可用。
但对于每个独立可以保存到内嵌书香则有一个大小限制：即属性名称和值占用空间最多为 254 字节（即如果属性的名称长度和值长度都在 254 字节以内则为内嵌属性）。超过这个限制则会将属性强制保存为外部属性，即使在该内节点中有足够到空间保存所有属性。
持续元数据修改优化
日志的大小时决定可持续元数据修改等级的主要因素。日志设备是循环使用的，因此最可以覆盖 tail 命令的结果钱，必须将日志中的所有修改写入磁盘的实际位置中。这可能会涉及大量寻求写入所有脏元数据的操作。默认配置会让日志大小与文件系统总体大小成比例，因此在大多数情况下不需要调整日志大小。
小日志设备可导致非常频繁的元数据写回操作，即日志会一直从结尾写入以便释放空间，会经常将如此频繁修改的元数据写入磁盘，导致操作变缓。
增加日志大小会增加从结尾处 push 事件的间隔。这样可以更好地聚合脏元数据，形成更好的元数据写回模式，减少频繁修改的元数据的写回。代价是较大的日志需要更多内存方可跟踪所有内存中突出的修改。
如果您的机器内存有限，大日志就没有好处，因为内存限制可导致元数据写回延长抵消了释放大日志带来的好处。在这些情况下，通常较小的日志比较大的日志性能更好，因为缺少空间的日志元数据写回比内存重新回收形成的写回更有效。
您应该永远都保持将日志与包含该文件系统的设备底层条单位同步。
mkfs 命令可自动为 MD 或者 DM 设备完成此功能，但如果是硬件 RAID 则需要手动指定。设定这个功能目前可以避免在磁盘写入修改时所有可能的由于未同步 I/O 以及后续读取-修改-写入操作造成的日志 I/O。
通过编辑挂载选项可进一步提高日志操作性能。增大内存嵌入的日志缓存（
logbsize）的大小可增加写入日志的更改速度。默认日志缓存大小为 MAX（32 KB，日志条单元），且最高可达 256 KB。通常该数值越大性能越快。但如果是在 fsync 负载较重的环境中，小日志缓存比使用大条单元的大缓存速度明显快很多。
delaylog 挂载选项也可以改进不变的元数据修改性能，方法是减少日志更改次数。它通过在将其写入日志前整合每个内存更改：频繁修改的元数据是阶段性写入日志，而不是每次修改时都写入。这个选项增加了跟踪脏元数据的内存用量，同时也增加了崩溃发生时可能损失的操作量，但可以将元数据修改速度和延展性提高一个等级。使用这个选项不会在使用 fsync, fdatasync 或者 sync 时减少数据或者元数据完整性，从而保证可以将数据和元数据写入磁盘。
