/debug/pprof/*

The debug/pprof paths provided by the Go profiling tool (pprof) expose several types of profiling data, which are essential for diagnosing performance issues in applications, particularly those written in Go (including many Kubernetes components). Here’s a rundown of what each of the primary pprof profiles represents and who typically uses and understands them:

Types of Profiles

1. CPU Profile (/debug/pprof/profile):

   • What it measures: Records where the application spends its time in the CPU.
   • Use case: Identify functions or areas in the code consuming excessive CPU time.
   • Common users: Developers and performance engineers interested in CPU optimization.

2. Heap Profile (/debug/pprof/heap):

   • What it measures: Captures the memory allocation of live objects (those still reachable by the application).
   • Use case: Identify memory leaks, frequent allocations, and memory bloat.
   • Common users: Developers debugging memory issues like leaks or high memory usage.

3. Goroutine Profile (/debug/pprof/goroutine):

   • What it measures: Lists all current goroutines, showing stack traces.
   • Use case: Used to analyze concurrency issues such as deadlocks or heavy use of goroutines.
   • Common users: Developers working on highly concurrent systems and needing to understand threading and concurrency behaviors.

4. Block Profile (/debug/pprof/block):

   • What it measures: Measures where goroutines block on synchronization primitives (e.g., mutexes, channel operations).
   • Use case: Diagnose contention issues where goroutines are delayed by blocking on shared resources.
   • Common users: Developers optimizing performance-critical sections where synchronization is important.

5. Threadcreate Profile (/debug/pprof/threadcreate):

   • What it measures: Shows stack traces that led to the creation of new OS threads by the Go runtime.
   • Use case: Understand thread usage and potential issues with excessive thread creation.
   • Common users: System architects and developers interested in the low-level behavior of threading in applications.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: x.x.x.x:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=x.x.x.x
    - --allow-privileged=true
      #- --profiling=false
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt

$ kubectl proxy &

$ go tool pprof http://localhost:8001/api/v1/nodes/{NODE-NAME}/proxy/debug/pprof/profile