问题标签 [pprof]

我对这个pprof工具有点陌生，我想知道在生产中继续运行它是否可以。从我看到的文章来看，这似乎是好的和标准的，但是我很困惑这不会影响性能，因为它N每秒都会进行一次采样，以及为什么这不会导致性能下降。

我在 Go中jemalloc使用。cgo我还想获取堆配置文件。目前，我正在获取配置文件，但它没有显示相应的 go 代码。

如果我使用它构建它go build example.go，然后使用它查看配置文件jeprof ./example test.349341.0.m0.heap --lines，我会在顶部得到这个输出。

从相应的 go 代码中获取行的正确方法是什么？提前致谢。

我正在运行一个用 Go 编写的服务器，并且 RSS 非常高，甚至没有释放内存（回到操作系统）。

我使用 pprof 进行检查，但似乎没有内存泄漏。

我也试过：

请告诉我如何使用 madvdontneed。

代码：

输出：</p>

我有一个 go-app，我必须在其中比较 pprof 输出。为此main，我在函数中创建了一个cpuProfiler并启动它。我有一个跟踪退出信号的程序。之后，我启动我infinitely正在运行的函数，除非它们被使用输入中断（应用程序无限运行，除非有键盘中断）。我让应用程序运行了一段时间，希望在指定的 pprof 文件中捕获元数据，但该文件始终为空。请注意，我确实通过调用来终止分析stopCPUProfile。

我究竟做错了什么？

提前致谢。

我正在使用 Go 的 pprof 工具来调查我的服务的内存使用情况。几乎所有的内存使用都来自一个设置多个有界队列通道的函数。我对 pprof 在这里告诉我的内容有些困惑：

看起来第 142 行负责 19.50MB 的分配，第 146 行负责 27.53MB，但这些行做同样的事情 - 它们创建具有相同输入类型和相同容量的缓冲通道。

• 这是 pprof 进行随机抽样这一事实的产物吗？
• Go 是否会延迟分配通道（fwiw，在让服务运行几天后，这些值最终会均衡）？
• pprof 是否报告了沿通道发送的对象所需的内存以及通道本身所需的内存？

我正在使用 pprof 检查我的 Go 服务器是否存在内存泄漏。

到目前为止，一切都很好，但我仍然希望有一件事。

有没有办法显示特定结构类型（或函数）的分配计数？

top用例：我在运行时看到了一些分配pprof -inuse_space。

其中之一是NewFoo() *Foo类型函数，它创建Foo结构的实例。

现在我想检查这些结构中有多少Foo实际上存在。

切换到pprof -inuse_objects不显示Foo或NewFoo在 的输出中top，好的，这些结构并不多。但我想知道有多少。

有办法吗？

我正在尝试分析一个用c++. 我已经pprof安装了必要的环境变量，以便pprof找到该命令。我正在尝试按照文档获取我的程序的 svg。

这是我尝试过的：

pprof sort profile.pb.gz，sort位于我当前目录中的程序的名称在哪里（我也尝试过使用 ./sort），而 profile.pb.gz 是我认为根据文档应该生成的输出。

当我运行它时，我收到以下错误消息：

我也尝试在我的 Makefile 中使用不同的标志，但不会包含它们，因为没有一个有效，我愿意接受有关测试不同标志的建议。我对 pprof 完全陌生，所以这可能是一个简单的错误。

此外，运行时如何添加命令行参数？我想通过一些。

此外，我想添加我的目标，以防pprof可能不是我正在寻找的工具：

1. 查找性能瓶颈，查看我的程序在哪里花费最多的时间
2. 可能会生成调用图以更好地可视化堆栈跟踪。

最近我想分析我的 cpp 代码并遇到了 gperftool，但是关于如何在 Mac 上使用它并没有真正明确的说明。到目前为止，我已经运行brew install gperftools并想编译我的简单 cpp 文件，它只输出“Hello world！”。我运行g++ main.cpp -lprofiler -o main但得到错误ld: library not found for -lprofiler。如果你能指导我或者应该给我一个易于遵循的教程，我真的很感激。谢谢 ：）

编辑：目前我正在使用带有新 M1 芯片的 MacOS（不确定这是否会导致任何问题）

我们的管道是基于 Apache Beam Go SDK 开发的。我正在尝试通过设置标志来分析所有工作人员的 CPU --cpu_profiling=gs://gs_location：https ://github.com/apache/beam/blob/master/sdks/go/pkg/beam/runners/dataflow/dataflow.go

这项工作以花费 16.636 个 vCPU 小时和最多 104 个工作人员完成：

结果在指定的 GCS 位置，记录了一堆名为“profprocess_bundle-*”的文件：

然后我下载了这些文件，将它们全部解压缩，并使用 pprof ( https://github.com/google/pprof ) 可视化结果：

所以这是我的问题：

1. 分析结果中的总时间是如何收集的？采样时间（1.06 小时）比 Dataflow 报告的 vCPU 时间（16.626 小时）短得多。

2. 文件名“profprocess_bundle-*”中的数字是多少？我在想它可能对应于工人的指数。但是数量的最大值大于工人数量，并且数量不连续。最大数量为 122，但只有 66 个文件。

在 kubernetes 源代码中有一段代码可以处理分析部分，但我无法访问端点：

我不知道 pprof 工具使用的端口，但我发现它使用：

然后我试过了

有没有人知道我应该尝试什么来访问 pprof 端点？或者如何尝试不同的方法来分析 kubelet 进程？