pprof | pprof is a tool for visualization and analysis | Monitoring library

Based on the comments, my suggestion is to add $HOME/go/bin to the path and use the default GOPATH.

Go mod depends on the bin directory inside the GOPATH. It installs new packages there. The go binary itself can actually reside somewhere else. If you follow these install instruction https://go.dev/doc/install, go itself will actually be in /usr/local/go but the GOPATH is still $HOME/go.

I would also recommend, not involving apt in this at all. This looks like trouble in the form of conflicts with different installations.

To answer your questions:

How can I release the memory of "encodedString" in this case that it does not pile up?

You cannot and you need not. Unused memory is "freed".

Or is it maybe not my wrong coding, and the mem-leak is at the lib base64 ?

No, package encoding/base64 has no memory leak. (Chances are 0 that you detect a memory leak in a trivial function in the standard library of a garbage collected language.)

To guide you towards a solution:

Your application uses absurd amount of memory but that's because a) processing video and images is memory hungry and b) you seem to do nothing to keep memory low: E.g. you encode the whole image into a bytes.Buffer, then encode the whole bytes.Buffer to a string then work on that string and so on. You probably should encode the image into a stream, encode this stream to base64 and stream this output further to where it deposited. This is totally painless in Go as all these encoders work on io.Writers which can be chained very easily.

By default pprof removes nodes with less than 0.5% of the CPU time and edges with less then 0.1% of the CPU time. You can ask pprof to not do this by supplying the -nodefraction=0 and -edgefraction=0 flags, this might solve your issue.

so as far as I know there shouldn't be any time limitations for collecting stats

Not fully true, runtime/pprof samples 100 times per second. Every time it samples, it captures the full stack-trace. So you might miss functions if they execute faster than 100th of a second and are not part of the stack frame of longer running functions.

You could copy StartCPUProfile and change the hz variable so it captures more often.

Please, try

I think you can just replace this:

You are using a debug value of 2 in pprof.Lookup("goroutine").WriteTo(f, 2). This will produce an output which the pprof tool can't parse, it is meant as directly human readable.

From the pprof.(*Profile).WriteTo docs:

The debug parameter enables additional output. Passing debug=0 writes the gzip-compressed protocol buffer described in https://github.com/google/pprof/tree/master/proto#overview. Passing debug=1 writes the legacy text format with comments translating addresses to function names and line numbers, so that a programmer can read the profile without tools.

The predefined profiles may assign meaning to other debug values; for example, when printing the "goroutine" profile, debug=2 means to print the goroutine stacks in the same form that a Go program uses when dying due to an unrecovered panic.

Changing this line to pprof.Lookup("goroutine").WriteTo(f, 0) resolves the issue.

Also, not relevant to the issue, but you might want to consider closing the file f.Close() before using it in the pprof command. WriteTo should flush the file to disk, but it can't hurt.

Why doesn’t -call_tree affect this output of -tree

I think the -call_tree option doesn't change the output of -tree the outputs are not actually a tree, it outputs the nodes of the tree(more on this in the extra credit section).

In general, what does -call_tree do?

You can see a difference when you take a look at images generated with the -png flag, without the -call_tree flag: And with the -call_tree flag:

So instead of having 1 call tree, pprof attempts to create seperate trees based on context. In my case(will list them since the text on the image is not readable) the roots are:

• testing.(*B).launch (benchmark/test framework)
• runtime.gcBgMarkWorker (part of the runtime GC)
• runtime.bgsweep (part of the runtime GC)
• runtime.mcall (part of the runtime scheduler)
• runtime.morestack (something to do with the stack :) )

In the non -call_tree image these nodes are still present, but start mid tree, as if our code calls these background processed directly.

Basically basically what the option does is remove/hide infrequent calls between functions, so you will end up with a tree for each set of functions that call each other frequently.

I haven't tested this but I imagine that pprof will do this context aware tree separation for user code as well. All in all it returns a subjectively more readable tree, or at least a more relevant one.

What is the exact meaning of the output node I showed above?

The -tree option attempts to output the tree, as shows in the images. But since it is text output it shows you 1 node of the tree at a time, the non indented line in the context column is the current node, the rows above are nodes that call the current node, the rows below the nodes which this one calls (the arrows in the image).

The calls% is a the "weight" of the the incoming or outgoing edge, so indeed the percentage of calls from or to a function.

What documents could I read to answer the above questions?

If figured all of this out by looking at the source code, here are some key parts, in case you are interested:

• The file which does most of the output generation: https://github.com/google/pprof/blob/2007db6d4f53c44a417ddae675d50f56b8e8c2fd/internal/report/report.go
• The function for the -tree option: https://github.com/google/pprof/blob/2007db6d4f53c44a417ddae675d50f56b8e8c2fd/internal/report/report.go#L1047
• Line which explains when -call_tree is actually used: https://github.com/google/pprof/blob/2007db6d4f53c44a417ddae675d50f56b8e8c2fd/internal/report/report.go#L133

The workflow-controller itself, which is running in the argo namespace with the argo ServiceAccount, needs permissions to patch the ConfigMap. The workflow-controller is modifying the ConfigMap on behalf of the Workflow. The Workflow itself does not modify the ConfigMap.

It appears to be a typo in the configuration file. As stated in the documentation, the configuration file should hold http-bind-address instead of bind-address. As well as a locked port by the first configuration.

The first few lines of the file /etc/influxdb/influxdb.conf should look like so: