gpt4 book ai didi

docker - docker 容器停止后 perf 无法解析符号

转载 作者:行者123 更新时间:2023-12-02 18:18:21 24 4
gpt4 key购买 nike

我正在使用在 docker 容器中运行的性能分析 golang 程序

我记录数据

# perf record -o "perf.data" -p `PID of the container`

并阅读

# perf report -i "perf.data"

一开始一切正常,我得到这样的报告(我的 elf 二进制名称是 bin):

Samples: 15  of event 'cpu-clock', Event count (approx.): 3750000
Overhead Command Shared Object Symbol
53.33% bin bin [.] runtime.scanobject
6.67% bin [kernel.kallsyms] [k] __schedule
6.67% bin bin [.] runtime.getStackMap
6.67% bin bin [.] runtime.getempty
6.67% bin bin [.] runtime.gopark
6.67% bin bin [.] runtime.greyobject
6.67% bin bin [.] runtime.scanblock
6.67% bin bin [.] runtime.unlock

但是在我停止容器并再次运行报告命令之后,我程序中的所有符号都变成了十六进制地址(内核符号仍然解析)

Samples: 15  of event 'cpu-clock', Event count (approx.): 3750000
Overhead Command Shared Object Symbol
33.33% bin bin [.] 0x000000000001f7ad
13.33% bin bin [.] 0x000000000001f7b0
6.67% bin [kernel.kallsyms] [k] __schedule
6.67% bin bin [.] 0x000000000000ac1a
6.67% bin bin [.] 0x000000000001f497
6.67% bin bin [.] 0x000000000001f7d6
6.67% bin bin [.] 0x000000000001fc82
6.67% bin bin [.] 0x00000000000242fd
6.67% bin bin [.] 0x0000000000035bf0
6.67% bin bin [.] 0x000000000004d5a9

我试图找到二进制文件的构建 ID,但没有得到任何线索:

# perf buildid-list -i perf.data
38b62c386e959108a2ff514c04f7df8f39e443f9 [kernel.kallsyms]
78fa50e860a2bb2b44f03a6a0a6f99735a8b599b [vdso]

根据@osgx 的建议,我在下面运行命令

#perf script -D |grep PERF_RECORD_MMAP2|head
Failed to open /bin, continuing without symbols
0 0x2b98 [0x60]: PERF_RECORD_MMAP2 15956/15956: [0x400000(0x852000) @ 0 fc:01 656204 7434654850458070581]: r-xp /bin
0 0x2bf8 [0x60]: PERF_RECORD_MMAP2 15956/15956: [0x7ffca95a8000(0x2000) @ 0 00:00 0 7434654850458070581]: r-xp [vdso]
0 0x2c58 [0x68]: PERF_RECORD_MMAP2 15956/15956: [0xffffffffff600000(0x1000) @ 0 00:00 0 7434654850458070581]: r-xp [vsyscall]
0 0x2ce8 [0x60]: PERF_RECORD_MMAP2 15956/16020: [0x400000(0x852000) @ 0 fc:01 656204 7434654850458070581]: r-xp /bin
0 0x2d48 [0x60]: PERF_RECORD_MMAP2 15956/16020: [0x7ffca95a8000(0x2000) @ 0 00:00 0 7434654850458070581]: r-xp [vdso]
0 0x2da8 [0x68]: PERF_RECORD_MMAP2 15956/16020: [0xffffffffff600000(0x1000) @ 0 00:00 0 7434654850458070581]: r-xp [vsyscall]
0 0x2e38 [0x60]: PERF_RECORD_MMAP2 15956/16021: [0x400000(0x852000) @ 0 fc:01 656204 7434654850458070581]: r-xp /bin
0 0x2e98 [0x60]: PERF_RECORD_MMAP2 15956/16021: [0x7ffca95a8000(0x2000) @ 0 00:00 0 7434654850458070581]: r-xp [vdso]
0 0x2ef8 [0x68]: PERF_RECORD_MMAP2 15956/16021: [0xffffffffff600000(0x1000) @ 0 00:00 0 7434654850458070581]: r-xp [vsyscall]
0 0x2f88 [0x60]: PERF_RECORD_MMAP2 15956/16022: [0x400000(0x852000) @ 0 fc:01 656204 7434654850458070581]: r-xp /bin

为什么会这样?有什么解决方案让 perf 在容器停止后解析符号吗?

这是我的环境:

perf version 4.15.18
Ubuntu 18.04 LTS (GNU/Linux 4.15.0-23-generic x86_64)
docker version 18.06.1-ce

我的容器 Dockerfile

FROM scratch
COPY artifact/bin /
ENTRYPOINT ["/bin"]

最佳答案

Why is that happen?

perf 工具正在对二进制文件进行某种搜索。在 perf.data 中记录了 mmap(使用 perf script -D |grep PERF_RECORD_MMAP2|head 命令查看),其中文件路径映射到 EXEC 权限。主二进制文件也被映射,但在映射时路径是相对于容器的。在容器中,此文件具有 /bin 路径,就像您使用 COPY artifact/bin/ 放置它一样。但是 perf report 是在容器外部启动的,并尝试在容器 fs cgroup/namespace 之外解析 /bin 路径。在主机系统中 /bin 是目录,而不是文件。当您在容器仍在运行时启动 perf report 时,它可能会通过一些启发式方法在 /proc/$PID/exe 特殊 fs 的帮助下获取可执行文件,这可能会成功在访问容器 fs 命名空间内的文件时。

Is there any solution let perf resolve symbol after container stop ?

我没有太好的建议(在评论中):将工件二进制文件放入容器中的路径,该路径与二进制文件的实际位置相等。例如,如果您将二进制文件作为 /home/pexie/project1/artifact/bin;在 dockerfile 中创建目录 /home/pexie/project1/artifact/ 并将二进制文件放入该目录。

关于docker - docker 容器停止后 perf 无法解析符号,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60880117/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com