/proc/sys/kernel/文档（二）

numa_balancing

    启用/禁用基于页面错误的自动NUMA内存平衡。内存会自动移动到经常访问它的节点。
    通常，当应用程序的进程线程正在按调度线程的方式访问同一NUMA节点上的内存时，其性能最佳。自动NUMA平衡会将任务（可以是线程或进程）移动到它们正在访问的内存附近。它还会将应用程序数据移到内存中，使其更靠近引用它的任务。当自动NUMA平衡处于活动状态时，这全部由内核自动完成。
    启用/禁用自动NUMA内存平衡。在NUMA计算机上，如果CPU访问远程内存，则会降低性能。启用此功能后，内核会通过定期取消映射页面并稍后捕获页面错误来采样哪个任务线程正在访问内存。在发生页面错误时，确定是否应将正在访问的数据迁移到本地存储节点。
    页面的取消映射和陷阱错误会导致额外的开销，理想情况下，这些开销会被改进的内存局部性所抵消，但不保证其普遍性。如果目标工作负载已绑定到NUMA节点，则应禁用此功能。否则，如果该功能的系统开销过高，则可通过numa_balancing_scan_period_min_ms，numa_balancing_scan_delay_ms，numa_balancing_scan_period_max_ms，numa_balancing_scan_size_mb和numa_balancingsyssets控制NUMA提示错误的内核样本速率。
    默认情况下，在Red Hat Enterprise Linux 7中启用了自动NUMA平衡，并且在具有NUMA属性的硬件上启动时会自动激活。
    同时满足以下两个条件时，将启用自动NUMA平衡：

• # numactl --hardware 显示多个节点
• # cat /proc/sys/kernel/numa_balancing 值为1

    在某些情况下，首选在系统范围内进行手动NUMA调整。
    要禁用自动NUMA平衡，请使用以下命令：

# echo 0 > /proc/sys/kernel/numa_balancing

    要启用自动NUMA平衡，请使用以下命令：

# echo 1 > /proc/sys/kernel/numa_balancing

numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb

    自动NUMA平衡扫描任务地址空间和取消映射页，以检测页是否正确放置，或者数据是否应迁移到任务运行所在的本地内存节点。每次“扫描延迟”任务扫描其地址空间中的下一个“扫描大小”页面数。当到达地址空间的末尾时，扫描仪将从头重新启动。
    结合起来，“扫描延迟”和“扫描尺寸”决定了扫描速率。当“扫描延迟”减小时，扫描速率增加。扫描延迟以及每个任务的扫描速率都是自适应的，并且取决于历史行为。如果正确放置页面，则扫描延迟会增加，否则扫描延迟会减少。“扫描尺寸”不是自适应的，但是“扫描尺寸”越高，扫描速率越高。
    较高的扫描速率会导致较高的系统开销，因为必须捕获页面错误，并且必须迁移潜在的数据。但是，扫描速率越高，如果工作负载模式发生更改并将远程内存访问对性能的影响降至最低，则任务内存迁移到本地节点的速度就越快。sysctl控制扫描延迟的阈值和扫描的页数。
    numa_balancing_scan_period_min_ms是扫描任务虚拟内存的最短时间（以毫秒为单位）。它有效地控制了每个任务的最大扫描速率。
    numa_balancing_scan_delay_ms是任务fork时最初使用的“扫描延迟”。
    numa_balancing_scan_period_max_ms是扫描任务虚拟内存的最长时间（以毫秒为单位）。它有效地控制了每个任务的最小扫描速率。
    numa_balancing_scan_size_mb是对于给定的扫描，扫描了多少兆字节的页面。

osrelease, ostype & version

# cat osrelease 
3.10.0-862.el7.x86_64
# cat ostype 
Linux
# cat version 
#1 SMP Fri Apr 20 16:44:24 UTC 2018

    osrelease文件和ostype文件应该足够清楚了。然而，version需要更多说明。“＃1”表示这是从该源库构建的第五个内核，其后的日期表示构建内核的时间。调整这些值的唯一方法是重建内核:-)

overflowgid & overflowuid

    如果您的体系结构不总是支持32位UID（即arm、i386、m68k、sh和sparc32），那么如果实际UID或GID将超过65535，则会向使用旧的16位UID/GID系统调用的应用程序返回一个固定的UID和GID。
sysctl允许您更改固定UID和GID的值。默认值为65534。

panic

    该文件中的值表示内核在紧急情况下重新启动之前等待的秒数。使用软件看门狗时，建议设置为60。

panic_on_io_nmi

    当CPU收到由IO错误引起的NMI时，控制内核的行为。
    0：尝试继续操作（默认）
    1：立即进入紧急情况。IO错误触发了NMI。这表明严重的系统状况，可能导致IO数据损坏。与其继续，进入紧急状态可能是更好的选择。一些服务器在按下转储按钮时会发出这种NMI，您可以使用此选项进行崩溃转储。

panic_on_oops

    当遇到oops或BUG时，控制内核的行为。
    0：尝试继续操作
    1：立即进入紧急状态。如果panic参数也非零，则机器将重新启动。

panic_on_stackoverflow

    当检测到内核，IRQ和异常堆栈（用户堆栈除外）的溢出时，控制内核的行为。如果启用了CONFIG_DEBUG_STACKOVERFLOW，则显示此文件。
    0：尝试继续操作。
    1：立即进入紧急状态。

panic_on_unrecovered_nmi

    在内存或未知的NMI上，Linux的默认行为是继续操作。对于许多环境，如科学计算，最好取出盒子并处理错误，而不是传播未修正的奇偶校验/ECC错误。
    少数系统出于奇怪的随机原因（例如电源管理）会生成NMI，因此默认设置为关闭。sysctl的工作方式类似于该目录中现有的应急控制。

panic_on_warn

    设置为1时在WARN（）路径中调用panic（）。这对于在WARN（）位置尝试kdump时避免内核重建非常有用。
    0：仅WARN（），默认行为。
    1：在打印出WARN（）位置后调用panic（）。

perf_cpu_time_max_percent

    提示内核应将多少CPU时间用于处理性能采样事件。如果perf子系统被告知其样本已超过此限制，它将降低其采样频率以尝试减少其CPU使用率。
    在NMI中会进行一些性能采样。如果这些样本出乎意料地花费太长时间执行，则NMI可能会紧挨在一起堆叠在一起，以致其他任何内容均无法执行。
    0：禁用该机制。无论花费多少CPU时间，都不要监视或校正性能采样率。
    1-100：尝试将perf的采样率限制为该CPU百分比。注意：内核会计算每个样本事件的“预期”长度。这里的100表示​​预期长度的100％。即使将其设置为100，如果超过此长度，您仍可能会看到样品节流。如果您确实不关心消耗了多少CPU，则设置为0。

参考文档

https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/sect-virtualization_tuning_optimization_guide-numa-auto_numa_balancing