首页
/ BCC系统性能监控实战：从进程追踪到CPU调度分析

BCC系统性能监控实战：从进程追踪到CPU调度分析

2026-02-04 04:25:08作者：裘旻烁
bcc
iovisor/bcc: 是基于 Linux eBPF 的新型网络分析工具，可用于 Linux 系统的性能监控、网络追踪和安全分析等领域。适合对
项目地址：https://gitcode.com/gh_mirrors/bc/bcc

本文深入探讨了BCC工具集中四个核心性能监控工具：execsnoop、runqlat、profile和cpudist。这些工具基于eBPF技术，为Linux系统提供了强大的实时监控和分析能力。从进程创建追踪到CPU调度延迟分析，从系统性能剖析到CPU时间分布统计，这些工具共同构成了完整的系统性能监控解决方案，帮助系统管理员和开发人员快速诊断和解决性能问题。

execsnoop：实时监控进程创建与执行

在Linux系统性能监控领域，execsnoop是BCC工具集中一个极为强大的实时进程追踪工具。它专门用于监控系统中通过exec()系统调用创建的新进程，为系统管理员和开发人员提供了前所未有的进程创建洞察能力。

execve系统调用与进程创建机制

在深入了解execsnoop之前，我们需要理解Linux进程创建的基本机制。传统的进程创建遵循fork-exec模型：

flowchart TD
    A[父进程] --> B[fork系统调用]
    B --> C[创建子进程副本]
    C --> D[子进程内存空间]
    D --> E[execve系统调用]
    E --> F[加载新程序映像]
    F --> G[新进程执行]

execve()系统调用是这个过程的核心，它负责：

  • 程序加载：将新的可执行文件加载到进程地址空间
  • 参数传递：接收命令行参数和环境变量
  • 映像替换：完全替换当前进程的代码、数据和堆栈段
  • 权限处理：处理setuid/setgid权限位

execsnoop的工作原理

execsnoop利用eBPF技术在内核层面挂钩execve系统调用，其架构如下：

sequenceDiagram
    participant User as 用户空间
    participant Kernel as 内核空间
    participant eBPF as eBPF程序
    participant Perf as Perf Buffer
    
    User->>Kernel: 启动execsnoop
    Kernel->>eBPF: 加载BPF程序
    eBPF->>Kernel: 挂钩sys_execve入口
    eBPF->>Kernel: 挂钩sys_execve返回
    
    Note over Kernel: 进程执行execve时
    Kernel->>eBPF: 触发kprobe处理
    eBPF->>Perf: 提交参数事件(EVENT_ARG)
    eBPF->>Perf: 提交返回事件(EVENT_RET)
    Perf->>User: 传输事件数据
    User->>User: 解析并显示进程信息

核心功能特性

execsnoop提供了丰富的监控功能，主要包括：

1. 基本进程信息监控

  • 进程名称(COMM)：执行的程序名称
  • 进程ID(PID)：新进程的系统唯一标识符
  • 父进程ID(PPID)：创建该进程的父进程ID
  • 返回值(RET)：execve系统调用的返回状态码
  • 命令行参数(ARGS)：完整的执行命令和参数

2. 高级过滤功能

# 按用户ID过滤
sudo execsnoop -u 1000

# 按父进程ID过滤
sudo execsnoop -P 1234

# 按进程名模式匹配
sudo execsnoop -n "nginx"

# 按参数内容过滤
sudo execsnoop -l "config"

3. 详细的执行上下文

# 包含时间戳和UID信息
sudo execsnoop -tU

# 显示失败的执行尝试
sudo execsnoop -x

# 引用参数显示
sudo execsnoop -q

实际应用场景

场景1：诊断进程创建问题

当系统出现性能问题时，execsnoop可以帮助识别异常的进程创建模式：

# 监控所有进程创建
sudo execsnoop -T

输出示例：

TIME     COMM             PID    PPID   RET ARGS
14:23:45 cron             12345  1       0 /usr/sbin/cron -f
14:23:46 bash             12346  12345   0 /bin/bash -c /opt/script.sh
14:23:47 python           12347  12346   0 /usr/bin/python /opt/script.py

场景2：安全审计与入侵检测

通过监控异常的进程创建行为，可以发现潜在的安全威胁：

# 监控特定用户的进程执行
sudo execsnoop -u nobody -x

场景3：应用程序行为分析

开发人员可以使用execsnoop来理解复杂应用程序的启动过程：

# 分析Docker容器启动过程
sudo execsnoop -n docker --print-pcomm

技术实现深度解析

execsnoop的核心eBPF程序结构：

struct data_t {
    u32 pid;           // 进程ID
    u32 ppid;          // 父进程ID  
    u32 uid;           // 用户ID
    u32 cpu;           // CPU编号
    char comm[TASK_COMM_LEN];     // 进程名
    char pcomm[TASK_COMM_LEN];    // 父进程名
    enum event_type type;         // 事件类型
    char argv[ARGSIZE];           // 参数内容
    int retval;                   // 返回值
};

工具使用双挂钩策略：

  1. kprobe挂钩：监控execve系统调用入口，捕获参数信息
  2. kretprobe挂钩：监控execve返回，捕获执行结果

性能影响与最佳实践

execsnoop的设计极其高效，对系统性能的影响微乎其微：

  • 低开销：eBPF程序在内核中运行，避免用户空间-内核空间频繁切换
  • 零采样：捕获每一个execve调用，无采样误差
  • 实时输出：通过perf buffer实时传输数据

使用建议：

# 短期监控用于问题诊断
sudo execsnoop -t -n "problematic_app"

# 长期监控使用日志记录
sudo execsnoop -T | tee process_creation.log

# 结合其他工具进行综合分析
sudo execsnoop -U | awk '{print $1,$2}' | sort | uniq -c

高级用法示例

容器环境监控

# 监控特定cgroup的进程创建
sudo execsnoop --cgroupmap /sys/fs/bpf/docker-cgroups

# 监控命名空间内的进程
sudo execsnoop --mntnsmap /sys/fs/bpf/container-ns

性能基准测试

# 测量应用程序启动时间
start_time=$(date +%s.%N)
sudo execsnoop -t -n "myapp" | grep -q "myapp" && \
end_time=$(date +%s.%N)
echo "启动时间: $(echo "$end_time - $start_time" | bc)秒"

输出解读与数据分析

execsnoop的输出包含丰富的信息，正确解读这些数据至关重要：

字段 说明 诊断价值
RET=0 执行成功 正常操作
RET=-1 权限错误 权限配置问题
RET=-2 文件不存在 路径配置错误
RET=-13 权限拒绝 SELinux或AppArmor限制

通过分析这些返回值，可以快速定位各类执行问题。

execsnoop作为BCC工具集的重要组成部分，为Linux系统管理员提供了强大的进程级监控能力。无论是性能诊断、安全审计还是应用行为分析，execsnoop都能提供准确、实时的进程创建信息，是现代Linux系统监控不可或缺的工具。

runqlat：CPU调度延迟分析与优化

在现代Linux系统中，CPU调度性能是影响应用程序响应时间和系统整体效率的关键因素。runqlat作为BCC工具集的重要组成部分，专门用于测量和分析CPU运行队列延迟，为系统性能调优提供了强大的洞察能力。

运行队列延迟的核心概念

运行队列延迟（Run Queue Latency）是指进程从变为可运行状态（runnable）到实际开始在CPU上执行所经历的时间间隔。这个指标直接反映了CPU调度器的效率和系统负载状况。

flowchart TD
    A[进程变为可运行状态] --> B[进入运行队列等待]
    B --> C{CPU资源可用?}
    C -->|是| D[开始执行]
    C -->|否| E[继续等待]
    E --> C
    D --> F[执行完成]

运行队列延迟的产生主要源于两种场景：

  1. 主动上下文切换：进程完成时间片或主动让出CPU，重新进入运行队列等待
  2. 被动唤醒：进程被中断或信号唤醒，从睡眠状态进入运行队列

runqlat的工作原理与实现机制

runqlat利用eBPF技术在内核层面进行高效追踪，通过以下关键机制实现延迟测量：

内核追踪点机制

runqlat使用Linux内核的调度器追踪点来捕获进程状态变化：

  • sched_wakeup：进程被唤醒时触发
  • sched_wakeup_new：新进程创建时触发
  • sched_switch：上下文切换时触发

时间戳记录与计算

// 记录进程入队时间戳
static int trace_enqueue(u32 tgid, u32 pid)
{
    u64 ts = bpf_ktime_get_ns();
    start.update(&pid, &ts);
    return 0;
}

// 计算延迟并更新直方图
int trace_run(struct pt_regs *ctx, struct task_struct *prev)
{
    u64 *tsp, delta;
    tsp = start.lookup(&pid);
    delta = bpf_ktime_get_ns() - *tsp;
    dist.atomic_increment(bpf_log2l(delta));
}

runqlat的实战应用场景

系统负载状况分析

通过runqlat可以快速识别系统的CPU负载状况：

# 基本用法：汇总运行队列延迟直方图
./runqlat

# 每5秒输出一次，共3次，使用毫秒单位
./runqlat -m 5 3

进程级延迟分析

对于特定进程的调度延迟分析：

# 仅追踪PID为185的进程
./runqlat -p 185

# 按进程ID分别显示直方图
./runqlat -P

# 按线程ID分别显示直方图  
./runqlat -L

容器环境下的调度分析

在容器化环境中，runqlat可以帮助识别CPU限制导致的调度问题：

# 追踪特定cgroup路径下的进程
./runqlat -c /sys/fs/cgroup/unified

典型输出结果解读

runqlat的输出采用直方图形式展示延迟分布：

     usecs               : count     distribution
         0 -> 1          : 233      |***********                             |
         2 -> 3          : 742      |************************************    |
         4 -> 7          : 203      |**********                              |
         8 -> 15         : 173      |********                                |
        16 -> 31         : 24       |*                                       |
        32 -> 63         : 0        |                                        |
        64 -> 127        : 30       |*                                       |
       128 -> 255        : 6        |                                        |
       256 -> 511        : 3        |                                        |
       512 -> 1023       : 5        |                                        |
      1024 -> 2047       : 27       |*                                       |
      2048 -> 4095       : 30       |*                                       |
      4096 -> 8191       : 20       |                                        |
      8192 -> 16383      : 29       |*                                       |
     16384 -> 32767      : 809      |****************************************|
     32768 -> 65535      : 64       |***                                     |

延迟分布模式分析

延迟范围 典型场景 性能影响
0-15微秒 空闲系统 最优性能
16-1000微秒 轻度负载 可接受延迟
1-10毫秒 中度负载 需要关注
10-100毫秒 重度负载 性能瓶颈
100+毫秒 极端负载 严重问题

性能问题诊断与优化策略

识别调度瓶颈

通过runqlat的输出模式可以识别不同类型的调度问题：

双峰分布模式：通常表示系统中存在两种不同类型的负载

  • 低延迟峰值：交互式进程或高优先级任务
  • 高延迟峰值：CPU密集型后台任务

长尾分布模式：表示存在严重的CPU资源竞争

优化建议与解决方案

根据runqlat分析结果，可以采取以下优化措施：

  1. CPU资源扩展

    • 增加CPU核心数
    • 启用超线程技术
    • 调整CPU频率调节策略

  2. 调度策略优化

    • 调整进程优先级（nice值）
    • 使用CPU亲和性设置
    • 优化中断平衡

  3. 工作负载调整

    • 负载均衡分配
    • 批处理任务调度优化
    • 实时进程优先级调整

高级使用技巧

与其他工具协同分析

runqlat可以与其他BCC工具配合使用，进行全面的性能分析：

# 结合cpudist分析CPU使用时间分布
./cpudist

# 使用runqlen查看运行队列长度
./runqlen

# 使用profile进行CPU使用率采样分析  
./profile -adf 10

自动化监控与告警

通过脚本化方式实现runqlat的自动化监控：

#!/bin/bash
# 监控运行队列延迟并触发告警
THRESHOLD=10000  # 10毫秒阈值

while true; do
    # 捕获runqlat输出并解析最大延迟
    MAX_LATENCY=$(./runqlat 1 1 | awk '/^[0-9]/{print $1}' | sort -nr | head -1)
    
    if [ "$MAX_LATENCY" -gt "$THRESHOLD" ]; then
        echo "警告：检测到高运行队列延迟: ${MAX_LATENCY}us"
        # 触发告警逻辑
    fi
    
    sleep 30
done

实际案例研究

案例一：Web服务器响应延迟问题

某Web服务器在高峰时段出现响应延迟，通过runqlat分析发现：

  • 平均运行队列延迟：15毫秒
  • 95百分位延迟：45毫秒
  • 最大延迟：120毫秒

根本原因：CPU核心数不足，导致请求处理进程长时间等待调度

解决方案：增加CPU核心并优化Nginx工作进程配置

案例二：数据库查询性能下降

数据库集群出现查询性能波动，runqlat显示：

  • 周期性出现高延迟峰值（50+毫秒）
  • 与备份任务执行时间高度相关

根本原因：备份任务与业务查询竞争CPU资源

解决方案：调整备份任务优先级和调度时间

技术限制与注意事项

在使用runqlat时需要注意以下限制：

  1. 内核版本要求：需要Linux 4.1+内核支持eBPF
  2. 性能开销：在高频调度场景下可能有轻微性能影响
  3. 采样精度：极端短时间的调度事件可能无法完全捕获
  4. 容器环境：需要适当的权限才能监控容器内进程

最佳实践指南

为了充分发挥runqlat的诊断价值，建议遵循以下最佳实践：

  1. 基线建立：在系统正常运行时建立延迟基线
  2. 定期监控：设置定期运行队列延迟检查
  3. 关联分析：结合其他监控指标进行综合分析
  4. 趋势跟踪：长期跟踪延迟变化趋势
  5. 告警阈值：根据业务需求设置合理的告警阈值

runqlat作为BCC工具集中专门针对CPU调度性能分析的工具，为系统管理员和性能工程师提供了深入洞察Linux调度器行为的强大能力。通过准确测量运行队列延迟，可以帮助识别和解决各种CPU资源竞争和调度效率问题，最终提升系统的整体性能和响应能力。

profile：系统性能剖析与热点识别

在现代系统性能分析中，CPU性能剖析是识别应用性能瓶颈和优化机会的关键技术。BCC提供的profile工具通过eBPF技术实现了高效的系统级性能剖析，能够以极低的性能开销捕获CPU使用情况的详细快照。

工作原理与架构设计

profile工具基于Linux内核的perf_events子系统，通过定时采样CPU堆栈轨迹来构建性能剖析数据。其核心工作机制如下：

flowchart TD
    A[perf_events定时中断] --> B[触发eBPF程序执行]
    B --> C[捕获当前进程上下文]
    C --> D[获取用户空间堆栈ID]
    D --> E[获取内核空间堆栈ID]
    E --> F[构建性能数据键值对]
    F --> G[在哈希表中增量计数]
    G --> H[定期聚合输出结果]

工具的核心优势在于内核空间的频率计数机制，相比传统profiler将每个堆栈样本传输到用户空间，profile在内核中完成频率统计，大幅减少了内核与用户空间的数据传输量。

关键特性与使用模式

profile工具提供了丰富的配置选项来满足不同的性能分析需求：

采样模式配置

参数选项 说明 示例用法
-F, --frequency 设置采样频率（Hz） profile -F 99
-c, --count 设置采样事件周期 profile -c 1000000
-p, --pid 指定进程PID进行剖析 profile -p 185
-L, --tid 指定线程TID进行剖析 profile -L 185

堆栈跟踪配置

# 仅分析用户空间堆栈
./profile -U

# 仅分析内核空间堆栈  
./profile -K

# 包含CPU空闲堆栈
./profile -I

# 添加分隔符区分用户/内核堆栈
./profile -d

实际应用案例分析

识别CPU热点函数

通过分析一个简单的计算密集型应用，我们可以清晰地识别性能热点：

# 剖析特定进程的CPU使用情况
./profile -p $(pgrep compute_app) -f 10 > flamegraph_data.txt

典型的输出结果展示了函数调用关系和执行频率：

func_matrix_multiply
compute_algorithm
main
__libc_start_main
[unknown]
-                compute_app (2930)
        64

func_vector_operation  
compute_algorithm
main
__libc_start_main
[unknown]
-                compute_app (2930)
        22

火焰图生成与分析

profile工具支持折叠格式输出，便于生成火焰图进行可视化分析：

# 生成折叠格式数据
./profile -f -p 185 30 > profile.folded

# 使用FlameGraph工具生成SVG
./flamegraph.pl profile.folded > profile.svg

火焰图能够直观展示：

  • 函数调用栈的宽度代表CPU时间占比
  • 调用栈深度反映函数调用关系
  • 颜色编码帮助区分不同模块

高级配置与调优

存储空间优化

对于大规模应用分析，可以调整存储参数：

# 增加哈希表存储容量
./profile --hash-storage-size 81920

# 增加堆栈跟踪存储容量
./profile --stack-storage-size 32768

容器环境支持

profile工具支持容器环境下的性能剖析：

# 针对特定cgroup进行剖析
./profile --cgroupmap /sys/fs/bpf/cgroup_map

# 针对特定mount namespace
./profile --mntnsmap /sys/fs/bpf/mntns_map

性能剖析最佳实践

1. 采样频率选择

根据分析目标选择合适的采样频率：

  • 常规分析: 49-99 Hz（默认49Hz）
  • 精细分析: 199-499 Hz（注意性能开销）
  • 长期监控: 19-29 Hz（降低系统影响）

2. 分析时长控制

# 短期热点分析（5-30秒）
./profile -p 185 10

# 长期趋势分析（1-5分钟）  
./profile -p 185 60

3. 结果解读技巧

  • 关注高频调用路径: 执行次数最多的堆栈通常代表性能热点
  • 识别阻塞操作: 内核系统调用频繁出现可能暗示I/O瓶颈
  • 分析调用关系: 完整的调用链帮助理解应用架构

技术实现细节

profile工具的核心eBPF程序实现了高效的堆栈采样机制：

struct key_t {
    u32 pid;
    u64 kernel_ip;
    int user_stack_id;
    int kernel_stack_id;
    char name[TASK_COMM_LEN];
};

BPF_HASH(counts, struct key_t, u64, HASH_STORAGE_SIZE);
BPF_STACK_TRACE(stack_traces, STACK_STORAGE_SIZE);

这种设计确保了：

  • 内核中完成频率统计，最小化数据传输
  • 支持用户空间和内核空间堆栈跟踪
  • 自动处理PID命名空间转换
  • 高效的哈希表存储和查找

典型应用场景

1. 应用性能优化

通过识别代码中的热点函数，指导性能优化工作：

  • 数学计算密集型函数的算法优化
  • 内存访问模式优化
  • 并行化机会识别

2. 系统瓶颈诊断

分析系统级性能问题：

  • 内核锁竞争分析
  • 系统调用开销评估
  • 中断处理性能分析

3. 容量规划与监控

长期性能趋势分析为容量规划提供数据支持：

  • CPU使用模式分析
  • 负载特征识别
  • 资源需求预测

profile工具作为BCC工具集的核心组件，为系统性能工程师提供了强大的CPU性能剖析能力。其基于eBPF的实现确保了低开销和高效率，使其成为生产环境性能监控的理想选择。通过结合其他BCC工具如offcputime、runqlat等，可以构建完整的系统性能分析解决方案。

cpudist：CPU时间分布统计与诊断

在Linux系统性能监控领域，CPU调度分析是诊断系统瓶颈和优化性能的关键环节。BCC工具集中的cpudist工具提供了强大的CPU时间分布统计能力，能够精确测量任务在CPU上运行(on-CPU)和等待调度(off-CPU)的时间分布，为系统性能分析提供重要数据支撑。

cpudist工具的核心功能

cpudist工具通过eBPF技术在内核层面跟踪任务调度事件，构建CPU时间分布的直方图统计。其主要功能包括：

  • on-CPU时间分析：测量任务在CPU上实际执行的时间分布
  • off-CPU时间分析：测量任务等待调度的时间分布
  • 进程/线程级统计：支持按进程ID或线程ID分别统计
  • 时间单位灵活选择：支持微秒(usecs)和毫秒(msecs)两种时间单位
  • 实时监控能力：支持定时输出和连续监控

cpudist的工作原理

cpudist通过内核探针(kprobe)跟踪finish_task_switch函数，这个函数在内核任务切换时被调用。工具在任务切换时记录时间戳，计算任务在CPU上的运行时间或等待时间。

flowchart TD
    A[任务调度事件发生] --> B[触发finish_task_switch]
    B --> C[记录当前时间戳]
    C --> D{判断任务状态}
    D -->|任务离开CPU| E[计算on-CPU时间]
    D -->|任务进入CPU| F[记录off-CPU开始时间]
    E --> G[更新直方图统计]
    F --> H[等待下一次调度]

使用场景与参数详解

cpudist提供丰富的命令行参数来满足不同的监控需求：

参数 说明 使用示例
-O 测量off-CPU时间 cpudist -O
-T 包含时间戳输出 cpudist -T 5
-m 使用毫秒单位 cpudist -m
-P 按进程ID分别统计 cpudist -P
-L 按线程ID分别统计 cpudist -L
-p PID 只监控特定进程 cpudist -p 185
-I 包含CPU空闲时间 cpudist -I
-e 显示扩展统计信息 cpudist -e

典型输出分析与诊断

cpudist的输出采用直方图形式展示时间分布，每个区间显示该时间段内的任务调度次数和分布比例。

正常系统输出示例：

     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 1        |                                        |
         4 -> 7          : 1        |                                        |
         8 -> 15         : 13       |**                                      |
        16 -> 31         : 187      |****************************************|
        32 -> 63         : 89       |*******************                     |
        64 -> 127        : 26       |*****                                   |

这种分布表明系统相对空闲，任务运行时间主要集中在16-63微秒区间。

过载系统输出示例：

     usecs               : count     distribution
         0 -> 1          : 51       |*                                       |
         2 -> 3          : 395      |***********                             |
         4 -> 7          : 259      |*******                                 |
         8 -> 15         : 61       |*                                       |
        16 -> 31         : 75       |**                                      |
        4096 -> 8191     : 1361     |****************************************|
        8192 -> 16383    : 523      |***************                         |

这种双峰分布表明系统存在资源竞争，部分任务能够长时间运行(4-16ms)，而其他任务频繁被抢占。

高级诊断技巧

1. 进程级分析 使用-p参数可以专注于特定进程的分析：

cpudist -p $(pidof nginx)  # 监控nginx进程的CPU时间分布

2. 线程级细粒度监控 对于多线程应用，使用-L参数可以查看每个线程的调度行为：

cpudist -p $(pidof java) -L  # 监控Java进程所有线程

3. 结合时间戳的时序分析

cpudist -T 5 3  # 每5秒输出一次，共输出3次，包含时间戳

4. 扩展统计信息 使用-e参数获取平均值、总计和计数等扩展信息：

cpudist -e  # 显示平均CPU时间、总时间和调度次数

实际案例诊断

案例1：锁竞争诊断 当观察到大量短时间(0-15μs)的on-CPU时间分布时，通常表明存在锁竞争：

cpudist -p $(pidof database_process)

案例2：CPU过载诊断 如果off-CPU时间分布显示任务长时间等待调度，表明CPU资源不足：

cpudist -O -p $(pidof cpu_intensive_app)

案例3：调度器配置优化 通过分析不同优先级任务的CPU时间分布，可以优化调度器配置：

cpudist -P | grep -E "(high_priority_pid|low_priority_pid)"

技术实现细节

cpudist使用eBPF哈希表存储时间戳信息，通过原子操作更新直方图统计。其核心数据结构包括：

classDiagram
    class entry_key_t {
        +u32 pid
        +u32 cpu
    }
    
    class pid_key_t {
        +u64 id
        +u64 slot
    }
    
    class ext_val_t {
        +u64 total
        +u64 count
    }
    
    class BPF_HASH_start {
        +update()
        +lookup()
    }
    
    class BPF_HISTOGRAM_dist {
        +increment()
        +atomic_increment()
    }
    
    BPF_HASH_start --> entry_key_t : uses
    BPF_HISTOGRAM_dist --> pid_key_t : uses

性能考虑与最佳实践

  1. 采样频率控制：过高的输出频率会影响系统性能，建议根据实际需求调整间隔
  2. 目标进程过滤：使用-p参数减少不必要的监控开销
  3. 生产环境使用：建议在测试环境充分验证后再在生产环境使用
  4. 结合其他工具：与runqlat、profile等工具结合使用，获得更全面的性能视图

cpudist作为BCC工具集中CPU调度分析的核心工具，为系统管理员和性能工程师提供了强大的CPU时间分布诊断能力。通过精确的直方图统计和灵活的配置选项，能够有效识别CPU调度瓶颈、锁竞争、资源过载等性能问题，为系统优化提供数据支撑。

BCC工具集通过eBPF技术实现了高效、低开销的系统性能监控能力。execsnoop提供实时的进程创建监控，runqlat专注于CPU调度延迟分析，profile进行系统性能剖析和热点识别，cpudist则统计CPU时间分布。这些工具相互配合，为Linux系统性能分析提供了全方位的视角。无论是诊断进程创建问题、分析CPU调度瓶颈、识别性能热点，还是优化系统资源分配，BCC工具集都是现代系统监控不可或缺的利器，极大地提升了系统性能分析和优化的效率。

bcc
iovisor/bcc: 是基于 Linux eBPF 的新型网络分析工具，可用于 Linux 系统的性能监控、网络追踪和安全分析等领域。适合对
项目地址：https://gitcode.com/gh_mirrors/bc/bcc
登录后查看全文

相关内容推荐

1 BPF Compiler Collection（BCC）——Linux 内核监控与性能分析的利器2 如何快速掌握 BCC 工具：Linux 系统性能监控的终极指南3 终极指南：如何快速掌握 BPF Compiler Collection (BCC) 开源项目4 深入理解bcc项目中磁盘I/O追踪的实现与内核函数选择5 探索高效监控：gobpf——Go语言的eBPF库6 Surftrace 使用教程7 bpftrace项目中runqlat.bt工具运行问题的分析与解决8 深入分析bcc项目中内核栈追踪的优化问题9 BCC工具集中runqlen对Linux内核调度队列统计字段变更的适配分析10 tracepkt 的安装和配置教程
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
27
11
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
525
3.72 K
pytorchpytorch
Ascend Extension for PyTorch
Python
329
391
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
877
578
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
335
162
flutter_flutterflutter_flutter
暂无简介
Dart
764
189
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台，包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分，采用java语言实现，可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
12
1
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot，Spring Security，JWT，Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.33 K
746
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer（第 2 版）》、《程序员面试金典（第 6 版）》题解
Java
67
20
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
JavaScript
302
350