• SCHED_OTHER （有时称为 SCHED_NORMAL）

  这是默认的线程策略，并由内核控制动态优先级。优先级根据线程活动进行更改。具有此策略的线程被视为具有实时优先级 0（零）。

• SCHED_FIFO （最初为先出）

  优先级范围为 1 - 99 的实时策略，1 为最高，99%。SCHED_FIFO 线程始终具有高于 SCHED_OTHER 线程的优先级更高（例如，优先级为 1 的 SCHED_FIFO 线程将具有高于 任何 SCHED_OTHER 线程的优先级）。作为 SCHED_FIFO 线程创建的任何线程都具有固定优先级，并将运行，直至被高优先级线程阻止或抢占。

• SCHED_RR (Round-Robin)

  SCHED_RR 是对 SCHED_FIFO 的修改。具有相同优先级的线程具有量量，并且是所有等同优先级 SCHED_RR 线程之间的轮循程序。此策略很少使用。

流程

• 查看默认内核：

  ~]# grubby --default-kernel
  /boot/vmlinuz-4.18.0-80.rt9.138.el8.x86_64

  命令的输出中的 rt 显示默认内核是实时内核。

流程

• 显示系统当前正在运行的内核。

  ~]# uname -a
  Linux rt-server.example.com 4.18.0-80.rt9.138.el8.x86_64 …

  注意

  当系统收到次要更新（例如从 8.3 到 8.4）时，默认内核可能会自动从 Real Time 内核改回标准内核。

验证步骤

• 显示默认内核：

  ~]# grubby --default-kernel
  /boot/vmlinuz-4.18.0-80.rt9.138.el8.x86_64

先决条件

• 确保已安装 RHEL-RT 和 rt-tests 软件包。

流程

• 运行 hwlatdetect，指定测试持续时间（以秒为单位）。

  hwlat 通过轮询 clock-source 来查找硬件和固件导致的延迟，并寻找无法解释的差距。

  # hwlatdetect --duration=60s
  hwlatdetect:  test duration 60 seconds
  	detector: tracer
  	parameters:
  		Latency threshold:    10us
  		Sample window:        1000000us
  		Sample width:         500000us
  		Non-sampling period:  500000us
  		Output File:          None
  
  Starting test
  test finished
  Max Latency: Below threshold
  Samples recorded: 0
  Samples exceeding threshold: 0

例子

• 以下结果代表了经过调优的系统，可最小化固件系统中断。在这种情况下，hwlatdetect 的输出如下所示：

  # hwlatdetect --duration=60s
  hwlatdetect:  test duration 60 seconds
  	detector: tracer
  	parameters:
  		Latency threshold: 10us
  		Sample window:     1000000us
  		Sample width:      500000us
  		Non-sampling period:  500000us
  		Output File:       None
  
  Starting test
  test finished
  Max Latency: Below threshold
  Samples recorded: 0
  Samples exceeding threshold: 0

• 以下结果代表了一个无法调整的系统，以便最大程度降低固件系统中断。在这种情况下，hwlatdetect 的输出如下所示：

  # hwlatdetect --duration=10s
  hwlatdetect:  test duration 10 seconds
  	detector: tracer
  	parameters:
  		Latency threshold: 10us
  		Sample window:     1000000us
  		Sample width:      500000us
  		Non-sampling period:  500000us
  		Output File:       None
  
  Starting test
  test finished
  Max Latency: 18us
  Samples recorded: 10
  Samples exceeding threshold: 10
  SMIs during run: 0
  ts: 1519674281.220664736, inner:17, outer:15
  ts: 1519674282.721666674, inner:18, outer:17
  ts: 1519674283.722667966, inner:16, outer:17
  ts: 1519674284.723669259, inner:17, outer:18
  ts: 1519674285.724670551, inner:16, outer:17
  ts: 1519674286.725671843, inner:17, outer:17
  ts: 1519674287.726673136, inner:17, outer:16
  ts: 1519674288.727674428, inner:16, outer:18
  ts: 1519674289.728675721, inner:17, outer:17
  ts: 1519674290.729677013, inner:18, outer:17----

  这个结果显示，在连续读取系统时钟源时，会在 15-18 us 范围内显示 10 延迟。

  hwlatdetect 使用 tracer 机制来检测无法解释的延迟。

  注意

  之前的版本使用了内核模块而不是 ftrace tracer。

• 已安装 RHEL for Real Time 软件包组。
• 系统的 root 权限。

先决条件

• 已安装 RHEL for Real Time 软件包组。
• 系统的 root 权限。

流程

• 运行 rteval 工具。

  # rteval

  rteval 程序启动一个重量系统负载的 SCHED_OTHER 任务。然后，它会测量每个在线 CPU 的实时响应。负载是循环中 Linux 内核树和 hackbench 合成基准的并行创建。

  目标是让系统进入一个状态，每个内核始终都有一个要调度的作业。作业执行各种任务，如内存分配/免费、磁盘 I/O、计算任务、内存复制等。

  当负载启动后，rteval 会启动 cyclictest 测量程序。该程序在每个在线内核上启动 SCHED_FIFO 实时线程。然后，它会测量实时调度响应时间。

  每个测量线程都需要一个时间戳，睡眠间隔，然后在启动后使用另一个时间戳。测量延迟是 t1 -(t0 + i)，这是实际生成时间 t1 之间的差值值，以及第一个时间戳 t0 以及 sleep 间隔 i 的理论唤醒时间。

  rteval 运行的详情将写入到 XML 文件中，以及系统的引导日志。此报告显示在屏幕上，并保存到压缩文件中。

  文件名采用 rteval- <date>-N-tar.bz2 格式，其中 < date> 是报告生成的日期，N 是 < date > 上运行的 Nth 计数器。

先决条件

• 根权限

验证

• 验证配置：

  ~]# cat /proc/sys/kernel/hung_task_panic
  0

流程

• 显示 available_clocksource 文件。

  # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
  tsc hpet acpi_pm

  在这个示例中，系统中的可用时钟源为 TSC、HPET 和 ACPI_PM。

流程

• 显示 current_clocksource 文件。

  # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
  tsc

  在这个示例中，系统中的当前时钟源是 TSC。

先决条件

• 系统上的 root 权限。

验证步骤

• 显示 current_clocksource 文件，以确保当前时钟源是指定的时钟源。

  # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
  hpet

  在这个示例中，系统中的当前时钟源是 HPET。

先决条件

• 系统上的 root 权限。
• clock_timing 程序必须位于系统中。如需更多信息，请参阅 clock_timing 程序。

先决条件

• 系统上的 root 权限。

• 当其中一个公司隔离了 4 个用于操作系统功能的 CPU 和中断处理时，他们就会发现最佳结果。剩余的 2 个 CPU 仅适用于应用程序处理。
• 当另一公司将网络相关应用程序进程绑定到处理网络设备驱动程序中断的单一 CPU 中时，他们发现了最佳决定。

验证

• 检查 irqbalance 的状态是否不活跃。

  ~]# systemctl status irqbalance

流程

• 使用必要的选项和参数运行 taskset。

  • 您可以使用 -c 参数而不是 CPU 掩码指定 CPU 列表。在本例中，my_embedded_process 会被指示在 CPU 0,4,7-11 上运行。

    ~]# taskset -c 0,4,7-11 /usr/local/bin/my_embedded_process

    在大多数情况下，这个调用更为方便。

  • 要设置当前运行的进程的关联性，请使用 taskset 并指定 CPU 掩码和进程。

    在本例中，指示 my_embedded_process 只使用 CPU 3（使用 CPU 掩码的十进制版本）。

    ~]# taskset 8 /usr/local/bin/my_embedded_process

  • 您可以在 bitmask 中指定多个 CPU。在本例中，my_embeed_process 会被指示在处理器 4、5、6 和 7 上执行（使用 CPU 掩码的十六进制版本）。

    ~]# taskset 0xF0 /usr/local/bin/my_embedded_process

  • 您可以为已经运行的进程设置 CPU 关联性，以将 -p (--pid)选项用于 CPU 掩码，以及您要更改的进程的 PID。在本例中，指示 PID 为 7013 的进程仅在 CPU 0 上运行。

    ~]# taskset -p 1 7013

• 系统上的 root 权限。

• oom_adj - oom_adj 有效的分数位于 -16 到 +15 范围。这个值用于计算进程的性能占用空间，使用一种算法来考虑进程运行的时间（其他因素除外）。
• oom_score - 包含使用 oom_adj 中的值计算的算法结果。

先决条件

• 知道您要优先排序的进程的进程 ID(PID)。

流程

• 将 oom_adj 的值设置为 -17。

  # echo -17 > /proc/12465/oom_adj

• 已安装 RHEL for Real Time 软件包组，以及 tuna 软件包。
• 系统的 root 权限。

先决条件

• 已安装 RHEL for Real Time 软件包组，以及 tuna 软件包。
• 系统的 root 权限。

流程

• 隔离一个或多个 CPU。

  # tuna --cpus=cpu_list --isolate

  其中 cpu_list 是要隔离的 CPU 的逗号分隔列表。

  例如：

  # tuna --cpus=0,1 --isolate

先决条件

• 已安装 RHEL for Real Time 软件包组，以及 tuna 软件包。
• 系统的 root 权限。

验证步骤

• 比较之前和将任何 IRQ 移动到指定的 CPU 后所选 IRQ 的状态。

  # tuna --irqs=128 --show_irqs
     # users         affinity
   128 iwlwifi          3

先决条件

• 已安装 RHEL for Real Time 软件包组，以及 tuna 软件包。

• 系统的 root 权限。

  注意

  分配 OTHER 和 NATCH 调度策略不需要 root 权限。

验证步骤

• 查看线程的信息，以确保信息更改。

先决条件

• 活跃的 RHEL 订阅
• kexec-tools 软件包
• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。

流程

• 执行以下命令生成内存用量报告：

  # makedumpfile --mem-usage /proc/kcore
  
  
  TYPE        PAGES    EXCLUDABLE    DESCRIPTION
  -------------------------------------------------------------
  ZERO          501635      yes        Pages filled with zero
  CACHE         51657       yes        Cache pages
  CACHE_PRIVATE 5442        yes        Cache pages + private
  USER          16301       yes        User process pages
  FREE          77738211    yes        Free pages
  KERN_DATA     1333192     no         Dumpable kernel data

先决条件

• root 权限。
• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。

先决条件

• 根 权限。
• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。

流程

• 要在本地文件系统的 /var/crash/ 目录中存储崩溃转储文件，请编辑 /etc/kdump.conf 文件并指定路径：

  path /var/crash

  选项 路径 /var/crash 代表到 kdump 保存崩溃转储文件的文件系统的路径。当您在 /etc/kdump.conf 文件中指定转储目标时，路径相对于指定的转储目标。

  如果您没有在 /etc/kdump.conf 文件中指定转储目标，则该路径代表根目录的绝对路径。根据当前系统中挂载的内容，会自动执行转储目标和调整的转储路径。

• 要改变保存崩溃转储的本地目录，以 root 用户身份编辑 /etc/kdump.conf 配置文件，如下所述。

  1. 从 #path /var/crash 行的开头删除 hash 符号("#")。

  2. 使用预期的目录路径替换该值。例如：

     path /usr/local/cores

     重要

     在 RHEL 8 中，当 kdump systemd 服务启动 - 否则服务失败，使用 path 指令定义的目录必须存在。这个行为与早期版本的 RHEL 不同，如果启动该服务时不存在该目录，则会自动创建该目录。

• 要将文件写入不同的分区，以 root 用户身份编辑 /etc/kdump.conf 配置文件，如下所述。

  1. 根据您的选择，从 #ext4 行的开头删除 hash 符号("#")。

     • 设备名称（ #ext4 /dev/vg/lv_kdump 行）
     • 文件系统标签（ #ext4 LABEL=/boot 行）
     • UUID（ #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 行）

  2. 将文件系统类型以及设备名称、标签或者 UUID 更改为所需值。例如：

     ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937

     重要

     建议您使用 LABEL= 或 UUID= 指定存储设备。无法保证 /dev/sda3 等磁盘设备名称在重启后保持一致。

• 要将崩溃转储直接写入设备，请编辑 /etc/kdump.conf 配置文件：

  1. 删除 #raw /dev/vg/lv_kdump 行开头的哈希符号 ("#")。

  2. 使用预期的设备名称替换该值。例如：

     raw /dev/sdb1

• 要使用 NFS 协议将崩溃转储保存到远程机器中，请编辑 /etc/kdump.conf 配置文件：

  1. 删除 #nfs my.server.com:/export/tmp 行开头的哈希符号 ("#")。

  2. 使用有效的主机名和目录路径替换该值。例如：

     nfs penguin.example.com:/export/cores

• 要使用 SSH 协议将崩溃转储保存到远程机器中，请编辑 /etc/kdump.conf 配置文件：

  1. 从 #ssh user@my.server.com 行的开头删除 hash 符号("#")。
  2. 使用有效的用户名和密码替换该值。

  3. 在配置中包含 SSH 密钥。

     • 从 #sshkey /root/.ssh/kdump_id_rsa 行的开头删除哈希符号。

     • 将该值改为您要转储的服务器中有效密钥的位置。例如：

       ssh john@penguin.example.com
       sshkey /root/.ssh/mykey

• 压缩崩溃转储文件的大小，并只复制使用不同的转储级别所需的页面
• 排除不必要的崩溃转储页面
• 过滤崩溃转储中包含的页面类型。

选项

• -c、-l 或 -p ：指定每个页的压缩 dump 文件的格式，使用 zlib 用于 -c 选项、使用 lzo 用于 -l 新选项，或 snappy 用于 -p 选项。
• -d (dump_level) ：排除页面，它们不会复制到转储文件中。
• --message-level ：指定消息类型。您可以通过使用这个选项指定 message_level 来限制打印的输出。例如，把 message_level 设置为 7 可打印常见消息和错误消息。message_level 的最大值为 31

先决条件

• Root 权限
• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。

• 使用 -c 压缩崩溃转储文件：

• 使用 -p 压缩崩溃转储文件：

先决条件

• root 权限。
• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。

先决条件

• 管理员特权

验证

• 检查 kdump 服务是否正在运行：

  # systemctl status kdump.service
  
  ○ kdump.service - Crash recovery kernel arming
       Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
       Active: active (live)

先决条件

• 管理员特权

验证

• 检查 kdump 服务是否正在运行：

  # systemctl status kdump.service
  
  ○ kdump.service - Crash recovery kernel arming
       Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
       Active: active (live)

先决条件

• 满足 kdump 配置和目标的要求。详情请查看支持的 kdump 配置和目标。
• 安装 kdump 的所有配置都是根据您的需要设置的。详情请参阅 安装 kdump。

流程

• 要查看正在运行的线程的调度优先级，请使用 tuna 程序：

  # tuna --show_threads
                        thread       ctxt_switches
      pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
    2      OTHER     0    0xfff       451            3        kthreadd
    3       FIFO     1        0     46395            2     ksoftirqd/0
    5      OTHER     0        0        11            1    kworker/0:0H
    7       FIFO    99        0         9            1   posixcputmr/0
    ...[output truncated]...

• 其他
• batch
• idle
• fifo
• rr

先决条件

• 管理员特权。
• 引导时运行的服务。

验证

• 显示服务优先级。

  $ tuna -t mcelog -P

  输出显示服务的已配置优先级。

  例如：

                      thread       ctxt_switches
    pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
  826     FIFO    20  0,1,2,3        13            0          mcelog

先决条件

• 管理员特权。

验证

• 显示将指定服务限制为的 CPU。

  $ tuna -t mcelog -P

  其中，service 是指定的服务。

  以下输出显示 mcelog 服务限制为 CPU 0 和 1。

                      thread       ctxt_switches
    pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
  12954   FIFO    20      0,1         2            1          mcelog

先决条件

• 管理员特权。

流程

• 要启用 coalescing 中断，请使用 --coalesce 选项运行 ethtool 命令。

  # ethtool -C tun0

先决条件

• 管理员特权

流程

• 要更改暂停参数，请使用 -A 选项运行 ethtool 命令。

  # ethtool -A enp0s31f6

先决条件

• 管理员特权

流程

• 安装 trace-cmd。

  # yum install trace-cmd

先决条件

• 管理员特权。

流程

• 输入 trace-cmd 命令

  其中 command 是一个 ftrace 选项。

  注意

  有关命令和选项的完整列表，请查看 trace-cmd(1) 手册页。大多数个别命令也具有自己的 man page，trace-cmd-命令。

例子

• 在 myapp 运行时，启用和开始在内核中执行的记录功能。

  # trace-cmd record -p function myapp

  此记录来自所有 CPU 和所有任务的功能，甚至与 myapp 无关。

• 显示结果。

  # trace-cmd report

• 仅记录在 myapp 运行时 开始的功能。

  # trace-cmd record -p function -l 'sched*' myapp

• 启用所有 IRQ 事件。

  # trace-cmd start -e irq

• 启动 wakeup_rt tracer。

  # trace-cmd start -p wakeup_rt

• 在禁用功能追踪时启动 preemptirqsoff tracer。

  # trace-cmd start -p preemptirqsoff -d

  注意

  RHEL 8 中的 trace-cmd 版本关闭 ftrace_enabled 而不是使用 function-trace 选项。您可以使用 trace-cmd start -p 功能再次启用 ftrace。

• 在 trace-cmd 开始修改系统前，恢复系统所处的状态。

  # trace-cmd start -p nop

  如果您要在使用 trace-cmd 后使用 debugfs 文件系统，这很重要，无论是在平均时间中重启该系统。

• 跟踪单个 trace 点。

  # trace-cmd record -e sched_wakeup ls /bin

• 停止追踪。

  # trace-cmd record stop

• 如果您的应用程序有一个多线程应用程序，其中线程需要通过共享缓存相互通信，则可能需要在同一 NUMA 节点或物理套接字中保存。
• 如果您运行多个不相关的实时应用程序，可将 CPU 除以 NUMA 节点或套接字进行隔离。

先决条件

• 必须安装 hwloc 软件包。

先决条件

• 已安装 TuneD 和 tuned-profiles-realtime 软件包。

验证

• 在内核命令行中搜索 isolcpus 参数：

  $ cat /proc/cmdline | grep isolcpus
  BOOT_IMAGE=/vmlinuz-4.18.0-305.rt7.72.el8.x86_64 root=/dev/mapper/rhel_foo-root ro crashkernel=auto rd.lvm.lv=rhel_foo/root rd.lvm.lv=rhel_foo/swap console=ttyS0,115200n81 isolcpus=0,4

流程

• 要调整 sched_nr_migrate 变量的值，请直接向 /proc/sys/kernel/sched_nr_migrate 回显：

  ~]# echo 2 > /proc/sys/kernel/sched_nr_migrate

验证

• 查看 /proc/sys/kernel/sched_nr_migrate 的内容：

  ~]# cat > /proc/sys/kernel/sched_nr_migrate
  2

流程

• 关闭 TCP 时间戳：

  # sysctl -w net.ipv4.tcp_timestamps=0
  net.ipv4.tcp_timestamps = 0

  输出显示 net.ip4.tcp_timestamps 选项的值是 0。也就是说，TCP 时间戳被禁用。

流程

• 启用 TCP 时间戳。

  # sysctl -w net.ipv4.tcp_timestamps=1
  net.ipv4.tcp_timestamps = 1

  输出显示 net.ip4.tcp_timestamps 的值为 1。也就是说，启用 TCP 时间戳。

流程

• 显示 TCP 时间戳生成状态：

  # sysctl net.ipv4.tcp_timestamps
  net.ipv4.tcp_timestamps = 0

  值 1 表示生成时间戳。值 0 表示不会生成时间戳。

流程

• 要从运行 RCU 回调的候选中移除一个或多个 CPU，在 rcu_nocbs 内核参数中指定 CPU 列表，例如：

  rcu_nocbs=1,4-6

  或者

  rcu_nocbs=3

  第二个示例指示 CPU 3 为 no-callback CPU 的内核。这意味着，RCU 回调不会在 rcuc/$CPU 线程固定到 CPU 3 中完成，但在 rcuo/$CPU 线程中。您可以将此 trhead 移到 housekeeping CPU，以缓解 CPU 3 不会被分配的 RCU 回调作业。

流程

• 将 RCU 回调线程移到 housekeeping CPU 中：

  # tuna --threads=rcu --cpus=x --move

  其中 x 是内务 CPU 的 CPU 号。

流程

• 设置 rcu_nocb_poll 内核参数。

  此命令会导致计时器定期提升 RCU 卸载线程，以检查是否存在回调是否在运行。

过滤器示例

• 仅追踪 schedule 功能：

  # echo schedule > /sys/kernel/debug/tracing/set_ftrace_filter

• 跟踪以 锁定结尾的所有功能 ：

  # echo "*lock" > /sys/kernel/debug/tracing/set_ftrace_filter

• 跟踪以 spin_ 开头的所有功能：

  # echo "spin_*" > /sys/kernel/debug/tracing/set_ftrace_filter

• 跟踪名称中 cpu 的所有功能：

  # echo "cpu" > /sys/kernel/debug/tracing/set_ftrace_filter

流程

• 要调用 sched_yield（） 系统代码，请运行以下命令：

  for(;;) {
              do_the_computation();
              /*
  	     * Notify the scheduler the end of the computation
               * This syscall will block until the next replenishment
               */
  	    sched_yield();
          }

  SCHED_DEADLINE 任务使用基于冲突的搜索(CBS)算法限度，直到下一次执行循环开始为止。

• 在内存中构建连续数据包，然后将逻辑数据包发送到使用 TCP_NODELAY 配置的套接字上的 TCP。
• 在配置了 TCP_NODELAY 的套接字上创建一个 I/O vector，并使用 writev 命令将其传递给内核。
• 使用 TCP_CORK。TCP_CORK 告知 TCP 在发送任何数据包前等待应用程序删除 cork。该命令会导致它接收的缓冲区附加到现有缓冲区中。这使得应用程序可以在内核空间中构建数据包，在使用为层提供提取的不同库时，可能需要此数据包。

流程

• 使用以下任一方式创建 mutex 属性对象：

  • pthread_mutex_t(my_mutex);
  • pthread_mutexattr_t(&my_mutex_attr);
  • pthread_mutexattr_init(&my_mutex_attr);

流程

• 使用以下任一方法在 pthreads 中创建 mutex 对象：

  • pthread_mutex_t(my_mutex);

  • pthread_mutex_init(&my_mutex, &my_mutex_attr);

    其中 &my_mutex_attr; 是 mutex 属性对象。

流程

• 使用 _destroy 命令清理属性对象。

  pthread_mutexattr_destroy(&my_mutex_attr);

  mutex 现在作为常规 pthread_mutex 运行，可以正常锁定、解锁和销毁。

流程

• 收集系统范围性能统计数据。

  # perf record -a
  ^C[ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.725 MB perf.data (~31655 samples) ]

  在本例中，所有 CPU 都使用 -a 选项表示，进程在几秒钟后被终止。结果显示收集 0.725 MB 数据并将其保存到新创建的 perf.data 文件中。

验证

• 确保结果文件已创建。

  # ls
  perf.data

• 分析系统中已存在动态共享对象(DSO)，如二进制和库，如 ~/.debug/ 缓存。
• 两个系统都有相同的二进制文件集合。

流程

• 直接从 perf.data 文件或存档 tarball 中分析结果。

  # perf report

  报告的输出根据应用程序的最大 CPU 使用量排序。它显示示例是否已在进程的内核或用户空间中出现。

  这个报告显示从中获取示例模块的信息：

  • 没有出现在内核模块中的内核示例标有符号 [kernel.kallsyms]。
  • 发生在内核模块中的内核示例被标记为 [module] [ext4]。

  • 对于用户空间的进程，结果可能会显示与进程关联的共享库。

    这个报告表示进程在内核或用户空间中是否发生。

  • 结果 [.] 表示用户空间。
  • 结果 [k] 表示内核空间。

  精细细节可用于审核，包括适合经验丰富的 perf 开发人员的数据。

流程

• 列出预定义的硬件和软件事件：

  # perf list
  List of pre-defined events (to be used in -e):
    cpu-cycles OR cycles                               [Hardware event]
    stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
    stalled-cycles-backend OR idle-cycles-backend      [Hardware event]
    instructions                                       [Hardware event]
    cache-references                                   [Hardware event]
    cache-misses                                       [Hardware event]
    branch-instructions OR branches                    [Hardware event]
    branch-misses                                      [Hardware event]
    bus-cycles                                         [Hardware event]
  
    cpu-clock                                          [Software event]
    task-clock                                         [Software event]
    page-faults OR faults                              [Software event]
    minor-faults                                       [Software event]
    major-faults                                       [Software event]
    context-switches OR cs                             [Software event]
    cpu-migrations OR migrations                       [Software event]
    alignment-faults                                   [Software event]
    emulation-faults                                   [Software event]
    ...[output truncated]...

先决条件

• 系统的 root 权限

流程

• 要测试一个 CPU 上的浮动点 60 秒，请使用 --matrix 选项：

  # stress-ng --matrix 1 -t 1m

• 要对多个 CPU 运行多个 stressors，请使用 --times 或 -t 选项：

  # stress-ng --matrix 0 -t 1m
  
  stress-ng --matrix 0 -t 1m --times
  stress-ng: info:  [16783] dispatching hogs: 4 matrix
  stress-ng: info:  [16783] successful run completed in 60.00s (1 min, 0.00 secs)
  stress-ng: info:  [16783] for a 60.00s run time:
  stress-ng: info:  [16783] 240.00s available CPU time
  stress-ng: info:  [16783] 205.21s user time   ( 85.50%)
  stress-ng: info:  [16783] 0.32s system time (  0.13%)
  stress-ng: info:  [16783] 205.53s total time  ( 85.64%)
  stress-ng: info:  [16783] load average: 3.20 1.25 1.40

  带有 0 stressors 的特殊模式，查询要运行的可用 CPU 数量，从而无需指定 CPU 号。

  需要的总 CPU 时间为 4 x 60 秒（240 秒），其中 0.13% 在内核中是 85.50%，所有 CPU 的 stress-ng 运行 85.64%。

• 要使用 POSIX 消息队列测试在进程间传递的消息，请使用 -mq 选项：

  # stress-ng --mq 0 -t 30s --times --perf

  mq 选项配置特定的进程，以使用 POSIX 消息队列强制上下文切换。此压力测试旨在降低数据缓存未命中。

先决条件

• 系统的 root 权限

流程

• 运行多个 CPU 压力实例，如下所示：

  # stress-ng --cpu 2 --matrix 1 --mq 3 -t 5m

  在示例中，sess-ng 运行 CPU stressors 的两个实例，一个列表压力器和消息队列压力测试的三个实例来测试五分钟。

• 要并行运行所有 stress 测试，请使用 -all 选项：

  # stress-ng --all 2

  在本例中，s ess-ng 并行运行所有 stress 测试的两个实例。

• 要以特定顺序运行每个不同的压力，请使用 --seq 选项。

  # stress-ng --seq 4 -t 20

  在本例中，sess-ng 以 1 到 20 分钟后运行一次，每个压力的实例数与在线 CPU 的数量匹配。

• 要从测试运行中排除特定的 stressors，请使用 -x 选项：

  # stress-ng --seq 1 -x numa,matrix,hdd

  在本例中，stress-ng 运行所有的 stressors，每个实例都不包括 numa、hdd 和 key stressors 机制。

先决条件

• 系统的 root 权限。

先决条件

• 系统上的 root 权限

流程

• 要在 bogo 操作中测量测试结果，可将 与 --metrics-brief 选项搭配使用：

  # stress-ng --matrix 0 -t 60s --metrics-brief
  
  stress-ng: info: [17579] dispatching hogs: 4 matrix
  stress-ng: info: [17579] successful run completed in 60.01s (1 min, 0.01 secs)
  stress-ng: info: [17579] stressor bogo ops real time usr time sys time   bogo ops/s bogo ops/s
  stress-ng: info:  [17579]                  (secs)   (secs)  (secs)  (real time) (usr+sys time)
  stress-ng: info:  [17579] matrix  349322   60.00    203.23   0.19      5822.03      1717.25

  --metrics-brief 选项显示测试结果以及 列表 压力运行的实时 bogo 操作总数，60 秒。

先决条件

• 系统的 root 权限。

流程

• 要压力测试虚拟内存，请使用 --page-in 选项：

  # stress-ng --vm 2 --vm-bytes 2G --mmap 2 --mmap-bytes 2G --page-in

  在这个示例中，E ess-ng 测试内存在有 4GB 内存的系统上压力，小于分配的缓冲区大小，vm stressor 的 2 x 2GB 和启用了 --page-in 的 mmap stressor 的 2 x 2GB 压力。

先决条件

• 系统上的 root 权限。

流程

• 要生成中断负载，请使用 --timer 选项：

  # stress-ng --timer 32 --timer-freq 1000000

  在本例中，stress-ng 测试 32 个实例，位于 1MHz。

先决条件

• 系统上的 root 权限。

流程

• 要在早期内核版本上生成主要页面错误，请使用：

  # stress-ng --fault 0 --perf -t 1m

• 要在新内核版本上生成主要页面错误，请使用：

  # stress-ng --userfaultfd 0 --perf -t 1m

先决条件

• 系统上的 root 权限。

先决条件

• 系统上的 root 权限。

流程

• 要验证压力测试结果，请使用 --verify 选项：

  # stress-ng --vm 1 --vm-bytes 2G --verify -v

  在本例中，s stress-ng 使用配置了 --verify 模式的 vm stressor 打印针对虚拟映射内存检查的详细内存检查。它能够检查内存中的读取和写入结果。