存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载本指南面向 Ceph 开发者与集群运维人员介绍如何对 Ceph 守护进程如ceph-osd、ceph-mon、ceph-mds进行 CPU 消耗剖析。文章以官方开发文档 doc/dev/cpu-profiler.rst 为主线完整覆盖两种剖析路线经典的全系统剖析工具 OProfile含专门为剖析编译 Ceph 的方法以及现代 Linux 内置的perf含调用图与火焰图生成并给出剖析前必须完成的 Ceph 配置禁用 lockdep、合理设置日志级别。读完本文你将能够独立完成「安装剖析工具 → 为剖析重编 Ceph → 采集 CPU 采样 → 解读调用图」的完整流程。为什么需要剖析 Ceph 的 CPU 消耗Ceph 是分布式对象、块与文件存储平台其守护进程在单个节点上会同时承载大量 I/O 与网络线程。当出现性能瓶颈时最直接的排查手段就是回答一个问题CPU 时间花在了哪些函数上剖析profiling通过周期性采样或硬件计数器把 CPU 时间按函数、调用路径归因帮助开发者快速定位热点。官方开发文档指出剖析 Ceph CPU 消耗最简便的方式是使用 OProfile 这类全系统system-wide剖析器。同时随着 Linux 内核的发展perf已成为更主流的选择——它的优势在于无需为剖析专门重新编译 Ceph直接使用 release 包即可工作详见 doc/rados/troubleshooting/cpu-profiling.rst。下文先完整还原文档中的 OProfile 路线再补充perf的完整操作。一、OProfile 路线安装、重编 Ceph 并采集调用图1.1 安装 OProfileOProfile 是 Linux 上的全系统性能剖析器通过内核采样事件如 CPU 时钟周期收集数据且无需修改被剖析的应用程序。在 Debian/Ubuntu 发行版上官方文档给出的安装命令为sudo apt-get install oprofile oprofile-gui其中oprofile-gui提供了图形界面便于可视化查看采样结果。RPM 系发行版Fedora/RHEL/CentOS可使用dnf install oprofile或yum install oprofile安装等价软件包。1.2 为剖析重新编译 CephOProfile 若想输出函数名与调用图callgraph必须保证二进制的符号表和帧指针frame pointer信息可用。官方文档要求对 Ceph 进行专门编译步骤如下。第一步彻底清理构建残留git clean -dfxgit clean -dfx会删除工作区中所有未被 Git 跟踪的文件包括之前的build目录、CMake 缓存、编译产物确保后续配置基于干净源码树。第二步带剖析标志重新配置并编译./do-cmake.sh -DCMAKE_CXX_FLAGS-fno-omit-frame-pointer -O2 -g cd build cmake --build .关键参数说明-fno-omit-frame-pointer核心参数。-O2优化级别默认会启用-fomit-frame-pointer省略帧指针这会阻止基于栈的剖析器获取完整的调用栈信息。显式关闭它OProfile/perf 才能回溯出完整调用链详见 doc/dev/perf.rst 中的 Common Issues 一节。-O2保持优化级别使剖析结果贴近真实生产性能。-g生成调试符号供剖析器把地址解析为函数名。文档特别强调指定CMAKE_CXX_FLAGS正是为了获得调用图callgraph输出——没有帧指针时调用图回溯会在第一层栈帧处中断。关于do_cmake.sh仓库根目录的 do_cmake.sh 是官方提供的 CMake 配置封装脚本默认使用 Ninja 生成器-GNinja并根据发行版自动选择 Python 版本、检测并启用 sccache/ccache 加速编译同时支持通过BUILD_DIR环境变量自定义构建目录。脚本还会在检测到源码目录存在.git时默认创建 debug 构建并打印性能警告若需性能敏感的构建请显式追加-DCMAKE_BUILD_TYPERelWithDebInfo。1.3 使用 OProfile 采集与查看结果重编并启动 Ceph 守护进程后按以下流程采集# 重置采样数据root 权限 sudo opcontrol --reset # 启动全系统采样 sudo opcontrol --start # 运行你的工作负载一段时间后停止 sudo opcontrol --stop # 生成调用图报告按 CPU 消耗排序 opreport -l --callgraphopreport -l输出每个函数的采样计数CPU 时间占比--callgraph展示调用者与被调用者关系结合-fno-omit-frame-pointer编译出的二进制即可看到完整热点调用链。也可使用oprofile-gui以图形方式浏览。二、perf 路线无需重编即可定位热点相比 OProfileperf是当前 Linux 生态更常用的剖析工具。按 doc/rados/troubleshooting/cpu-profiling.rst 的说明perf与 release 包直接兼容不需要为剖析专门编译 Ceph只需为待剖析的守护进程安装调试符号perf即可解析函数名Debian 系-dbg包例如ceph-osd-dbgRPM 系-debuginfo包。以下命令均需 root 权限且应在守护进程所在宿主机上执行。2.1 定位目标进程使用pgrep -a列出本机所有ceph-osd进程及其命令行命令行中包含 OSD IDpgrep -a ceph-osd例如输出12345 ... ceph-osd -i 3表示 PID 为12345的osd.3进程。同理可用pgrep -a ceph-mon、pgrep -a ceph-mds定位其他守护进程。2.2 实时观察热点perf topperf top -p {pid}perf top会持续刷新显示目标进程 CPU 时间占比最高的函数列表适合快速验证热点在哪里。2.3 录制采样并生成调用图perf record/report# 录制 60 秒采样包含调用图 perf record -p {pid} -F 99 --call-graph dwarf -- sleep 60 # 查看报告caller 视图展示每个顶级函数调用了什么 perf report --call-graph caller # callee 视图展示是谁调用了每个顶级函数 perf report --call-graph callee参数解释-F 99采样频率 99 Hz即每秒约 99 次采样避免对繁忙守护进程造成过多干扰。--call-graph dwarf通过 DWARF 调试信息回溯调用栈。-- sleep 60让perf跟随sleep60 秒即采样窗口为 60 秒。注意--call-graph dwarf会在每次采样时复制部分栈内容产生的数据文件可能非常大。文档特别建议在繁忙守护进程上保持较低采样频率如-F 99并缩短采样时长。若希望使用更省开销的--call-graph fp模式则必须按第一节的方法用-fno-omit-frame-pointer重编 Ceph详见 doc/dev/perf.rst。2.4 生成火焰图doc/dev/perf.rst 还给出了从录制数据生成火焰图flamegraph的完整流程# 录制采样与上文相同 sudo perf record -p pidof ceph-osd -F 99 --call-graph dwarf -- sleep 60 # 转换为火焰图 sudo perf script | ~/src/FlameGraph/stackcollapse-perf.pl /tmp/folded ~/src/FlameGraph/flamegraph.pl /tmp/folded /tmp/perf.svg # 浏览器打开 firefox /tmp/perf.svg前置步骤为克隆 Brendan Gregg 的 FlameGraph 工具集到~/src/FlameGraph。火焰图以 SVG 形式直观展示 CPU 时间的调用路径分布宽条代表消耗 CPU 多的栈路径。提示若caller与callee视图显示相同可能是内核 bug 所致建议升级到内核 4.8 或更高版本来源doc/dev/perf.rst。三、剖析前的 Ceph 配置准备无论是 OProfile 还是 perf剖析前都应调整 Ceph 运行配置避免干扰采样结果。官方文档明确要求两件事。3.1 禁用 lockdeplockdep 是 Ceph 的锁依赖分析器用于在开发阶段检测死锁。它会在每次加锁时记录锁的获取顺序与持有者信息带来可观的 CPU 与内存开销且其自身的处理逻辑会污染采样热点。在配置文件中/etc/ceph/ceph.conf显式关闭[global] lockdep false从源码看src/common/options/global.yaml.in 中lockdep的默认值即为falsetype: bool、level: dev、标记为startup启动参数属于开发级别dev选项不应用于生产。其实现位于 src/common/lockdep.cc维护follows[a][b]矩阵记录锁的获取先后顺序一旦检测到循环依赖即报告死锁。这一机制在开发期价值极高但会显著拖慢加锁路径因此剖析性能时必须关闭。相关选项还有lockdep_force_backtrace每次加锁时收集当前 backtrace同样默认false。3.2 将日志级别调至接近生产水平Ceph 子系统日志等级范围为 1精简到 20极详细详细日志dout()输出本身就是性能杀手——doc/rados/troubleshooting/log-and-debug.rst 明确警告详尽日志每小时可能产生超过 1 GB 数据且调试输出会拖慢系统、掩盖竞态条件。剖析时应采用接近生产集群的日志级别例如[global] debug_ms 1/5 [osd] debug_osd 1/5 debug_filestore 1/5 debug_journal 1 debug_monc 5/20 [mon] debug_mon 20 debug_paxos 1/5 debug_auth 2 [mds] debug_mds 1 debug_mds_balancer 1其中x/y形式中第一个值是该子系统的日志级别写入输出日志第二个值是内存级别仅驻留内存出错时转储只写单个值则两者相同。完整配置示例见 doc/rados/troubleshooting/log-and-debug.rst。3.3 剖析期间的配置调整手段若剖析时希望临时改变运行中守护进程的日志级别无需重启可注入运行时配置# 查看当前配置 ceph daemon osd.0 config show | less # 通过 monitor 下发对所有 osd 生效 ceph tell osd.* config set debug_osd 0/5 # 或直接登录守护进程宿主机设置单个 daemon sudo ceph daemon osd.0 config set debug_osd 0/5将上述参数降到生产水平后再启动剖析采样即可获得接近真实负载的 CPU 热点分布。四、常见问题与排查要点问题现象原因与解决调用图只显示第一层函数-O2默认开启-fomit-frame-pointer栈回溯被截断。用-fno-omit-frame-pointer重编 Cephdoc/dev/perf.rstperf report显示地址而非函数名未安装调试符号。Debian 系装ceph-osd-dbg等-dbg包RPM 系装-debuginfo包perf record数据文件过大--call-graph dwarf每次采样复制部分栈降低-F频率并缩短采样时长caller/callee视图相同内核 4.8 之前的已知 bug升级内核剖析结果大量命中 lockdep/日志代码未关闭lockdep或日志级别过高参照第三节调整总结本文以 doc/dev/cpu-profiler.rst 为骨架完整覆盖了两条 Ceph CPU 剖析路线OProfile 路线sudo apt-get install oprofile oprofile-gui安装git clean -dfx清理后用./do-cmake.sh -DCMAKE_CXX_FLAGS-fno-omit-frame-pointer -O2 -g重编 Ceph 以获得调用图支持再通过opcontrol采集。perf 路线无需重编安装调试符号后用pgrep -a找进程、perf top -p {pid}实时观察、perf record/report录制与分析调用图、配合 FlameGraph 生成火焰图。无论哪条路线剖析前都应在 ceph.conf 中关闭 lockdep 并压低日志级别确保采样结果反映真实业务热点而非调试基础设施的开销。进一步可参考 doc/rados/troubleshooting/cpu-profiling.rst 与 doc/dev/perf.rst 获取更多 perf 细节。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Ceph 守护进程 CPU 性能剖析实战指南使用 perf 定位 CPU 热点Ceph 守护进程 CPU 性能剖析实战指南使用 perf 定位 CPU 热点 导读 本指南基于 Ceph 官方故障排查文档 doc/rados/troubl存储分布式文件系统对象存储后端高可用Ceph 性能剖析实战使用 Linux perf 与火焰图定位 ceph-osd CPU 热点Ceph 性能剖析实战使用 Linux perf 与火焰图定位 ceph osd CPU 热点 本指南围绕 doc/dev/perf.rst https://存储分布式文件系统对象存储后端高可用使用 perf 剖析 ScyllaDB定位 Pegged Shard 与 CPU 热点使用 perf 剖析 ScyllaDB定位 Pegged Shard 与 CPU 热点 ScyllaDB 基于 Seastar 的线程 per 核threa数据库分布式数据库后端大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考