To perform performance analysis of Go code in the container, you must first enable pprof and expose the port, and then collect data through go tool pprof. The specific steps are: 1. Import the net/http/pprof package in the Go application and start the HTTP server to expose the debugging interface; 2. Open port 6060 through EXPOSE and -p parameters in the container configuration, or use port-forward in Kubernetes; 3. Use go tool pprof http://localhost:6060/debug/pprof/profile and other commands on the host to obtain performance data such as CPU, heap memory or goroutine; 4. Optionally optimize symbol parsing by copying binary files to the host or providing HTTP access; 5. In production environments, the pprof interface should be avoided, and access can be controlled through authentication, firewall, temporary port forwarding or functional switches; in addition, if the port cannot be exposed, you can enter the container to generate a profile file and copy it to local analysis. The entire process needs to ensure network connectivity and symbol parsability, while taking into account security.

Profiling Go code running in a container is a common need when optimizing performance in production-like environments. While containers add a layer of isolation, Go's built-in profiling tools (via the net/http/pprof package) make it surprisingly straightforward — as long as you set things up correctly. Here's how to do it effectively.

1. Enable pprof in Your Go Application

The first step is to expose profiling endpoints using Go's net/http/pprof package. This doesn't require adding new routes if you're already running an HTTP server — just import the package:

 import _ "net/http/pprof"
import "net/http"

// Somewhere in your app
go func() {
    http.ListenAndServe("0.0.0.0:6060", nil)
}()

This automatically registers several profiling endpoints under /debug/pprof/ , such as:

• /debug/pprof/profile – CPU profile (30-second default)
• /debug/pprof/heap – Heap allocation
• /debug/pprof/goroutine – Goroutine dump
• /debug/pprof/block , /debug/pprof/mutex – Contention profiles

? Tip: Use port 6060 or another non-conflicting port. Avoid exposing this on public interfaces in production.

2. Expose the pprof Port in the Container

Make sure the port used by pprof is accessible from the host. In your Dockerfile or container runtime config, expose and publish the port:

 EXPOSE 6060

When running the container:

 docker run -p 6060:6060 my-go-app

If you're using Kubernetes, ensure the port is exposed in the container spec and accessible via port-forwarding:

 kubectl port-forward pod/my-pod 6060:6060

Now localhost:6060/debug/pprof/ on your host maps to the container.

3. Collect Profiles from the Host

Once the port is exposed, use go tool pprof to fetch profiles directly from the containerized app:

CPU Profile (30 seconds)

 go tool pprof http://localhost:6060/debug/pprof/profile

Heap Profile

 go tool pprof http://localhost:6060/debug/pprof/heap

Goroutine Profile

 go tool pprof http://localhost:6060/debug/pprof/goroutine

?? Note: The CPU profile endpoint blocks for 30 seconds by default. Don't use it in production unless you know the impact.

For shorter durations, use query params:

 go tool pprof 'http://localhost:6060/debug/pprof/profile?seconds=10'

4. Optimize Symbol Resolution (Optional but Recommended)

By default, pprof downloads the binary from the container to resolve symbols. If your container doesn't serve the binary over HTTP, you may get:

 Fetching binary from target: <url>
Failed to fetch symbolized binary

To fix this, either:

• Serve the binary via HTTP (eg, copy it to a public path and serve it)
• Copy the binary to the host and point pprof to it:

 # Copy binary from container
docker cp my-container:/path/to/app ./app-binary

# Use it with pprof
go tool pprof -binary ./app-binary http://localhost:6060/debug/pprof/heap

Or build your binary with debug symbols and make sure it's accessible.

5. Security and Production Considerations

While pprof is powerful, exposing it publicly is a security risk:

• Never expose /debug/pprof on public endpoints in production.
• Use authentication , firewall rules, or restrict access to internal networks.
• In Kubernetes, consider using temporary port-forwarding only during debugging.
• Disable or firewall the pprof port in production images when not needed.

Alternatively, enable pprof only behind a feature flag or in debug builds.

Bonus: Profile Without Exposing Ports (Advanced)

If you can't expose ports, you can still generate profiles from inside the container:

1. Exec into the container:

    docker exec -it my-container sh

2. Install curl and go tools (if available), then:

    curl -o cpu.pprof 'http://localhost:6060/debug/pprof/profile?seconds=30'

3. Copy the profile out:

    docker cp my-container:/tmp/cpu.pprof ./cpu.pprof

4. Analyze locally:

    go tool pprof cpu.pprof

   This avoids network exposure but requires shell access.

   ---

   Profiling Go in containers isn't much different from profiling locally — you just need to wire up the network and manage symbol access. With pprof and a bit of container networking, you can get deep insights into CPU, memory, and goroutine behavior.

   Basically: expose the port, import net/http/pprof , and use go tool pprof against the container's endpoint. Just don't leave it open to the internet.

   The above is the detailed content of How to Profile Go Code Running in a Container. For more information, please follow other related articles on the PHP Chinese website!