Skip to content
This repository was archived by the owner on Aug 26, 2026. It is now read-only.

fix(observability): stop dcgm-exporter OOM-crashlooping and quiet pyroscope - #760

Merged
ExtraToast merged 1 commit into
mainfrom
fix/gpu-node-idle-power
Aug 18, 2026
Merged

fix(observability): stop dcgm-exporter OOM-crashlooping and quiet pyroscope#760
ExtraToast merged 1 commit into
mainfrom
fix/gpu-node-idle-power

Conversation

@ExtraToast

Copy link
Copy Markdown
Owner

Problem

dcgm-exporter has been in CrashLoopBackOff on both NVIDIA nodes for a month:

dcgm-exporter-pg79w  enschede-t1000-1     restarts=9398  OOMKilled/137
dcgm-exporter-twf2k  enschede-gtx-960m-1  restarts=8198  OOMKilled/137

Roughly 17,600 OOM kills. Each container starts, logs DCGM successfully initialized!, and is killed with exit 137 about two seconds later. CrashLoopBackOff then settles at its 5-minute ceiling, so each node repeats the cycle 247 times a day with no end state.

Root cause

limits.memory: 256Mi in platform/cluster/flux/apps/observability/nvidia-dcgm-exporter/release.yaml.

The upstream chart defaults to 512Mi, so this override lowered the ceiling. A 4.x exporter's resident set settles near 450 MiB once the DCGM host engine has initialised, which is above the 256Mi cap — the process cannot reach a steady state at that limit regardless of how many times it restarts.

Change

  • dcgm-exporter: limits.memory 256Mi to 1Gi, requests.memory 64Mi to 256Mi. 1Gi leaves headroom above the observed steady state rather than sitting right at the chart default.
  • pyroscope: the chart ships extraArgs.log.level: debug. A single-binary install logs every block flush and memberlist tick at that level and nothing consumes the output, so the release now pins log.level: info under the chart-name key where the chart actually reads it.

Impact

GPU telemetry has been absent fleet-wide for the full month — no DCGM metric exists for either GPU node. That blackout is why idle GPU power draw on enschede-gtx-960m-1 could not be measured while investigating that host's constant load.

The exporter also holds nvidia.com/gpu: 1 (one time-slice) on every one of those 247 daily attempts.

Validation

  • kubectl kustomize platform/cluster/flux/clusters/production builds clean.
  • cd platform/tests && node --test — 56/56 pass.

…oscope

dcgm-exporter had accumulated 8198 restarts on enschede-gtx-960m-1 and
9398 on enschede-t1000-1 — roughly 17,600 OOM kills. Every start died
with exit 137 about two seconds after logging "DCGM successfully
initialized!", then CrashLoopBackOff settled at its 5-minute ceiling, so
each node re-ran the cycle 247 times a day indefinitely.

The cause was `limits.memory: 256Mi` in this HelmRelease. The upstream
chart defaults to 512Mi, and a 4.x exporter's resident set sits near
450 MiB once the DCGM host engine is up, so the override was below the
floor the process needs to reach a steady state. Limits now allow 1Gi
with a 256Mi request.

The practical consequence was a fleet-wide GPU telemetry blackout: no
DCGM metric has been recorded on either GPU node for a month, which is
why idle GPU power draw on the 960M node was invisible.

Separately, the pyroscope chart ships `extraArgs.log.level: debug`. A
single-binary homelab install logs every block flush and memberlist tick
at that level and nothing reads them, so the release now pins
`log.level: info` under the chart-name key where the chart reads it.
@ExtraToast ExtraToast added the bug Something isn't working label Aug 18, 2026
@ExtraToast ExtraToast self-assigned this Aug 18, 2026
@ExtraToast
ExtraToast merged commit d3291f6 into main Aug 18, 2026
22 checks passed
@ExtraToast
ExtraToast deleted the fix/gpu-node-idle-power branch August 18, 2026 20:33
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant