怪物猎人世界烂辉龙顶级武器属性介绍 _k73电玩之家
当前位置： /
怪物猎人世界烂辉龙顶级武器属性介绍
时间: 17:25:25 来源: 作者: 热度: 32 次
全新的3.0版本上线后，《怪物猎人世界》中的最强武器的名号就被烂辉龙系列夺走。不过比较蛋疼的是，烂辉龙武器是随机掉落的，武器的等级层次不齐，所以还得看脸。那么烂辉龙顶级武器有多强呢?下面就为大家带来“”分享的《怪物猎人世界》烂辉龙顶级武器属性介绍。
全新的3.0版本上线后，《怪物猎人世界》中的最强武器的名号就被烂辉龙系列夺走。不过比较蛋疼的是，烂辉龙武器是随机掉落的，武器的等级层次不齐，所以还得看脸。那么烂辉龙顶级武器有多强呢?下面就为大家带来&&分享的《怪物猎人世界》烂辉龙顶级武器属性介绍。
这次更新的武器并不是属性随机，而是有一个新的武器池，池子里的武器是固定的。
具体的池子里的武器就是基于每一种武器的各种衍生，增加一系列新武器。
每一种衍生会有不同稀有度其中[铠罗]前缀的为最高稀有度，[金色的xx]前缀的武器在绝大多数情况下都是完全下位。
部分特殊情况下，有些武器相较于面板更看重客制次数，比如纯炮铳枪，所以还是酌情选择。
初步做了下整理，其实基本已经能看出规律了。
名字带&?&的来源为非中文图片，具体武器名字不明。
弩枪考虑到弹种、反动、装填、这里不收录。
怪物猎人世界烂辉龙顶级武器属性介绍
铠罗炎 睡眠
铠罗炎 尸套
铠罗炎 熔岩
铠罗炎 毒妖
铠罗炎 熔山
铠罗炎 骨锤
铠罗炎 凶豺？
铠罗剑 麻痹
铠罗剑 风飘
铠罗剑 熔山
铠罗剑 黑甲
铠罗剑 飞雷
铠罗剑 蛮颚
铠罗切刀 龙
铠罗切刀 水
铠罗切刀 爆破
铠罗切刀 土砂
铠罗小刀 毒
铠罗小刀 冰
铠罗小刀 水
铠罗小刀 泥鱼
铠罗小刀 角
铠罗大锤 雷
铠罗大锤 水
铠罗大锤 冰
铠罗大锤 搔
铠罗大锤 土砂
铠罗大锤 尸套
铠罗大锤 痹贼
铠罗炎 骨锤？
铠罗风笛 龙
铠罗风笛 水
铠罗风笛 麻痹
铠罗风笛 岩贼
铠罗风笛 幻
铠罗风笛 骨笛
铠罗风笛 蛮颚
铠罗之尖 水
铠罗之尖 睡眠
铠罗之尖 雷
铠罗之尖 土砂
铠罗之尖 风飘
铠罗之尖 惨爪
铠罗长刀 冰
铠罗长刀 水
铠罗长刀 麻痹
铠罗铳枪 睡眠
铠罗铳枪 毒
铠罗铳枪 水
铠罗铳枪 贼
铠罗铳枪 王
铠罗铳枪 土砂
铠罗剑斧 麻痹
铠罗剑斧 睡眠
铠罗剑斧 雷
铠罗剑斧 爆鳞
铠罗剑斧 角
铠罗剑斧 贼
铠罗兵装 雷
铠罗兵装 睡眠
铠罗兵装 冰
铠罗兵装 惨爪
铠罗兵装 泥鱼
铠罗兵装 角
铠罗兵装 冰
铠罗兵装 王
铠罗弓 爆破
铠罗弓 尸套
铠罗弓 飞雷
铠罗弓 女王
←扫一扫关注“k73手游”
游戏、动画、漫画，ACG的圈内圈外事
公众号查询：k73手游 轻松订阅 &&
官方QQ群1： 官方QQ群2：
游戏平台：
游戏类型：动作沙盒开放
游戏版本：日版美版中文版
游戏标签：
玩家评分：45
k73评分：47
版权所有 鄂ICP备号
k73所有游戏及软件下载资源均来源自互联网，并由网友上传分享。如有侵权，请来电来函告之。
K73电玩之家Single-page HTML
性能调节指南
红帽企业版 Linux 7在红帽企业版 Linux 7 中优化子系统吞吐量
作者：罗拉?贝莉 － Laura Bailey红帽 工程部出版中心翻译、校对：付莹莹 － Yingying (Angelina) Fu澳大利亚昆士兰大学 笔译暨口译研究所翻译、校对：龚心星 － Xinxing Gong澳大利亚昆士兰大学 笔译暨口译研究所校对、编辑：任浩 － Hao (Naomi) Ren澳大利亚昆士兰大学 笔译暨口译研究所校对、责任编辑：鄭中 － Chester Cheng红帽工程部翻译中心 ＆ 澳大利亚昆士兰大学笔译暨口译研究所摘要
红帽企业版 Linux 7 《性能调节指南》 阐述了优化红帽企业版 Linux 7 性能的方法，收录了红帽企业版 Linux 7 的性能升级。
《 性能调节指南 》仅陈述现场试验过和经过证实的程序。尽管如此，在所有可能的配置应用到产品系统之前，都应在测试环境下进行设置和测试，也建议在调节之前备份所有的数据和配置设定。
第 1 章 红帽企业版 Linux 7 的性能特性
红帽企业版 Linux 7 中与性能有关的变更的简要概述，请阅读本章节。
1.1. 7.0版本中的新变化
此指南是为红帽企业版 Linux 7 而完全重新撰写和架构的。
红帽企业版 Linux 7 中 deadline 作为默认的 I/O 调度器替代了 cfq。这个变更为大多数的用例提供更好的性能表现。
XFS 文件系统替代 ext4 成为默认的文件系统，并且现在支持最大容量可达 500 TB 的文件系统，及最大容量可达 8 EB（稀疏文件）的文件偏移。为协助清晰度，更新了 XFS 的调整推荐。
Ext4 文件系统现在支持最大容量为 50 TB 的文件系统和最大可达 16 TB 的文件。调整推荐也做了相应的更新。此外，ext4 的驱动提供对 ext2 和 ext3 文件系统的支持。
现在提供作为技术预览的 Btrfs 文件系统。
红帽企业版 Linux 7 包括一些为 GFS2 的细微的性能提升。
为了提供对配置文件和添加/保存 tuned 配置文件的支持，更新了 Tuna。为了消耗更少的处理器资源，这个更新版使用基于事件的采样。为了允许实时监控，图形化版本也同样进行了更新。Tuna的文档参见：〈〉，〈〉和〈 〉。
tuned 默认配置文件更新为 throughput-performance。它替代了现在被移除的
enterprise-storage 配置文件。为了网络化和虚拟化，添加了一些新的配置文件。此外，tuned 现在提供外壳脚本标注和 includes 功能。
tuned-adm 工具现在提供 recommend 子命令，它为您的系统推荐适当的调整配置文件。它同时为您的系统在安装时设置默认的配置文件，因此可用于恢复默认配置。
红帽企业版 Linux 7 提供对自动 NUMA 平衡的支持。系统内核自动探测主动使用的内存页进程线程，并且将这些线程和它们的内存进行 NUMA 节点内或跨节点的分组。系统内核重新调度线程并迁移内存，从而为最佳 NUMA 对齐方式和性能平衡系统。
启用文件系统 barrier（屏障）的性能惩罚现在是可忽略的（少于3%）。因此， tuned 配置文件不会禁用文件系统 barrier。
使用新的 operf 工具，OProfile 增加了对基于 Linux 性能事件子系统配置文件的支持。这个新工具能替代 opcontrol 后台程序用于收集数据。
控制组作为一种分配资源到您系统中的某些进程组的方法仍然可用。红帽企业版 Linux 7 的实现的具体信息请参见《红帽企业版 Linux 7 资源管理指南》，可在下列网站中查找 。
第 2 章 性能监控工具
本章简要说明了一些红帽企业版 Linux 7 可用的性能监控和配置工具。在可能的情况下，本章会进一步指导用户使用该工具并举例说明可以使用该工具来解决的实际问题。
以下知识库文章提供适用于红帽企业版 Linux 的更为全面的性能监控工具列表：。
2.1. /proc
/proc “文件系统”是一个目录，其中包含的文件层次结构代表了 Linux 内核的当前状态。它允许用户和管理员查看系统的内核视图。
/proc 目录中还包含关于系统硬件及任何当前正在运行的程序信息。大部分在 /proc 中的文件是只读文件，但一些文件（主要是 /proc/sys 文件）能够被用户和应用程序操作，以便向内核传达配置的修改信息。
关于查看及编辑 /proc 目录中文件的更多信息，请参见红帽企业版 Linux 7 系统管理员参考指南，可从
2.2. GNOME 系统监控器
GNOME 桌面系统包含一个图形工具，即系统监控器来协助用户监控及修改系统性能。系统监控器显示基本的系统信息并能让用户监控系统进程，以及资源或文件系统的用量。
系统监控器有四个选项卡，每个都显示不同的系统信息。
此选项卡显示关于系统硬件和软件的基本信息。
此选项卡显示关于活动进程和进程间相互关系的具体信息。显示的进程可进行筛选，以便更容易找到某些特定的进程。
此选项卡显示目前 CPU 的时间使用量，内存和交换空间用量以及网络使用情况。
此选项卡列举了所有安装的文件系统，并提供每个的基本信息，例如文件系统类型、安装点和内存使用情况。
要启动系统监控器，按超级键进入活动概览，输入 “System Monitor” ，然后按回车键。
关于系统监控器的更多信息，参见应用程序中的帮助菜单，或红帽企业版 Linux 7 《System Administrator's Guide》，可从
红帽企业版 Linux 7 引入了对 PCP（性能协驾）的支持，PCP 是一套工具、服务及程序库，用于获取、存储及分析系统级的性能测量值。其轻量级分布式体系结构尤其适合复杂系统的集中化分析。可以使用 Python，Perl，C++ 和 C 接口来添加性能指标。分析工具可以直接使用客户 API （应用编程接口）（Python, C++, C），而且丰富的网页应用程序可以通过一个 JSON 接口来搜索所有可用的性能数据。
pcp 数据包提供命令行工具及底层功能。图形工具也需要 pcp-gui 数据包。
关于 PCP，详情请见 。此外，pcp-doc 数据包提供全面的文档，默认安装于 /usr/share/doc/pcp-doc。PCP 也提供每个工具的手册页，在命令行输入 man toolname 来查看该工具的手册页。
Tuna 调试配置细节，如调度器策略、线程优先级以及 CPU 和中断关联。tuna 数据包提供了命令行工具和有同样功能的图形界面。
说明了使用 Tuna 在命令行配置系统的方法。关于使用 Tuna 的方法，请见
或手册页：
$ man tuna2.5. 内置命令行工具
红帽企业版 Linux 7 提供大量工具来从命令行监控用户系统，使用户可在运行级 5 外监控系统。本章会简要论述每个工具，并提供更多关于在何处使用及如何使用这些工具的链接。
2.5.1. top
top 工具由 procps-ng 数据包提供，提供运行系统中进程的动态视图。它能显示多种信息，包括系统摘要和当前由 Linux 内核管理的任务列表。它也具有有限的控制流程的能力，并且在系统重启时永久保存配置更改。
默认情况下，显示的进程会根据 CPU 使用率比例来调整，以便容易地看出消耗最多资源的进程。显示的信息及操作都是高度可配置型的，这使用户可以专注于所需的不同用量的统计数据。
关于使用 top 工具的更多信息，请见手册页：
$ man top2.5.2. ps
ps 工具由 procps-ng 数据包提供，提供选定的一组运行进程快照。默认情况下，检测过的组别受限于当前用户所占有的进程，并与运行 ps 的终端相关联。
较之于 top 工具，ps 可以提供更多关于进程的信息，但默认情况下提供的是这一数据的单一快照，并通过进程标识符来调整。
关于使用 ps 工具的更多信息，请见手册页：
$ man ps2.5.3. vmstst
虚拟内存统计数据工具，即 vmstat，提供关于系统进程、内存、分页、输入/输出、中断和 CPU 活动的即时报告。vmstat 让用户设置一组采样间隔以接近实时地观察系统活动。
vmstat 由 procps-ng 数据包提供。关于使用 vmstat 的更多信息，请见手册页：
$ man vmstat2.5.4. sar
系统活动报告，即 sar，收集及报告系统当天到目前为止发生的活动信息。默认的输出以十分钟为间隔，显示当天 CPU 的使用情况（自系统时间00:00:00 始）。
用户也可以使用 -i 选项来以秒为单位设置间隔时间，例如，sar -i 60 意味着 sar 每一分钟检查一次 CPU 使用率。
sar 是通过 top 工具来手动创建系统活动定期报告的一种有效方法。由 sysstat 数据包提供。关于使用 sar 的更多信息，请见手册页：
$ man sar2.6. tuned 和 tuned-adm
tuned 是一种后台调节程序，可通过设置调节配置文件使操作系统在特定工作负载下发挥更好的性能。tuned-adm 是一个命令行工具，允许用户在不同调节配置文件中进行切换。
常见用例包含一些预定义文件，但是 tuned-adm 允许用户自定义配置文件，既可以是预定义文件中的一个，也可以从头定义。在红帽企业版 Linux 7 中，默认文件是 throughput-performance。
tuned-adm 提供的文件分为两类：节能文件和性能提升文件。性能提升文件的内容如下，其侧重点分别为：
存储和网络的低延迟
存储和网络的高吞吐量
虚拟计算机性能
虚拟主机性能
启用 tuned 的方法，请见 。
tuned-adm 提供的性能提升文件，请见 。
tuned-adm 提供的节能文件，请见红帽企业版 Linux 7 电源管理指南，可从
关于 tuned 和 tuned-adm 的使用详情，请参见其各自的手册页：
$ man tuned$ man tuned-adm2.7. perf
perf 工具通过使用硬件性能计数器和内核跟踪程序来追踪其他命令和应用程序对系统的影响。不同 perf 子命令显示并记录常见性能活动的统计数据，并对数据进行分析和报告。
关于 perf 及其子命令，详情请见 。
此外，欲了解更多信息，请参见红帽企业版 Linux 7 《Developer Guide》，可从
2.8. turbostat
turbostat 由 kernel-tools 数据包提供。是对 Intel(R) 64 位处理器中处理器的拓扑、频率、空闲的电源状态统计、温度和用电量的报告。
turbostat 有助于识别服务器的用电量或空闲时间低效问题，也有助于识别系统的管理中断率 （SMI），并能验证电源管理调节的效果。
turbostat 需要 root 特权来运行，也需要处理器支持以下需求：
不变的时间戳计数器
APERF 特定模型寄存器
MPERF 模型特定寄存器
turbostat 的输出及读取方法，详情请见 。
关于 turbostat 的更多信息，请见手册页：
$ man turbostat2.9. iostat
iostat 工具由 sysstat 数据包提供。它对系统输入/输出设备负载进行监控和报告，以协助管理员就如何在物理磁盘间输入/输出负载做出决定。它是对处理器或设备自 iostat 上次运行或启动的使用率的报告。用户可以通过使用在 iostat 手册页中定义的参数来在特定设备上关注这些报告的输出：
$ man iostat2.10. irqbalance
irqbalance 是一个通过分配处理器硬件中断以提高系统性能的命令行工具。irqbalance 详情，请见
或手册页：
$ man irqbalance2.11. ss
ss 是一个命令行实用程序，显示 socket 的统计信息，使管理员能够根据时间来评估设备性能。ss 默认打开已建立连接但未在列表内的 TCP socket，也提供很多有用选项来协助管理员筛选出特定 socket 的统计数据。
红帽推荐在红帽企业版 Linux 7 中使用 ss 代替 netstat。
一个常见的用法是 ss -tmpie，它显示（包括内核信息在内）关于 TCP socket、内存使用率和使用 socket 进程的详细信息。
ss 由 iproute 数据包提供。更多信息请见手册页：
$ man ss2.12. numastat
numastat 工具以每一个 NUMA 节点为基础了，显示处理器和操作系统的内存统计数据。
默认情况下，numastat 显示每个节点的 NUMA 从内核的内存分配器中缺失的系统统计数据。最佳性能表现为高 numa_hit 值和低 numa_miss 值。Numastat 也提供很多命令行选项来说明系统和进程的内存如何通过系统中 NUMA 节点进行分配。
交叉引用每个节点的 numastat 输出和每个 CPU 的 top 输出是很有用的，可以用来验证进程线程是在内存分配的同一节点上运行。
Numastat 由 numactl 数据包提供。关于使用 numastat 的方法，详情请见 。关于 numastat 的更多信息，请见手册页：
$ man numastat2.13. numad
numad 是一个自动的 NUMA 关联管理后台程序。它监控系统的 NUMA 拓扑和资源使用率，目的是为了动态地提高 NUMA 的资源分配和管理（从而提高系统性能）。numad 可以根据系统的工作负载来为性能基准提供高达 50% 的改善。它还提供预先安置咨询服务，可以通过多种工作关联系统进行查询，以此为最初绑定的 CPU 和内存资源的进程提供协助。
numad 以一个节点为基础，通过定期访问 /proc 文件系统中的信息来监控可用的系统资源。它能尝试将资源使用率保持在一个特定的等级，并在必要时通过移动 NUMA 节点间的进程来调整资源分配。numad 可以试图通过本地化和隔离系统中 NUMA 节点子集的重要进程来获得 NUMA 的最佳性能。
numad 主要对长时间运行程序的系统有用，这些程序消耗大量的资源并包含在总系统资源中的一个子集里。它也对消耗多个 NUMA 节点资源值的应用程序有用，但当系统资源消耗比例增加时，numad 的优势会减小。
当程序只运行几分钟或不消耗太多资源时，numad 不大可能会提高性能。拥有连续且不可预测的内存访问模式的系统，如大内存数据库，也不大可能受益于 numad。
关于使用 numad 的更多信息，请见
或参见手册页：
$ man numad2.14. SystemTap
SystemTap 是一个跟踪和探测工具，使用户可以详尽地监控和分析操作系统的活动，尤其是内核活动。它提供的信息类似于 top、ps、netstat 和 iostat 工具的输出，但包括筛选和分析所收集数据的额外选项。
SystemTap 提供对系统活动和应用程序性能更为深入且更为准确的分析，使用户能够精确地找到系统和应用程序的瓶颈。
关于 SystemTap 的更多信息，请见红帽企业版 Linux 7 《SystemTap Beginner's Guide》 和红帽企业版 Linux 7 《SystemTap TapSet Reference》。两本书都可从
2.15. OProfile
OProfile 是一个全系统性能监控工具。它使用处理器的专业性能监控硬件来检索关于内核和系统可执行文件的信息，以便确定某些事件的频率，比如引用内存时，就接收第二级缓存请求数和硬件请求数。OProfile 也可用于确定处理器的使用率，并确定最常使用的应用程序和服务。
但 OProfile 有一些局限性：
性能监控样本可能不太准确。由于处理器可能无法执行指令，样本就会记录一个附近的指令，而不是记录触发中断的指令。
OProfile 希望程序多次启动和停止。这样的话多次运行得到的样本就可以累积，用户可能需要清除上一次运行的样本数据。
OProfile 集中识别 CPU 访问限制的进程问题。因此，对于等待锁定其他事件来识别睡眠状态的进程并无帮助。
关于 OProfile 的更多信息，请见
或 Red Hat Enterprise Linux 7 System Administrator's Guide，可从
中获取。此外还可参见系统中位于 /usr/share/doc/oprofile-version 的文档。
2.16. Valgrind
Valgrind 提供大量的检测及分析工具以帮助提高应用程序的性能。这些工具能检测内存和与线程相关的错误，同样也能检测堆、栈和数组的超限运行，使用户能够轻松地定位和修改应用程序代码错误。它也可以配置缓存、堆和分支预测来确定能增加应用程序速度并最小化内存使用率的因素。
Valgrind 通过在合成的 CPU 上运行应用程序来进行分析，并在执行时对现有的应用程序代码进行测试。之后显示的评论会清楚地标识出每个参与应用程序执行的进程至用户指定文件、文件描述符或网络 socket。要注意的是执行测试代码会花上正常执行情况下四至五十倍的时间。
Valgrind 可以按原样应用于应用程序，不需要进行重新编制。但由于 Valgrind 使用调试信息来定位编码中的问题，若应用程序和支持库没有启用调试信息编制，红帽建议进行程序编制以便能包含该信息。
Valgrind 也与 GNU 项目调试器 （gdb）一起使用来提高调试效率。
Valgrind 及其附属工具有助于内存分析。关于使用 Valgrind 分析系统内存，详情请见 。
关于 Valgrind，详情请见红帽企业版 Linux 7 开发者指南，可从
关于使用 Valgrind，详情请见手册页：
$ man valgrind
当 valgrind 数据包安装后，附带文档可以在 /usr/share/doc/valgrind-version 中找到。
第 3 章 CPU
本章对红帽企业版 Linux 7 中会影响应用性能的 CPU（中央处理器）硬件细节及配置选择进行了概述。＜ ＞详述了与 CPU 相关的会影响性能的因素。 ＜ ＞教您如何使用红帽企业版 Linux 7 的工具来诊断与 CPU 硬件或配置细节相关的性能问题。＜ ＞ 详述了可用以解决在红帽企业版 Linux 7 中与 CPU 相关的性能问题的工具和策略。
阅读本章来了解以下因素是如何影响系统和应用程序性能的。
处理器如何互相连接，并且如何连接到相关资源，如内存。
处理器如何为执行操作调度线程。
处理器如何处理红帽企业版 Linux 7 中的间断。
在现代计算机技术中，一个＂中央＂处理单元的观念是误导性的，因为大部分现代化的系统都有多个处理器。这些处理器是如何相互连接，并且如何连接至其他系统资源 —＂系统拓扑＂— 会对系统和应用程序的性能以及系统调节选项产生巨大的影响。
现代计算机技术主要运用两种主要的拓扑类型
SMP（对称多处理器）拓扑允许所有的处理器同时访问内存。然而，由于内存访问权限的共享性和平等性，固然会迫使所有 CPU 及 SMP 系统序列化的内存访问权限的局限性增加，目前这种情况常不被接受。因此，几乎所有现代服务器系统都是 NUMA（非一致性内存访问）机器。
比起 SMP 拓扑，NUMA（非一致性内存访问）拓扑是近来才开发的。在 NUMA 系统中，多个处理器物理分组至一个 socket。每个 socket 都有一个专用内存区，对该内存进行本地访问的服务器统称为一个节点。
同一个节点上的服务器能高速访问该节点的存储体，但访问其他节点上的存储体速度就较慢。因此，访问非本地存储体会造成性能的损失。
考虑到性能损失，服务器执行应用程序时，NUMA 拓扑结构系统中对性能敏感的应用程序应访问同一节点的内存，并且应尽可能地避免访问任何远程内存。
因此，在调节 NUMA 拓扑结构系统中的应用程序性能时，重要的是要考虑这一应用程序的执行点以及最靠近此执行点的存储体。
在 NUMA 拓扑结构系统中，/sys 文件系统包含处理器、内存及外围设备的连接信息。/sys/devices/system/cpu 目录包含处理器在系统中相互连接的详情。 /sys/devices/system/node 目录包含系统中 NUMA 的节点信息以及节点间的相对距离。
3.1.1.1. 确定系统拓扑结构
很多指令能帮助用户了解系统的拓扑结构。numactl --hardware 指令概述了系统的拓扑结构。
$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 4 8 12 16 20 24 28 32 36
node 0 size: 65415 MB
node 0 free: 43971 MB
node 1 cpus: 2 6 10 14 18 22 26 30 34 38
node 1 size: 65536 MB
node 1 free: 44321 MB
node 2 cpus: 1 5 9 13 17 21 25 29 33 37
node 2 size: 65536 MB
node 2 free: 44304 MB
node 3 cpus: 3 7 11 15 19 23 27 31 35 39
node 3 size: 65536 MB
node 3 free: 44329 MB
node distances:
lscpu 指令由 util-linux 数据包提供，包括 CPU 体系结构信息，如 CPU 数量、线程数、内核数、 socket 数量以及 NUMA 节点数等。
Architecture:
CPU op-mode(s):
32-bit, 64-bit
Byte Order:
Little Endian
On-line CPU(s) list:
Thread(s) per core:
Core(s) per socket:
Socket(s):
NUMA node(s):
Vendor ID:
GenuineIntel
CPU family:
Model name:
Intel(R) Xeon(R) CPU E7- 4870
Virtualization:
L1d cache:
L1i cache:
NUMA node0 CPU(s):
0,4,8,12,16,20,24,28,32,36
NUMA node1 CPU(s):
2,6,10,14,18,22,26,30,34,38
NUMA node2 CPU(s):
1,5,9,13,17,21,25,29,33,37
NUMA node3 CPU(s):
3,7,11,15,19,23,27,31,35,39
lstopo 指令由 hwloc 数据包提供，创建了用户的系统示意图。lstopo-no-graphics 指令提供详尽的文本输出。
lstpo 指令的输出
在红帽企业版 Linux 中，执行进程的最小单元叫做一个 “线程”。系统调度器决定运行线程的处理器和运行的时间。但由于调度器主要关注的是保持系统繁忙，因此可能不会为应用程序的性能而对线程进行最佳调度。
例如，在 NUMA 系统中，一个处理器在节点 B 可用，一个应用程序在节点 A 运行，要使在节点 B 的处理器保持忙碌， 调度器会把应用程序的一个线程转移到节点 B。但是，线程上的应用程序仍然需要访问在节点 A 的内存。由于该线程目前在节点 B 运行，并且对于此线程来说节点 A 的内存已不再是本地内存，访问起来就要花更长的时间。较于在节点 A 等待可用的处理器，并且在能够进行本地内存访问的源节点上执行线程，此线程在节点 B 结束运行可能就更加费时。
设计器或管理员确定线程的运行位置能使对性能敏感的应用程序从中受益。如何保证适当地调度线程，以满足对性能敏感的应用程序的需要，详情请参见 ＜＞。
3.1.2.1. 内核滴答信号
在早期红帽企业版 Linux 版本中，Linux 内核会定期中断每个 CPU 以查看需要完成的任务。查看的结果用来决定进程调度及负载均衡。这种常规性的中断叫做一个内核 “滴答信号”。
此标记的出现不考虑内核是否有任务要执行。这意味着为了回应这些中断，即使是空闲的内核也会被迫定期进入高能状态（每秒高达1000次）。这阻止了系统有效地利用新近 x 86 代处理器的深睡眠状态。
在红帽企业版 Linux 6 和 7 中，默认情况下内核不再中断趋于低功率状态的空闲 CPU，这种性能叫做无时钟内核。当一个或几个任务在运行时，按需中断取代了定时中断，使 CPU 可以更久地处于空闲或低功率状态，减少了电量的消耗。
红帽企业版 Linux 7 提供一种动态的无时钟设置（ nohz_full ），通过用户空间的任务来减少内核干扰以进一步改善其确定性。这一设置可以在指定的内核中通过 nohz_full 内核参数来启用。当这一设置在一个内核中启用时，所有的计时活动将会被移动至无延迟敏感性的内核。这对于高性能计算和实时计算工作负载来说都很有用，因为其用户空间任务对由于内核计时器滴答信号造成的微秒级的延迟尤为敏感。
启用红帽企业版 Linux 7 中动态无时钟性能的方法，请见＜ ＞。
中断请求或 IRQ 是请求及时关注的信号，是从硬件发送至处理器的。系统中的每个设备都分配到一个或多个 IRQ 号，以便能发送独一的中断信号。当启用中断时，收到中断请求的处理器会立即暂停执行当前应用程序线程，这是为了处理该中断请求。
因为中断了正常的运行，高中断率会严重降低系统性能，但减少中断的时间是可能的，可以设置中断关联或发送一批低优先率的中断（“组合 中断”）
关于调节中断请求的更多信息，请见＜ ＞ 或 ＜＞。针对网络中断信息，请见＜ ＞。
3.2. 监控和诊断性能问题
红帽企业版 Linux 7 提供了大量工具，这些工具对与处理器及其配置相关的系统性能监和性能问题诊断很有帮助。本章概述了可用的工具并举例说明如何使用它们来监测和诊断与处理器相关的性能问题。
3.2.1. turbostat
Turbostat 在规定的间隔中给出计时器的结果以协助管理员识别服务器异常，例如过度耗电，无法进入深睡眠状态或是创建了不必要的系统管理中断（SMIs）。
turbostat 工具是
内核工具 数据包的一部分。支持在 AMD 64 和 Intel(R) 64 处理器的系统中使用。需要 root 特权来运行，处理器支持时间戳计时器以及 APERF 和 MPERF 型号的特定寄存器。
使用实例，请参见手册页：
$ man turbostat3.2.2. numastat
该工具在红帽企业版 Linux 6 的整个使用周期中都会接收到大量更新，虽然默认的输出和 Andi Kleen 写的原始工具相兼容，但提供任何选项或参数给 numastat 都会显著地改变其输出格式。
numastat 工具会列举每个 NUMA 节点内存数据给所有的进程和操作系统，并会告知管理员进程内存是散布于系统还是集中于某个节点。
通过处理器的 top 输出进行交互参照 numastat 输出，以确认进程线程是在同一个节点运行，此节点是进程内存分配节点。
Numastat 由 numactl 数据包提供。关于 numastat 输出的更多信息，请参见手册页：
$ man numastat3.2.3. /proc/ 中断
/proc/interrupts 文件列举了从一个特殊的 I/O 设备发送至各处理器的中断数量，显示了中断请求（IRQ）数量、系统中各处理器处理该类型中断请求的数量，发送的中断类型以及以逗号分隔开的回应所列中断请求的设备列表。
如果一个特定的应用程序或是设备生成大量的中断请求给远程处理器处理，其性能就会受到影响。这种情况下，当应用程序或设备在处理中断请求时，可以在同一节点设置一个处理器，以此来缓解性能不佳的状况。将中断处理分配给特定处理器的方法，请见 ＜＞。
3.3. 配置建议
红帽企业版 Linux 提供了大量工具来协助管理员配置系统。本章概述了可用的工具并提供了使用它们在红帽企业版 Linux 7 中解决与处理器相关的性能问题的实例。
默认情况下，红帽企业版 Linux 7 使用无时钟内核，它不会中断空闲 CPU 来减少用电量，并允许较新的处理器利用深睡眠状态。
红帽企业版 Linux 7 同样提供一种动态的无时钟设置（默认禁用），这对于延迟敏感型的工作负载来说是很有帮助的，例如高性能计算或实时计算。
要启用特定内核中的动态无时钟性能，在内核命令行中用 nohz_full 参数进行设定。在 16 核的系统中，设定 nohz_full=1-15 可以在 1 到 15 内核中启用动态无时钟内核性能，并将所有的计时移动至唯一未设定的内核中（0 内核）。这种性能可以在启动时暂时启用，也可以在 /etc/default/grub 文件中永久启用。要持续此性能，请运行 grub2-mkconfig -o /boot/grub2/grub.cfg 指令来保存配置。
启用动态无时钟性能需要一些手动管理。
当系统启动时，必须手动将 rcu 线程移动至对延迟不敏感的内核，这种情况下为 0 内核。
# for i in `pgrep rcu` ; do taskset -pc 0 $ done
在内核命令行上使用 isolcpus 参数来将特定的内核与用户空间任务隔离开。
可以选择性地为辅助性内核设置内核回写式 bdi-flush 线程的 CPU 关联：
echo 1 & /sys/bus/workqueue/devices/writeback/cpumask
验证动态无时钟配置是否正常运行，执行以下命令，其中 stress 是在 CPU 中运行 1 秒的程序。
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
可替代 stress 的是一个脚本，该脚本的运行类似 while :; do d=1; done 。以下链接中的程序是另一个合适的替代程序： 。
默认的内核计时器配置在繁忙 CPU 中显示 1000 次滴答记号：
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
1000 irq_vectors:local_timer_entry
动态无时钟内核配置下，用户只会看到一次滴答记号：
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
1 irq_vectors:local_timer_entry3.3.2. 设置硬件性能策略
x86_energy_perf_policy 工具允许管理员定义性能与能效的相对重要性。当处理器在性能与能效间权衡选择时，此信息可用来改变支持这一特征的处理器。
默认情况下适用于所有在 performance 模式下的处理器，它要求处理器的支持，由 CPUID.06H.ECX.bit3 显示，且必须在有 root 特权的情况下运行。
x86_energy_perf_policy 由 kernel-tools 数据包提供。如何使用 x86_energy_perf_policy，详情请见 ＜＞ 或参见手册页：
$ man x86_energy_perf_policy3.3.3. 使用 taskset 设置处理器关联
taskset 工具由 util-linux 数据包提供。Taskset 允许管理员恢复和设置进程中的处理器关联，或通过特定的处理器关联来启动一个进程。
taskset 不能保证本地的内存配置。若需要本地内存配置的额外性能收益，红帽推荐使用 numactl 来替代 taskset。
关于 taskset 的更多信息，请见 ＜＞ 或手册页：
$ man taskset3.3.4. 使用 numaactl 管理 NUMA 关联
管理员可以通过特定的调度或内存安置策略来使用 numactl 运行进程。Numactl 也可以为共享内存片段或文件设置永久性策略，并设置处理器关联和进程的内存关联。
在 NUMA 拓扑系统中，处理器访问内存的速度会由于处理器和存储体之间距离的增加而减慢。因此，重要的是要对性能敏感的应用程序进行配置，以便它们能够从最近的且可能的存储体分配内存。最好是使用在同一 NUMA 节点的内存和 CPU。
对性能敏感的多线程应用程序经配置后在特定的 NUMA 节点上运行会比在特定的处理器上运行好处更多。这是否适合则取决于用户系统及应用程序的需求。如果多个应用程序线程访问同一缓存数据，那么对那些线程进行配置，使其在同一处理器上运行可能是合适的。但是，如果在同一处理器上运行的多线程访问及缓存的是不同数据，那么每个线程可能会收回之前线程访问的缓存数据。这就意味着每个线程会“缺失”缓存，会浪费运行时间来从磁盘中获取数据并在缓存中替代它。用户可以使用 perf 工具，收录于 ＜＞ 中，用它来查看大量的缓存缺失。
Numactl 提供大量的选择来协助管理处理器及内存关联。详情请见 ＜＞ 或手册页：
$ man numactl
numactl 数据包包括 libnuma 库。这个库提供了一个简单的编程接口至内核支持的 NUMA 策略，比起 numactl 应用程序，它可以用来进行更细致的调节。更多信息请参见手册页：
$ man numa3.3.5. 使用 numad 进行自动化 NUMA 关联管理
numad 是一种自动化的 NUMA 关联管理后台程序。它对系统中的 NUMA 拓扑及资源用量进行监控，以便动态地改善 NUMA 资源配置及管理。
numad 也同样提供预先安置咨询服务，这一服务可以通过不同的作业管理系统来查询，并为处理器 CPU 的初始绑定及内存资源提供帮助。无论 numad 是以可执行程序或服务在运行，这一预先安置咨询都可用。
使用 numad 的方法，请见 ＜＞ 或参见手册页：
$ man numad3.3.6. 调节调度策略
Linux 调度器执行大量的调度原则，以此决定线程运行的位置和时长。调度原则主要有两类：普通原则和实时原则。普通线程用于普通优先级任务，实时原则用于具有时效性且必须无中断完成的任务。
实时线程不受时间间隔的控制，这意味着它们将一直运行直至它们阻拦、退出、主动让步或是被更高优先权的线程预先安置。最低优先权的实时线程会先于其他普通原则的线程进行调度。
3.3.6.1. 调度原则3.3.6.1.1. SCHED_FIFO 静态优先级调度
SCHED_FIFO （也叫做静态优先级调度）是一项实时策略，定义了每个线程的固定优先级。这一策略让管理员能改进事件响应的时间并减少延迟，这一策略建议无法运行较长时间且具有时效性的任务使用。
在使用 SCHED_FIFO 时，调度器会按优先级顺序扫描所有的 SCHED_FIFO 线程，并对准备运行的最高优先级线程进行调度。一个 SCHED_FIFO 线程的优先级级别可以是 1 至 99 之间的任何整数，99 是最高优先级。红帽建议一开始使用较小的数字，在确定了延迟问题后再增加优先级。
由于实时线程不受时间间隔的控制，红帽不推荐设置 99 优先级。这会使同优先级的进程成为迁移线程或监控线程，如果线程进入一个计算机回路且这些线程被阻拦，它们将无法运行。这种情况下，单处理器系统最终会暂停。
管理员可以限制 SCHED_FIFO 的带宽以防止实时应用程序的程序员启用独占处理器的实时任务。
/proc/sys/kernel/sched_rt_period_us
该参数以微秒为单位来定义时间，是百分之百的处理器带宽。默认值为 1000000 μs, 或1秒。
该参数以微秒为单位来定义时间，用来运行实时线程。默认值为 950000 μs, 或0.95秒。
3.3.6.1.2. SCHED_RR 轮循优先级调度
SCHED_RR 是 SCHED_FIFO 的一个轮循变形。这一策略在同优先级的多线程需要运行时很有用。
正如 SCHED_FIFO，SCHED_RR 是一项实时策略，定义了每个线程的固定优先级。调度器会按优先级顺序扫描所有的 SCHED_RR 线程，并对准备运行的最高优先级线程进行调度。但是，和 SCHED_FIFO 不同，同优先级的线程在一定的时间间隔内是以循环的方式进行调度的。
用户可以使用 sched_rr_timeslice_ms 内核参数，并毫秒为单位设定这一时间间隔 (/proc/sys/kernel/sched_rr_timeslice_ms) 。最小值为1毫秒。
3.3.6.1.3. SCHED_OTHER 普通调度
SCHED_OTHER 是红帽企业版 Linux 7 中默认的调度策略。这一策略使用 CFS （完全公平排程器）让处理器能够平等地访问用此策略调度的所有线程。这一策略在有大量线程或数据吞吐量优先时最为有用，因为它能够随着时间而更为有效地调度线程。
在使用这一策略时，调度器会创建一个动态优先级列表，此列表一部分是基于每个进程线程的进程优先级。管理员可以改变一个进程的进程优先级，但是不能直接改变调度器的动态优先级列表。
改变进程的进程优先级，详情请见 ＜Red Hat Enterprise Linux 7 Deployment Guide＞，可从
3.3.6.2. 隔离 CPU
用户可以使用 isolcpus 开机参数来从调度器隔离一个或多个 CPU，以此防止调度器在此 CPU 上调度任何用户空间的线程。
一旦 CPU 被隔离，用户须手动分配进程至被隔离的 CPU，或使用 CPU 关联系统呼叫或 numactl 命令。
将系统中第三和第六 CPU 隔离至第八 CPU，添加如下至内核命令行：
isolcpus=2,5-7
用户也可使用 Tuna 工具来隔离CPU。Tuna 可以随时隔离 CPU，不仅仅局限于启动时。但这种隔离方法与 isolcpus 参数略有不同，并且目前尚未实现与 isolcpus 相关的性能收益。关于此工具的详情，请参见 ＜＞。
3.3.7. 设置中断关联
中断请求有一个相关的关联属性smp_affinity， 它能确定处理中断请求的处理器。若要提高应用程序的性能，就将中断关联和进程关联分配至同一处理器或分配至同一内核的处理器。这可以使特定的中断和应用程序线程共享高速缓存线路。
特定中断请求的中断关联值存储在相关的 /proc/irq/irq_number/smp_affinity 文件下。smp_affinity 是存储为十六进制的位掩码来代表系统中所有的处理器。默认值为 f，这意味着一个中断请求可以在系统中任何处理器中处理。如果将这个值设为 1 则意味着只有 0 位处理器可以处理这一中断。
在超过 32 个处理器的系统中，用户须将 smp_affinity 的值限定为分散的 32 位组。例如，如果一开始只想使用 64 位处理器系统中的 32 位处理器来处理一个中断请求，可以运行：
# echo 0xffffffff, & /proc/irq/IRQ_NUMBER/smp_affinity
此外，如果 BIOS 导出其 NUMA 拓扑，irqbalance 服务可以使用此信息来处理节点上的中断请求，对请求服务的硬件来说此节点是本地节点。关于 irqbalance，详情请见 ＜＞。
如果在支持中断驱动且可以修改一个中断请求的 smp_affinity 系统中设置硬件，那么特定的处理器处理一个中断请求的决策就是硬件级别，它不会受内核的干扰。关于中断驱动，详情请见 ＜＞。
3.3.8. 使用 Tuna 配置 CPU、线程和中断关联
Tuna 能够控制 CPU、线程及中断关联，并能给其所能控制的每类实体提供大量操作。完整的 Tuna 功能列表，请参见 ＜＞。
要从一个或多个特定的 CPU 中移除所有线程，请运行如下命令，使用想要隔离的 CPU 数量来替换 CPUs。
# tuna --cpus CPUs --isolate
要在可运行特定线程的 CPU 列表中加入一个 CPU，请运行如下命令，使用想要加入的 CPU 数量来替换 CPUs。
# tuna --cpus CPUs --include
要将一个中断请求移动至特定的 CPU，请运行如下命令，用 CPU 数量替换 CPU，用想要移动且使用逗号分隔的中断请求列表替换 IRQs。
# tuna --irqs IRQs --cpus CPU --move
此外，用户可以使用如下命令来找到所有 sfc1* 模式的中断请求。
# tuna -q sfc1* -c7 -m -x
要改变一个线程的策略和优先级，请运行如下命令，使用想要改变的线程替换 thread，使用需要的线程运行策略名称替换 policy，用从 0（最低优先级）至 99（最高优先级）间的一个整数替换 level。
# tuna --threads thread --priority policy:level第 4 章 内存
本章概述了红帽企业版 Linux 7 的内存管理功能。＜＞ 探讨了与内存相关的会影响性能的因素。＜＞ 教您如何使用红帽企业版 Linux 7 的工具来诊断与内存使用情况或配置细节相关的性能问题。＜＞ 探讨了可以使用的工具和策略，以此解决红帽企业版 Linux 7 中与内存相关的性能问题。
对于适中的工作负载，红帽企业版 Linux 7 会默认优化。如果用户的应用程序或用例需要大量的内存，那么改变系统处理虚拟内存可以提高应用程序的性能。
物理内存管理区块称为页面。每一个页面的物理位置都映射到一个虚拟位置以便处理器能够访问内存。这种映射存储于一个叫做页面表的数据结构中。
默认情况下，一个页面大约有 4 KB。由于页面的默认大小非常小，因此用户需要很多页面来管理大量的内存。但是，页面表只能存储有限的地址映射，增加其存储地址映射的数量既昂贵又困难，因为要考虑到将性能等级保持在内存需求的范围内。
红帽企业版 Linux 通过静态大型分页来给每个页面管理大内存的能力。静态大型分页可以配置到 1 GB 大小。但很难对其进行手动管理，必须在启动时就分配好。
透明大型分页很大程度上是之余静态大型页面的一个自动选择。透明大型页面大小为 2 MB 且默认启动。它们有时会干扰对延迟敏感的应用程序，因此常常在延迟严重时被禁用。
配置大页面以提高应用程序性能，详情请见 ＜＞。
从页面表中读取地址映射很耗时且资源很宝贵，因此 Linux 操作系统提供最近使用地址的缓存：转换后背缓冲区（TLB）。但默认的 TLB 只能缓存一定量的地址映射。如果需要的地址映射不在 TLB 中（即，TLB missed），系统仍然需要读取页面表以决定物理到虚拟的地址映射。
由于应用程序内存需求与用来缓存地址映射的页面大小之间的关系，较于对内存需求小的应用程序来说，对内存需求大的应用程序更容易受到 TLB 缺失造成的性能下降问题。因此无论何时，避免 TLB 缺失很重要。
红帽企业版 Linux 提供大型转换后背缓冲区 （大型 TLB），可以将内存分为大片段进行管理。这使大量的地址映射能同时进行缓存，以此降低 TLB 缺失的可能性，并提高需要大内存的应用程序的性能。
配置大型 TLB，详情请见 ＜＞。
4.2. 监控及诊断性能问题
红帽企业版 Linux 7 提供大量有用的工具来监控系统性能并诊断与系统内存相关的性能问题。本章概述了可用的工具，并举例说明如何使用它们来监控和诊断与内存相关的性能问题。
4.2.1. 使用 vmstat 监控内存使用量
Vmstat 由 procps-ng 数据包提供，输出用户系统进程、内存、网页、字块输入/输出、中断以及 CPU 活动等的报告。这是在机子最后一次启动或上一个报告之后提供的关于这些活动平均数的即时报告。
以下指令显示了各种事件计数和内存统计信息列表。
$ vmstat -s
使用 vmstat 的方法，详情请见 ＜＞ 或手册页：
$ man vmstat4.2.2. 用 Valgrind 分析应用程序的内存使用量
Valgrind 是一个为用户提供空间二进制文件测量方法的框架。它包含大量的工具来概述和分析程序性能。本章列出的 valgrind 工具能帮助用户检测内存错误，例如未初始化的内存使用和不适当的内存分配及解除分配。
要使用 valgrind 或其工具，请安装 valgrind 数据包：
# yum install valgrind4.2.2.1. 使用 Memcheck 分析内存使用量
Memcheck 是默认的 valgrind 工具。它检测并报告大量难以检测和诊断到的内存错误，例如：
不应发生的内存访问
使用未定义或未初始化的值
不正确的释放堆内存
指示字重叠
Memcheck 只能报告这些错误，但并不能阻止它们发生。如果程序以通常会引起段错误的方式来访问内存的话，段错误仍然会发生。但memcheck 会在发生错误之前立刻记录一条信息。
由于 memcheck 使用测量工具，通过 memcheck 执行的应用程序会比平常运行起来慢 10-30 倍。
要在应用程序上运行 memcheck， 请执行以下指令：
# valgrind --tool=memcheck application
用户也可以使用以下选项来使 memcheck 的输出集中在特定的问题类型上。
--leak-check
在应用程序结束运行后，memcheck 会搜索内存泄露问题。默认值为 --leak-check=summary，在找到内存泄露时会显示其数量。用户可以指定 --leak-check=yes 或 --leak-check=full 来输出每个泄露问题的详情。禁用请设定 --leak-check=no。
--undef-value-errors
默认值为 --undef-value-errors=yes，使用未定义的值时会报错。用户还可设定 --undef-value-errors=no ，这将禁用此报告并略微提高 Memcheck 的速度。
--ignore-ranges
在查看可寻址内存时指定一个或多个 memcheck 应忽略的范围，例如， --ignore-ranges=0xPP-0xQQ,0xRR-0xSS。
要查看 memcheck 选项的完整列表，请参见 /usr/share/doc/valgrind-version/valgrind_manual.pdf 中的文档。
4.2.2.2. 使用 Cachegrind 分析缓存使用量
Cachegrind 会模拟应用程序与系统缓存层次结构和分支预测器间的交互作用。它会追踪模拟的第一级指令和数据缓存使用情况，以此检测出该级缓存与代码间不良的交互作用。它也会追踪最后一级缓存（第二或第三极）以便追踪内存访问。这样的情况下，使用 cachegrind 的应用程序运行起来会比通常慢 20-100 倍。
Cachegrind 会收集应用程序执行期间的统计数据，并且将概要输出至操作台。要在应用程序中运行 cachegrind ，请执行以下指令：
# valgrind --tool=cachegrind application
用户也可以使用以下选项来让 cachegrind 的输出集中在一个特定的问题上。
指定大小、关联性以及第一级指令缓存行大小的方法如下：--I1=size,associativity,line_size。
指定大小、关联性以及第一级数据缓存行大小的方法如下：--D1=size,associativity,line_size.。
指定大小、关联性以及最后一级缓存行大小的方法如下：--LL=size,associativity,line_size。
--cache-sim
启用或禁用缓存访问和缺失数量的集合是默认启用的（--cache-sim=yes）。禁用此集合以及 --branch-sim 来使 cachegrind 不收集信息。
--branch-sim
启用或禁用分支指令及错误预测数量的集合是默认启用的（--branch-sim=yes）。禁用此集合以及 --cache-sim 来使 cachegrind 不收集信息。
Cachegrind 写入详细的分析信息至每个进程 cachegrind.out.pid 文件，其中， pid 是进程标识符。这一详细信息可以使用 cg_annotate 工具进行进一步处理，方法如下：
# cg_annotate cachegrind.out.pid
Cachegrind 也提供 cg_diff 工具，可以更为容易地在代码变化前后对程序性能进行记录。要对比输出文件，请执行以下命令：先用原始配置输出文件替代，再用后续配置输出文件替代。
# cg_diff first second
生成的输出文件可以使用 cg_annotate 工具来查看更多详情。
要查看 cachegrind 选项的完整列表，请参见 /usr/share/doc/valgrind-version/valgrind_manual.pdf 中的文档。
4.2.2.3. 使用 Massif 分析堆栈空间
Massif 测量特定应用程序的堆空间。它测量可用空间和额外用来记录和调准的空间。massif 有助于用户了解减少应用程序内存使用的方法，以便提高运行速度，减少应用程序耗尽系统交换空间的可能性。使用 massif 执行的应用程序运行起来比平常通常慢 20 倍左右。
要在一个应用程序中运行 massif，请执行如下命令：
# valgrind --tool=massif application
用户也可以使用以下选项来将 massif 的输出集中在一个特定的问题上。
设定 massif 是否分析堆。默认值为 --heap=yes。要禁用堆分析可设置为 --heap=no。
--heap-admin
堆分析启用时要设定每个用于管理的数据块字节数。默认值为 8 字节。
设定 massif 是否分析堆。默认值为 --stack=no 是由于堆分析会大大减缓 massif。将这一选项设置为 --stack=yes 来启用堆分析。要注意的是，massif 会假设主要的堆始于零值，这是为了更好地显示与所分析的应用程序相关的堆尺寸的变化。
设定 massif 收集分析数据的间隔。默认值为 i（执行指令）。用户也可以指定 ms（毫秒或实时）和 B（分配或收回的堆栈字节数）。检查分配的字节数有利于短期运行的应用程序及测试，因为对于不同的硬件来说，它是最具重复性的。
Massif 将分析数据输出至 massif.out.pid 文件中，该文件中的 pid 是指定应用程序的进程标识符。ms_print 工具将此分析数据绘成图表，以此显示执行应用程序的内存消耗，也包括峰值内存分配点负责分配的站点详情。要绘制 massif.out.pid 文件中的数据，请执行以下指令：
# ms_print massif.out.pid
要查看 Massif 选项的完整列表，请参见 /usr/share/doc/valgrind-version/valgrind_manual.pdf 中的文档。
4.3. 配置工具
内存使用量往往是通过设置一个或多个内核的参数值来进行配置的。这些参数可以通过改变在 /proc 文件系统中的文件内容来进行暂时设置，或是通过设置系统核心参数工具来进行永久设置，此工具由 procps-ng 数据包提供。
例如，要将 overcommit_memory 参数暂时设置为 1，请运行以下指令：
# echo 1 & /proc/sys/vm/overcommit_memory
要永久设置这个值，请运行以下指令：
# sysctl vm.overcommit_memory=1
暂时设置一个参数有利于决定此参数对系统的影响。用户可以在确定了参数值有预期的效果之后再将其设置为永久值。
4.3.1. 配置大页面
大页面依赖于连续的内存区域，因此最好在启动时，也就是在内存变为片段前就定义好大页面。为此，请添加以下参数至内核启动命令行：
启动时在内核中定义 2MB 定值大页面的数量。默认值为 0。只有在系统拥有足够的物理持续性空闲页面时才能进行分配（或是收回）大页面。此参数保留的页面不能用于其他目的。
此值可以在启动后通过改变 /proc/sys/vm/nr_hugepages 文件值来调节。
更多详情请参阅相关内核文档，默认安装于 /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt 中。
/proc/sys/vm/nr_overcommit_hugepages
通过超量使用内存来定义系统所能创建和使用的最大数量的额外大页面。在此文件中写入任何非零的值，表示系统包含此数目的大页面，在不变的页面池耗尽后，这些大页面便来自于内核的常规页面池。由于这些额外的大页面是未使用过的，因此它们会释放并返回至内核的常规页面池中。
4.3.2. 配置系统内存容量
本章探讨与内存相关的内核参数，它们可能有助于提高用户系统的内存使用率。基于测试目的，可以通过改变 /proc 文件系统中相应的文件值来暂时设置这些参数。一旦决定了能提供最佳性能的值，就可以使用 sysctl 指令来进行永久设置。
4.3.2.1. 虚拟内存参数
此章中的参数都在 /proc/sys/vm 内，除非另有标明。
dirty_ratio
一个百分比值。当整个系统内存的这一百分比值被修改时，系统会通过运行 pdflush 将改动写入磁盘。默认值为 20%。
dirty_background_ratio
一个百分比值。当整个系统内存的这一百分比值被修改时，系统会在后台将改动写入磁盘。默认值为 10 %。
overcommit_memory
定义用来决定接受或拒绝一个大内存请求的注意事项。
默认值为 0。默认情况下，内核执行探索法内存超量使用，是通过估算可用内存大小和由于太大而失败的请求来进行处理的。但由于内存分配使用的是探索法而不是精确算法，这一设置导致超载内存是可能的。
当这一参数设置成 1 时，内核不执行内存超量使用处理。这增加了内存超量的可能性，但提高了内存密集型任务的性能。
当这一参数设置成 2 时，内核拒绝请求，即请求的内存等于或大于总的可用交换空间，以及在 overcommit_ratio 中指定的物理 RAM 的百分比。这减少了超量使用内存的风险，但仅在系统交换空间大于物理内存时推荐此设置。
overcommit_ratio
当 overcommit_memory 设置为 2 时，设定所考虑的物理 RAM 的百分比。默认值为 50。
max_map_count
定义一个进程可以使用的最大内存映射区域数量。默认值（65530）适用于大部分情况。如果应用程序需要映射超过此数量的文件，可增加此值。
min_free_kbytes
指定千字节的最小数量，使之在整个系统中都保持空闲。这是用来给每一个低内存区决定一个合适的值，每一个低内存区都按照其大小比例分配了大量保留的空闲页面。
极值会损坏用户的系统。将 min_free_kbytes 设置为一个极小的值以防止系统回收内存，回收内存会导致系统锁死，以及 OOM-killing 进程。但是，将 min_free_kbytes 设置过高 （例如，整个系统内存的 5–10% ）会使系统立即进入一种内存不足的状态，导致系统花太多时间来回收内存。
在系统内存不足，并且 panic_on_oom 参数设置成 0 的情况下，oom_killer 功能会结束进程，直至系统可以恢复，从最高的 oom_score 进程开始。
oom_adj 参数有助于确定一个进程的 oom_score。此参数以每一个进程标识符为单位进行设置。值为 -17 时会禁用进程的 oom_killer。其他有效值是从 -16 到 15。
由一个调整过的进程而产生的进程会继续该进程的 oom_score。
swappiness
一个从 0 到 100 的值可以控制系统交换的程度。高值优先考虑系统效率，并在进程不活跃时主动交换物理内存耗尽的进程。低值优先考虑响应度，并且尽可能久地避免交换物理内存耗尽的进程。默认值为 60。
4.3.2.2. 文件系统参数
此章中的参数都在 /proc/sys/fs 内，除非另有标明。
aio-max-nr
定义在异步输入/输出环境中允许的最大事件数量。默认值为 65536。修改此值不会预分配或改变任何内核数据结构的大小。
定义内核分配的最大的文件句柄数量。默认值与内核中的 files_stat.max_files 值相匹配，将此值设为最大值 NR_FILE（8192，在红帽企业版 Linux 中）或是以下结果：
(mempages * (PAGE_SIZE / 1024)) / 10
增加此值可以解决由于缺少可用的文件句柄而引起的错误。
4.3.2.3. 内核参数
此章中的参数都在 /proc/sys/kernel 内，除非另有标明。
以字节为单位，定义任何一个在信息队列中的信息可能的最大值。该值不能超过队列的大小（msgmnb）。默认值为 65536。
以字节为单位，定义每一个信息队列的最大值。默认值为 65536。
定义信息队列标识符的最大数量（以及队列的最大数量）。在 64 位架构的系统中，默认值为 1985。
定义页面上共享内存的总量，这些内存是系统可以同时使用的。
定义页面上内核允许的单个共享内存片段的最大值。
定义系统范围内最大的共享内存片段数量。在所有系统中的默认值为 4096。
threads-max
定义系统范围内内核能同时使用的最大线程量。默认值与内核参数 max_threads 相同，或为以下结果：
mempages / (8 * THREAD_SIZE / PAGE SIZE )
最小值为 20。
第 5 章 存储和文件系统
此章节概述支持的文件系统和配置选项，此选项影响在红帽企业版 Linux 7 中 I/O 和文件系统的应用程序性能。〈 〉讨论了影响性能的 I/O 和文件系统相关因素。〈〉教授如何使用红帽企业版 Linux 7 工具诊断与 I/O 或者文件系统配置细节相关的性能问题。〈 〉讨论了为解决红帽企业版 Linux 7中 I/O 和文件系统相关的性能问题，您可使用的工具和策略。
存储和文件系统性能的合理设置在很大程度上取决于存储目的。 I/O 和文件系统性能会受到下列因素的影响：
数据写入或读取模式
数据重新排列与底层几何
文件系统大小
日记大小和位置
记录访问次数
确保数据可靠性
预先分配磁盘空间
阅读此章节可了解影响文件系统吞吐量、可伸缩性、响应能力、资源使用和可用性的格式和挂载选项。
SSD（固态硬盘）使用闪存芯片而非旋转磁盘存储永久数据。它们为逻辑块地址内的全部数据提供恒定访问时间，且不会像它们旋转的对应物那样出现可测量的搜寻成本。每千兆字节的存储空间更昂贵且存储密度更小，但比 HDD 延迟时间短、吞吐量更大。
当在 SSD 上使用的块接近磁盘容量，性能通常会降低。降低的程度因供应商的不同而异，在此情况下，所有设备性能都会降低。启用放弃有助于缓解性能降低；更多细节，请参见〈〉 。
默认 I/O 调度器和虚拟内存选项适用于 SSD。
SSD 部署建议的更多信息，可从 《红帽企业版 Linux 7 存储管理指南》获得， 参见 。
I/O 调度器决定 I/O 操作何时运行在存储设备上以及运行多久。它也被称为 I/O elevator（I/O 升降机）。
红帽企业版 Linux 7 提供三种 I/O 调度器。
除了 SATA 磁盘为所有块设备的默认 I/O 调度器。Deadline 尝试为指向到达 I/O 调度器的请求提供有保障的延迟。该调度器适合大多数用例，尤其适用于读取操作比写入操作更频繁的请求。
将排队的 I/O 请求分类为读或者写批处理，并按照 LBA 递增顺序执行。默认设置下，读批处理优先于写批处理，这是因为应用更可能阻止读取 I/O。批处理后，deadline 检查写入操作因等待处理器时间而处于多久的“饥饿”状态，并且适当地调度下一个读批处理或写批处理。解决批处理的请求数量、发出写批处理的读批处理数量、以及请求过期前的时间量都是可配置的，更多细节，请参见〈〉。
默认调度器只适用于标识为 SATA 硬盘的设备。完全公平队列调度器，cfq，将进程分成三个独立类别：实时、尽其所能和空闲。实时类别的进程总是先于尽其所能类别进程执行，而尽其所能类别进程总是在空闲类别进程之前执行。这意味着实时类别的进程可以使尽其所能和空闲进程等待处理器时间而忍受“饥饿”。默认设置下，分配进程到尽其所能类别。
Cfq 使用历史数据来预测应用是否会在不久之后发出更多 I/O 请求。如果将有更多 I/O 请求，cfq 空闲则会等待新的 I/O，即使有来自其他进程的 I/O 在等待处理。
因为有空闲的趋势，cfq 调度器不应用于连接不会引起大量搜寻 penalty（惩罚）的硬件，除非它为此目的而被调整。cfq 调度器也不应用于连接其他断续工作型调度器，例如基于主机的硬件 RAID 控制器，因为这些调度器的堆积有造成大量延迟的趋势。
Cfq 行为是可高度配置的，更多细节，请参见〈 〉。
noop I/O 调度器执行简单的 FIFO（先进先出）调度算法。请求通过简单的最后选中的缓存数据在一般块层合并。对于使用最快存储的受 CPU 限制的系统，这是最佳调度器。
设置不同默认 I/O 调度器的细节，或为特定设备指定不同的调度器，请参见〈〉。
欲了解红帽企业版 Linux 7 中支持文件系统的细节、推荐用例、通常情况下的文件系统可用的格式和挂载选项，请阅读此章节。为这些文件系统的调整推荐，请参见〈〉。
XFS 是一个可靠的、且可高度缩放的 64 位文件系统。它是红帽企业版 Linux 7 中默认文件系统。XFS 使用基于分区的分配，具有一些分配方案，包括预先分配和延迟的分配，这两种都会减少碎片和辅助性能。它也支持促进故障恢复的元数据日志。当挂载并激活时，能够对 XFS 进行碎片整理和放大，红帽企业版 Linux 7 支持几种 XFS 特定的备份和还原工具程序。
自红帽企业版 Linux 7.0 GA 起，XFS 支持最大容量可达 500 TB 的文件系统，以及最大容量为 8 EB 的文件偏移量（稀疏文件）。管理 XFS 的细节，请参见《红帽企业版 Linux 7 存储管理指南》。可在下列网站中查找 。如有调整 XFS 的特殊需求而需要协助，请参见〈〉。
Ext4 是 ext3 文件系统的可缩放扩展。它的默认行为对大部分工作负载是最佳的。然而，它只支持最大容量为 50 TB的文件系统以及最大容量为 16 TB 的文件。管理 ext4 的细节，请参见《红帽企业版 Linux 7 存储管理指南》，可在下列网站中查找
，如有调整 ex4 的特殊需求而需要协助，请参见〈〉。
Btrfs（技术预览）
Btrfs 是提供缩放性、容错和方便管理的 copy-on-write（写时复制）文件系统。它包括内置快照和 RAID 支持，通过数据和元数据校验来提供数据的完整性。它也通过数据压缩提高性能及使用空间的效率。Btrfs 作为一种技术预览，支持最大容量可达 50 TB 的文件系统。
Btrfs 是最适合桌面存储和云存储的。最初格式化设备时，最好按照预期使用而调整 btrfs。
红帽企业版 Linux 7 提供 Brtfs 作为技术预览。技术预览特征的细节，请参见 。
管理 brtfs 的细节，请参见《红帽企业版Linux 7存储管理手册》，可在下列网站中查找 。如有调整 btrfs 的特殊需求而需要协助，请参见〈〉。
GFS2 是具有极高可用性附加装置的一部分，为红帽企业版 Linux 7 提供簇文件系统支持。GFS2 集群提供所有服务器一致的文件系统图像，允许服务器在一个单独共享文件系统中读取和写入。
GFS2 支持最大容量可达 250 TB 的文件系统。
管理 GFS2 的细节，请参见《红帽企业版 Linux 7 存储管理指南》。可在下列网站中查找 。如有调整 GFS2 的特殊需求而需要协助，请参见〈〉。
此章节涵盖普遍适用于所有文件系统的调整注意事项。特定文件系统的调整推荐，请参见〈〉。
在设备格式化后，文件系统配置的部分决定不能改变。此章节包含格式化存储设备前必须要做的决定的可用选项。
按照工作负载创建合理大小的文件系统。按相应比例，较小的文件系统的备份次数也较少，且文件系统检查所需时间和内存也更少。然而，如果您的文件系统太小，性能将因大量碎片而降低。
块是文件系统中工作的单位。块大小决定单个块能存储多少数据，也因而决定能够同时读写的数据最小量。
默认块大小适用于大部分用例。然而，如果块大小（或者多个块大小）和通常同时读写的数据数量一样大，或者略大时，文件系统将执行得更好、存储数据更加有效率。小文件仍将使用一个完整的块。文件分布在多个块中，但这会造成额外的运行时间开销。另外，一些文件系统受限于一定数量的块，转而限制文件系统最大尺寸。
使用 mkfs 指令格式化设备时，块大小作为文件系统选项的一部分而被指定。指定块大小的参数随文件系统变化，文件系统的细节，请参见 mkfs 手册页。例如，查看格式化 XFS 文件系统时可用的选项，执行下列命令：
$ man mkfs.xfs
文件系统几何与文件系统中数据的分布相关。如果系统使用带状存储器，例如 RAID，可在格式化设备时，通过重新排列数据和底层存储几何的元数据提高性能。
很多数据导出的推荐几何在使用特定文件系统格式化设备时会被自动设置。如果设备没有导出这些推荐几何，或您想要变更推荐设置，那么您在使用 mkfs 格式化设备时，需要手动指定几何 。
指定文件系统几何的参数随文件系统而变化；文件系统细节请参见 mkfs 手册页。例如，查看格式化 ext4 系统时可用的选项，执行下列命令：
$ man mkfs.ext4
日志文件系统会在执行写操作之前，将写操作期间发生的变化记录到日志文件中。 这会降低系统发生故障、电源故障时日志的存储设备损坏的可能性，并加速恢复过程。
元数据密集工作负载涉及日志的频繁更新。大型日志使用更多内存，但会减少写操作的频繁性。此外，可通过将设备日志置于和主要存储一样快或者更快的专用存储上，提高带有元数据密集工作负载的设备的寻道时间。
确保外部日志的可靠性。失去外部日志，设备将导致文件系统损坏。
外部日志必须在格式化时便创建，并在挂载期间指定日志设备。细节请参见 mkfs 和 mount 手册页。
$ man mkfs$ man mount
此章节包含适用于大部分文件系统的调整决定，且可在挂载设备时指定。
文件系统 barrier 确保文件系统元数据正确写入到永久存储并排序，使用 fsync 传输的数据在断电下得以存留。以前红帽企业版 Linux 版本中，启用文件系统 barrier 会明显放慢严重依赖 fsync 的应用程序，或者创建和删除很多小文件。
红帽企业版 Linux 7 中，文件系统 barrier 性能的得到的改善使禁用的文件系统 barrier 的性能影响变得极小（小于3%）。
更多信息，请参见《红帽企业版 Linux 7 存储管理指南》，可在下列网站中查找 。
每次读取文件，它的元数据随访问时间（atime）更新。这涉及额外的写入 I/O。在大多数情况下，这样的开销是最小的，因为在默认设置下，前次访问时间早于上次修改时间（mtime） 或者状态变化（ctime），红帽企业版 Linux 7 只更新 atime 字段。
然而，如果更新元数据耗时，且并不对准确访问时间做要求，您可以使用 noatime 挂载选项挂载文件系统。读取文件时会禁用元数据的更新。它也会启用 nodiratime 行为，读取目录时，该行为禁用元数据的更新。
预读行为通过预取可能立即需要的数据，并且将其加载到可比在磁盘上更快检索的页面缓存中加速文件访问。预读值越高，系统预取数据越早。
红帽企业版 Linux 根据对于文件系统的检测，尝试设置一个合适的预读值。然而，检测不可能总是准确的。例如，如果存储数组将自己作为单一 LUN 展示给系统，系统会检测单一 LUN，但不会为数组设置合适的预读值。
涉及大量数据流的量数据流的顺序 I/O 的工作负载常常受益于高预读值。红帽企业版 Linux 7 提供的相关存储调整配置文件提高预读值，和使用 LVM 条带化一样，但这些调整对于所有工作负载而言并不总是足够的。
定义预写行为的参数随着文件系统而变化；请参见手册页。
$ man mount
定期丢弃文件系统不用的块是对于固态硬盘和精简配置存储的建议做法。有两种丢弃不使用的块的做法：batch discard（批量丢弃）和 online discard（网络丢弃）。
batch discard（批量丢弃）
这种丢弃方式是 fstrim 指令的一部分。它丢弃文件系统中与管理员指定的标准相配的所有不使用的块。
红帽企业版 Linux 7 支持 XFS 和 ext4 格式化设备上的 batch discard，这些设备支持实际丢弃操作即（ /sys/block/devname/queue/discard_max_bytes 值不为 0 的 HDD 设备，和 /sys/block/sda/queue/discard_granularity 不为 0 的 SSD 设备）。
online discard（网络丢弃）
这种方式的丢弃操作在挂载时间使用 discard 选项配置，实时运行不受用户干扰。然而，online discard 只丢弃从使用转换到空闲的块。红帽企业版 Linux 7 支持 XFS 和 ext4 格式化设备上的 online discard。
红帽推荐 batch discard，除非要求用 online discard 维持性能，或 batch discard 不可用于系统工作负载。
预先分配将硬盘空间标记为已经将磁盘空间分配给一个文件，而未将数据写入该空间。这可用于限制数据碎片和较差的读取性能。红帽企业版 Linux 7 支持挂载时间内 XFS、ext4、 和 GFS2 设备上预先分配空间。对您文件系统的合适参数，请参见 mount 手册页。应用程序也可通过使用 fallocate(2) glibc 调用从预先分配空间受益。
5.2. 性能问题监控和诊断
红帽企业版 Linux 7 提供一些工具，这些工具有助于监控系统性能和诊断与 I/O、文件系统及其配置相关性能问题。此章节概述可用的工具，并列举如何使用这些工具监控和诊断与 I/O 及文件系统相关的性能问题的例子。
5.2.1. 使用 vmstat 监控系统性能
Vmstat 报告整个系统的进程、内存、分页、阻止 I/O、中断和 CPU 活动。它能帮助管理员决定 I/O 子系统是否对任何性能问题负责。
下列是与 I/O 性能最相关的信息：
切换进硬盘，或者以 KB 为单位写入交换空间。
从硬盘中切换出，或者以 kb 为单位从交换空间读取。
写入块，或者以 kb 为单位阻止写操作。
读取块，或者以 kb 为单位阻止读操作。
等待 I/O 操作完成的队列部分。
交换空间和数据在同一设备上时，而且是内存使用指示器，切换进硬盘和从硬盘中切换出尤为有用。
另外，空闲、缓存和缓存列能帮助识别回写频率。缓存值突然下降和空闲值的增加表明回写和页面缓存无效。
如果使用 vmstat 的分析显示 I/O 子系统对性能下降负责，管理员可用 iostat 确定承担责任的 I/O 设备。
vmstat 由软件包 procps-ng 提供。更多使用 vmstat 的信息，请参见手册页：
$ man vmstat5.2.2. 使用 iostat 监控 I/O 性能
Iostat 是由 sysstat 软件包提供的。它报告加载在您系统中的 I/O 设备。如果使用 vmstat 的分析显示 I/O 子系统对性能下降负责，您可以使用 iostat 来确定负责的 I/O 设备。
您可以使用 iostat 手册页中定义的参数，将 iostat 报告的输出集中在特定设备上。
$ man iostat5.2.2.1. 使用 blktrace 详细说明 I/O 分析
Blktrace 提供 I/O 子系统上时间如何消耗的详细信息。配套工具 blkparse 从 blktrace 读取原始输出，并产生人们可读的输入和输出操作摘要，该摘要由 blktrace 记录。
更多此工具的细节请参见手册页：
$ man blktrace$ man blkparse5.2.2.2. 用 btt 分析 blktrace 输出
Btt 作为 blktrace 软件包的一部分而被提供。它分析 blktrace 输出，并显示该数据用在每个 I/O 栈区域的时间量，使它更容易在 I/O 子系统中发现瓶颈。
例如，如果 btt 显示发送至块层（Q2Q）的请求之间的时间比用于块层（Q2C）的请求之间的总时间长，那么 I/O 子系统可能不对性能问题负责。如果设备花了很长时间处理请求（D2C），该设备可能超载，或者发送给该设备的工作负载可能不是最佳的。如果块 I/O 队列等待很长时间，请求（Q2G）才分配给块 I/O 队列，这可能表明正在使用的存储不能够为 I/O 负载提供服务。
更多此工具的细节请参见手册页：
$ man btt5.2.2.3. 使用 seekwatcher 分析 blktrace 输出
seekwatcher 工具可使用 blktrace 输出随时间绘制 I/O 图表。它集中在硬盘 I/O 的 LBA（逻辑块地址）、每秒以兆计算的吞吐量、每秒搜寻的数量和每秒 I/O 操作。这能帮助您了解何时达到设备操作系统每秒的限制。
更多此工具的细节请参见手册页：
$ man seekwatcher5.2.3. 使用 SystemTap 监控存储
《红帽企业版 Linux 7 SystemTap 入门指南》 包含几个有助于配置和监控存储性能的示例脚本。
下列的 SystemTap 示例脚本与存储性能有关，并可能有助于诊断存储或文件系统性能问题。默认设置下，安装它们至 /usr/share/doc/systemtap-client/examples/io 目录下。
disktop.stp
每 5 秒检查读／写硬盘状态并输出在此期间的前十项。
显示用在读操作和写操作的时间量，以及读和写的字节量。
traceio.stp
根据观察到的累计 I/O 流，显示每秒前十项可执行文件。
traceio2.stp
在特定设备进行读和写操作时，显示可执行的名称和进程标识符。
inodewatch.stp
每当在特定主要／次要设备上的特定 inode 上进行读或者写操作时，显示可执行的名称和进程标识符。
inodewatch2.stp
每当在特定主要／次要设备上的特定 inode 上属性发生变化时，显示将可执行的名称、进程标识符、和属性。
《红帽企业版 Linux 7 SystemTap 入门指南》可在网站中查找 。
5.3. 配置工具
红帽企业版 Linux 提供一些帮助管理员配置存储和文件系统的工具。此章节概述可用的工具并提供示例阐述如何使用这些工具解决红帽企业版 Linux 7 中 I/O 和文件系统相关的性能问题。
5.3.1. 配置存储性能的调整配置文件。
Tuned 和 tuned-adm 提供一些旨在为特定用例提高性能的配置文件。下列配置文件对于提高存储性能尤其有用。
吞吐量性能（默认）
如需配置系统中的配置文件，请运行以下命令，用您想用的配置文件名称替代 name。
$ tuned-adm profile name
tuned-adm recommend 命令为系统推荐合适的配置文件。在安装时它也会为系统设置默认配置文件，因此可用于返回默认配置文件。
配置文件或其他配置选项更多细节，请参见 。
5.3.2. 设置默认 I/O 调度器
如果设备的挂载选项没有指定调度器，可使用默认 I/O 调度器。
如需设置默认 I/O 调度器，在重启时通过向内核命令行附加 elevator 参数来指定欲使用的调度器，或通过编辑 /etc/grub2.conf 文件。
elevator=scheduler_name5.3.3. 为设备配置 I/O 调度器
如需设置特定存储设备的调度器或调度器优先顺序，编辑 /sys/block/devname/queue/scheduler 文件，devname 为您欲配置的设备名称。
# echo cfq & /sys/block/hda/queue/scheduler5.3.4. 调整期限调度器
使用 deadline 时，排队的 I/O 请求将分为读批处理或者写批处理，然后按照 LBA 递增的执行顺序调度。默认设置下，读批处理比写批处理优先处理，这是因为在读 I/O 上应用程序易被阻止。在批处理被处理后，deadline 会检查写操作因等待处理器时间而处于多久的“饥饿”状态，并合理调度下一个读或者写批处理。
下列参数影响 deadline 调度器行为：
fifo_batch
单个批处理中读操作或写操作发出的数量。默认值为 16。值越高，吞吐量也会更多，但也会增加延迟。
front_merges
如果您的工作负载从不产生正面合并，可调整的参数设置为 0。然而，除非您已经测试了该检查的开销，红帽推荐 1 的默认值。
read_expire
应为服务调度读请求中毫秒的数量。默认值为 500（0.5秒）。
write_expire
应为服务调度写请求中毫秒的数量。默认值为 5000（5秒）。
writes_starved
先于写批处理而处理的读批处理数量。该值越高，给读批处理的优先更多。
5.3.5. 调整 cfq 调度器
使用 cfq 时 ，进程分为三类：实时、尽其所能和空闲。尽其所能进程之前调度所有实时进程，而空闲进程之前调度尽其所能进程。默认设置下，进程归类为尽其所能。可使用 ionice 命令手动调整进程分类。
通过使用下列参数进一步调整 cfq 调度器的行为。这些参数通过改变 /sys/block/devname/queue/iosched 目录下的指定文件，基于每个设备设置的。
back_seek_max
cfq 将执行向后搜寻以千字节计算的最大距离。默认值是 16 KB。 向后搜寻通常会损害性能，因此不推荐大的值。
back_seek_penalty
磁头在决定向前还是向后移动时，乘法器应用于向后搜寻。默认值为 2。如果磁头位置是 1024 KB，并且在系统中有等距的请求（例如：1008 KB 和 1040 KB），back_seek_penalty 应用于向后搜寻距离和磁盘向前移动。
fifo_expire_async
异步（缓冲写入）请求以毫秒计算的可能持续无服务的时间长度。在这个时间过期之后，一个单独的“饥饿”的异步请求移动至配送列表。默认值为 250 毫秒。
fifo_expire_sync
同步（读取或者O_DIRECT 写入）请求以毫秒计算的可能持续无服务的时间长度。在这个时期过期后，一个单独的“饥饿”的同步请求被移动到配送列表。默认值为 125 毫秒。
group_idle
默认设置下，参数设为 0（禁用）。设置为 1（禁用）时，cfq 调度器空闲在控制组中发出I/O的最后进程里。如使用成比例的重量 I/O 控制组，或 slice_idle 设置为 0 （在快速存储上）会有帮助。
group_isolation
默认设置下，该参数设置为 0（禁用）。设置为 1（启用）时，它提供组之间更强的隔离，但是吞吐量会减少，这是因为公平性用于随机和顺序工作负载。group_isolation 禁用时（设置为 0），公平性只提供给顺序工作负载。更多信息，请参见安装文件 /usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt。
low_latency
默认设置下，设置参数为 1 （启用）。启用后，通过为设备上发出 I/O 的每个进程提供最大为 300 ms 的等待时间，cfq 更注重公平性而非吞吐量。设置参数为 0 时（禁用），目标延迟被忽略，每个进程接受完整时间片。
该参数定义 cfq 在同一时间发送给一个设备的 I/O 请求的数量，实质上是对队列深度的限制。默认值为 8 请求。使用的设备可能支持更大的队列深度，但增加量程值也会导致延迟增加，尤其是大的顺序写工作负载。
slice_async
该参数定义分配给每个发出异步 I/O 请求的进程的时间片（以毫秒计算）长度。默认值为 40 毫秒。
slice_idle
该参数指定等待下一步请求时以毫秒计算的 cfq 空闲时间长度。默认值为 0（队列无空闲或者 service tree level）。默认值对于外部 raid 存储器的吞吐量是理想的，由于增加了搜寻操作的整体数量，而降低内部 non-RAID 存储器的吞吐量。
slice_sync
该参数定义分配给每个发出同步 I/O 请求的进程的时间片长度（以毫秒计算）。默认值为 100 ms。
5.3.5.1. 为快速存储调整 cfq
不向无法遭受大搜寻 penalty（惩罚）的硬件推荐 cfq 调度器，例如快速外部存储数列或者固态硬盘。如果您需要在此存储上使用 cfq ，需要编辑下列配置文件：
设置 /sys/block/devname/queue/ionice/slice_idle为0
设置 /sys/block/devname/queue/ionice/quantum 为64
设置 /sys/block/devname/queue/ionice/group_idle为 1
5.3.6. 调整 noop 调度器
noop I/O 调度器主要对使用快速存储的受 cpu 限制的系统有用。请求在块层合并，因此通过编辑 /sys/block/sdX/queue/ 目录中的文件中块层参数，修改noop 行为。
add_random
一些 I/O 事件会影响 /dev/random 的熵池 。如果这些影响的负荷变得可测量，该参数可设置为 0。
max_sectors_kb
指定 I/O 请求的最大尺寸（以千字节计算），默认值为 512 KB。该参数的最小值是由存储设备的逻辑块大小决定的。该参数的最大值是由 max_hw_sectors_kb 值决定的。
I/O 请求大于内部擦除块大小时，一些固态硬盘会表现不佳。在这种情况下，红帽推荐将 max_hw_sectors_kb 减少至内部擦除块大小。
大多数工作负载受益于请求合并。然而，禁用合并有助于调试目的。可设置参数为 0 禁用合并。默认设置下为启用（设置为 1）。
nr_requests
限定同一时间排队的读和写请求的最大数量。默认值为 128， 即在请求读或者写操作的下一个进程进入睡眠模式前有 128 个读请求和 128 个写请求排队。
对于延迟敏感应用程序，降低该参数值，并限制存储上的命令队列深度，这样回写 I/O 便无法填充有写请求的设备队列。设备队列填充时，其他尝试执行 I/O 操作的进程会进入睡眠模式，直到有可用队列空间。随后请求会以 round-robin fashion（循环方式）分配，以防止一个进程持续使用队列所有点。
optimal_io_size
一些存储设备用此参数报告最佳 I/O 大小。如果报告该值，红帽建议您尽可能将应用程序发出 I/O 与最佳 I/O 大小对齐，并是最佳 I/O 大小的倍数。
定义操作系统在顺序读取操作阶段将预先读取的千字节数量，以便存储在页面缓存中可能马上需要的信息。设备映射程序经常受益于高的 read_ahead_kb 值 128 KB ；对于访问将要被映射的设备这是一个良好的起点。
一些固态硬盘不能正确公布其固态硬盘状态，并且会如传统旋转磁盘挂载。如果您的固态硬盘不能将它自动设置它为 0，那么请您手动设置，禁用调度器上不必要的搜寻减少逻辑。
rq_affinity
默认设置下，I/O 完成能在不同处理器上进行，而不是限定在发出 I/O 请求的处理器上。 将rq_affinity 设置为 1 以禁用此能力，并只在发出 I/O 请求的处理器上执行完成。这能提高处理器数据缓存的有效性。
5.3.7. 为性能配置文件系统
此章节包含红帽企业版 Linux 7 支持的每个文件系统的调整参数。用户格式化存储设备或者挂载格式化设备时，参数根据其值是否应当配置而分配。
如果文件碎片或者资源争用引起性能损失，性能通常可通过重新配置文件系统而提高性能。然而，在有些用例中，可能需要更改应用程序。这种情况下，红帽建议联系客户支持以获得帮助。
5.3.7.1. 调整 XFS
此章节包含对 XFS 文件系统格式化和挂载时可用的一些调整参数。
XFS 默认格式化和挂载设置适用于大多数工作负载。红帽建议只在更改特定配置会对您的工作负载有益时对它们进行更改。
5.3.7.1.1. 格式化选项
格式化选项的更多信息参见手册页：
$ man mkfs.xfs目录块大小
目录块大小影响每个 I/O 操可检索或修改的目录信息数量。目录块大小最小值即文件系统块大小（默认设置下为4 KB）。目录块大小最大值为 64 KB。
对于指定的目录块大小来说，大的目录比小的目录需要更多 I/O。因为和小目录块的系统相比，大目录块大小的系统每 I/O 操作会使用更多的处理能力。因此，根据您的工作负载，推荐使用尽可能小的目录和目录块大小。
如文件系统比大量写和大量读工作负载的列出项目数量少，红帽推荐使用以下目录块大小，请参见 〈 〉
表 5.1. 为目录块大小推荐的最大目录项目录块大小最大项 （大量读操作）最大项 （大量写操作）4 KB00000000016 KB0000000000064 KB&1000000&
在不同大小文件系统中，目录块大小对读和写工作负载的影响的情况请参见 XFS 文件。
使用 mkfs.xfs -l 选项配置目录块大小。请参见 mkfs.xfs 手册页。
分配组是独立的结构，指示自由空间并在文件系统中一节分配 inodes。只要同时操作影响不同分配组，每个分配组能被独立修改，这样 XFS 同时执行分配和解除分配操作。因此文件系统中执行的同时操作数量和分配组数量相等。然而，由于执行同时操作的能力受到能够执行操作的处理器数量的限制，红帽建议分配组数量应多于或者等于系统中处理器的数量。
多个分配组无法同时修改单独目录。因此，红帽推荐大量创建和移除文件的应用程序不要在单个目录中存储所有文件。
使用 mkfs.xfs -d 选项配置分配组，更多信息参见 mkfs.xfs 手册页。
如您在格式化之后（通过增加更多硬件或通过自动精简配置），需要增加文件系统的大小，由于分配组大小在完成格式化之后不能更改，请务必仔细考虑初始文件布局。
必须根据文件系统最终能力，而非根据初始能力调节分配组大小。占据所有使用空间的文件系统中分配组数量不应超过数百，除非分配组处于最大尺寸 （1 TB）。因此，红帽向大部分文件系统推荐最大增长，允许文件系统是初始大小的十倍。
增长 RAID 数组的文件系统时，务必考虑额外护理，由于设备大小必须与固定多个分配组大小对齐，以便新分配组表头在新增加的存储中正确对齐。由于几何在格式化之后不能被更改，因此新存储也必须与已有的存储几何一致，因此，在同一个块设备上，不能优化不同几何的存储。
Inode 大小和内联属性
如果 inode 有足够可用空间，XFS 能直接将属性名称和值写入 inode。由于不需要额外的 I/O，这些内联属性能够被获取和修改，达到比获取单独的属性块更快的量级。
默认 inode 大小为 256 bytes。其中只有约 100 bytes 大小可用于属性存储，取决于 inode 上存储的数据范围指针数量。格式化文件系统时，增加 inode 大小能增加存储属性可用的空间数量。
属性名称和属性值两者都受到最大尺寸 254 bytes 的限制。如果名称或者值超过 254 bytes 长度，该属性会被推送到单独的属性快，而非存储在内联中。
使用 mkfs.xfs -i 选项配置 inode 参数，更多信息请参见 mkfs.xfs 手册页。
如果使用软件 RAID ，mkfs.xfs 会使用合适的带状单元和宽度自动配置底层的硬件。然而，如果使用硬件 RAID， 带状单元和宽度可能需要手动配置，这是因为不是所有硬件 RAID 设备输出此信息。使用 mkfs.xfs -d 选项配置带状单元和宽度。更多信息请参见 mkfs.xfs 手册页。
直到同步事件被触发，待定的更改在内存中累计，这个时候它们会被写入日志。日志大小决定同时处于进行中的修改数量。它也决定在内存中能够累计的最大更改数量，因此决定记录的数据写入磁盘的频率。与大日志相比，小日志促使数据更频繁地回写入磁盘。然而，大日志使用更多内存来记录待定的修改，因此有限定内存的系统将不会从大日志获益。
日志与底层带状单元对齐时，日志表现更佳；换言之，它们起止于带状单元边界。使用 mkfs.xfs -d 选项将日志对齐带状单元，更多信息请参见 mkfs.xfs 手册页。
使用下列 mkfs.xfs 选项配置日志大小，用日志大小替换 logsize ：
# mkfs.xfs -l size=logsize
更多详细信息参见 mkfs.xfs 手册页：
$ man mkfs.xfs日志带状单元
日志写操作起止于带状边界时（与底层带状单元对齐），存储设备上使用 RAID5 或 RAID6 布局的日志写操作可能会表现更佳。mkfs.xfs 尝试自动设置合适的日志带状单元，但这取决于输出该信息的 RAID 设备。
如果您的工作负载过于频繁地触发同步事件，设置大日志带状单元会降低性能。这是因为小的写操作需要填充至日志带状单元，而这会增加延迟。如果您的工作负载受到日志写操作延迟的约束，红帽推荐将日志带状单元设置为 1 个块，从而尽可能地触发非对齐日志写操作。
支持的最大日志带状单元为最大日志缓存的大小（256 KB）。因此底层存储器可能拥有更大的带状单元，且该带状单元能在日志中配置。在这种情况下，mkfs.xfs 会发出警告，并设置一个大小为 32 KB 的日志带状单元。
使用以下选项之一配置日志带状单元，其中 N 是被用于带状单元的块的数量，size 是以 KB 为单位的带状单元的大小。
mkfs.xfs -l sunit=Nb
mkfs.xfs -l su=size
更多详细信息参见 mkfs.xfs 手册页：
$ man mkfs.xfs5.3.7.1.2. 挂载选项Inode 分配
强烈推荐文件系统大于 1 TB。inode64 参数配置 XFS，从而在文件系统中分配 inode 和数据。这样能保证 inode 不会被大量分配到文件系统的起始位置，数据也不会被大量分配到文件系统的结束位置，从而提高大文件系统的性能表现。
日志缓存和数量
日志缓存越大，将所有变更写入日志的 I/O 操作越少 。大日志缓存能提高有大量 I/O 密集型工作负载的系统性能表现，而该工作负载没有非易变的写缓存。
通过 logbsize 挂载选项配置日志缓存大小，并确定日志缓存中信息存储的最大数量。如果未设置日志带状单元，缓存写操作可小于最大值，因此不需要减