【问题标题】:The "%" column of opreport always shows 0.0000opreport 的“%”列始终显示 0.0000
【发布时间】:2012-04-17 09:02:09
【问题描述】:

我正在使用 oprofile 来调整我的应用程序的性能。 以下是我收集分析数据的方式:

platform info: virtual machine (KVM-based), linux kernel 2.6.21, x86 64bit, 

1. opcontrol --init
2. opcontrol --no-vmlinux -p library -c 100
3. opcontrol --status

Separate options: library
vmlinux file: none
Image filter: none
Call-graph depth: 100

4. opcontrol -s
5. /*running my application*/
6. opcontrol -h
7. opreport -l my_application

20136     0.0000  no-vmlinux               no-vmlinux               /no-vmlinux
1311      0.0000  libcrypto.so.0.9.8       lighttpd                 /opt/ccnsr/lib64/libcrypto.so.0.9.8
455       0.0000  libxml2.so.2.6.26        my_application                     /opt/ccnsr/lib64/libxml2.so.2.6.26
350       0.0000  libc-2.5.90.so           my_application           _int_malloc
195       0.0000  libpython2.4.so.1.0      python                   PyEval_EvalFrame
142       0.0000  libc-2.5.90.so           my_application           vfprintf
79        0.0000  libc-2.5.90.so           my_application           _IO_default_xsputn

opreport的“%”栏总是显示0.0000!

【问题讨论】:

    标签: profiling oprofile


    【解决方案1】:

    如果您编写一个主要执行 I/O 的小应用程序,并在挂钟(而不是 CPU)时间上进行采样,并显示独占百分比,您会看到每个百分比都非常接近于零。

    原因是程序几乎所有时间都在等待先前启动的 IO 完成。 因此,与花在等待上的时间相比,它在 any 例程中花费的时间几乎为零。

    【讨论】:

    • 根本原因似乎是定制的glibc和gcc不匹配,导致浮动计算失败。感谢您的回复。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-25
    • 2020-08-11
    • 1970-01-01
    • 1970-01-01
    • 2012-12-12
    相关资源
    最近更新 更多