diagnose-perf
Skill34 starsChanged 7 months agoApache-2.0View on GitHub
First-responder performance triage for Isaac Sim and Isaac Lab. Identifies bottleneck category (GPU-bound, CPU-bound, VRAM, loading) using nvidia-smi and system tools without profiling. Use when a user reports slow FPS, stuttering, high latency, or wants a quick health check before profiling. NOT for applying specific fixes (use perf-tuning), capturing traces (use profiling), or analyzing traces (use nsys-analyze).
In this repository12 other files it gives its agents.
- benchmark-isaaclabSkill
- benchmark-isaacsimSkill
- install-isaaclabSkill
- install-isaacsimSkill
- install-profilersSkill
- kit-app-streaming-debugSkill
- nsys-analyzeSkill
- nvtx-pythonSkill
- perf-tuningSkill
- profiling-apiSkill
- profilingSkill
- tracy-memorySkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Run these commands and check for red flags:
- Distinctive: line 58
Start the Isaac workload, then capture GPU metrics while it runs:
- Distinctive: line 81
If the user ran a benchmark skill, check the output JSON for FPS:
- Distinctive: line 97
Use the GPU monitoring data to classify the bottleneck:
- Distinctive: line 125
Do not apply fixes from this skill.
- Very specific: line 127
Need likely fixes now: use perf-tuning with the red flags and bottleneck category.
- Very specific: line 128
Need exact hotspot attribution: use profiling to capture traces, then nsys-analyze.
- Very specific: line 129
Need a benchmark comparison: use benchmark-isaacsim or benchmark-isaaclab for WARM results.
- Distinctive: line 135
After running Phases 1-3, summarize findings in this format:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Performance Diagnosis Guide
Quick triage to identify the most likely performance bottleneck in an Isaac Sim or Isaac Lab workload. This skill does NOT require profiling tools — it uses only nvidia-smi, standard Linux utilities, and Kit config inspection.
For deeper analysis after triage, use the profiling and nsys-analyze skills.
Phase 1 — System Snapshot (no Isaac process needed)
Run these commands and check for red flags:
GPU Info
nvidia-smi -q | grep -E "Product Name|FB Memory Usage|GPU Current Temp|Performance State|Clocks Throttle|Driver Version|CUDA Version|PCIe Generation"Key fields to check:
| Field | Red Flag | Action |
| Performance State | P2 or higher (P3, P8…) | GPU in power-saving mode — run a workload to wake it, or set nvidia-smi -pm 1 |
| Clocks Throttle Reasons | Any "Active" | Thermal or power throttling — check cooling, power limits |
| FB Memory Usage | >90% used at idle | Other processes hogging VRAM — check with nvidia-smi process list |
| PCIe Generation | Gen2 or Gen1 | Bandwidth bottleneck for large scenes — check BIOS/motherboard |
| GPU Current Temp | >85°C | Thermal throttling likely — improve airflow |
CPU Info
# Governor (performance = best for benchmarks)
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort -u
# Core count
nproc
# Current frequency
lscpu | grep "MHz"Red flag: Governor is powersave or schedutil — for benchmarks, performance is recommended:
# Requires root; may be read-only in containers
sudo cpupower frequency-set -g performanceMemory
free -hRed flag: Swap usage > 0 during Isaac runs means system RAM is insufficient.
Phase 2 — Runtime Capture (Isaac process running)
Start the Isaac workload, then capture GPU metrics while it runs:
GPU Monitoring
# Run for 30 seconds alongside the workload
nvidia-smi dmon -s pucm -d 1 -c 30 > /tmp/gpu_monitor.csvColumns: pwr (watts), gtemp (°C), sm (SM utilization %), mem (memory utilization %), fb (VRAM MB used)
Process-Level Check
# Find Isaac process
ISAAC_PID=$(pgrep -f "isaac-sim\|kit\|python.*isaacsim" | head -1)
# CPU and memory usage
top -bn1 -p $ISAAC_PID | tail -1
# Thread count (high = possible thread contention)
ls /proc/$ISAAC_PID/task 2>/dev/null | wc -lQuick Frame Timing (if benchmark outputs JSON)
If the user ran a benchmark skill, check the output JSON for FPS:
cat /tmp/benchmark_output/*.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for phase in data:
for m in phase.get('measurements', []):
metric = m.get('name') or m.get('metric', '')
value = m.get('data', m.get('value'))
if isinstance(metric, str) and ('fps' in metric.lower() or 'time' in metric.lower()) and value is not None:
print(f\"{phase['phase_name']}: {metric} = {value:.2f}\")
"Phase 3 — Bottleneck Classification
Use the GPU monitoring data to classify the bottleneck:
Reading the nvidia-smi dmon Output
# Average SM and memory utilization from capture
awk 'NR>2 && $1!="#" {sm+=$5; mem+=$6; n++} END {printf "Avg SM: %.0f%% Avg MEM: %.0f%%\n", sm/n, mem/n}' /tmp/gpu_monitor.csvDecision Tree
| SM Util | Mem Util | VRAM | CPU | Diagnosis | Handoff |
| >80% | Low | OK | Low | GPU compute-bound (rendering or physics) | Profile with nsys to separate RTX vs PhysX zones |
| Low | >80% | High | Low | VRAM bandwidth-bound | Use perf-tuning for texture/material/Fabric options |
| Low | Low | >95% | Low | VRAM capacity-bound (near OOM) | Use perf-tuning for scene/render-resolution options |
| Low | Low | OK | >80% | CPU-bound | Use perf-tuning for Python/USD/Fabric options |
| High | Low | OK | High | Balanced load (good!) | Already well-utilized — micro-optimize with profiler |
| Low | Low | OK | Low | Idle/waiting | Check if rate-limited, sleeping, or blocked on I/O |
| Spiky | Any | Growing | Any | Loading-bound | Use profiling/nsys-analyze if the loading source is unclear |
Physics vs Rendering (if GPU compute-bound)
Without profiling, check these heuristics:
- Physics-heavy scene (>100 rigid bodies, soft bodies, fluids): likely PhysX-bound
- Camera/lidar-heavy scene (multiple render products): likely render-bound
- Both: profile to separate — use
profilingskill with NVTX markers
Phase 4 — Triage Handoff
Do not apply fixes from this skill. Use the bottleneck classification above to choose the next skill:
- Need likely fixes now: use
perf-tuningwith the red flags and bottleneck category. - Need exact hotspot attribution: use
profilingto capture traces, thennsys-analyze. - Need a benchmark comparison: use
benchmark-isaacsimorbenchmark-isaaclabfor WARM results.
Common handoff topics for perf-tuning: headless/viewport work, Fabric, debug visualization, CPU governor, RTX quality, PhysX settings, collision geometry, and waitIdle/async rendering.
Triage Report Template
After running Phases 1-3, summarize findings in this format:
## Performance Triage Report
### System
- GPU: [model] ([VRAM] GB) — Driver [version], CUDA [version]
- CPU: [model] × [cores] — Governor: [governor]
- RAM: [total] ([used] used, [swap] swap)
- PCIe: Gen[N]
### Red Flags
- [ ] GPU throttling: [yes/no, reason]
- [ ] CPU governor: [performance/powersave/schedutil]
- [ ] VRAM pressure: [usage %]
- [ ] Swap in use: [yes/no]
### Runtime Metrics (30s average)
- GPU SM utilization: [N]%
- GPU memory utilization: [N]%
- VRAM used: [N] MB / [total] MB
- CPU usage: [N]%
### Bottleneck Classification
**[GPU compute / VRAM bandwidth / VRAM capacity / CPU / Loading / Idle]**
### Recommended Actions
1. [Most impactful fix]
2. [Second fix]
3. [If deeper analysis needed: "Profile with nsys — see profiling skill"]Kit Settings Reference
For the full performance settings reference (physics, rendering, app loop), see the perf-tuning skill.
Settings can be applied via:
.kitfiles inapps/directory- CLI:
--/setting/path=value - Python:
carb.settings.get_settings().set("/setting/path", value)
When to Escalate to Full Profiling
This triage identifies the category of bottleneck. For specific hotspots, use:
- profiling skill → capture nsys/Tracy traces
- nsys-analyze skill → analyze traces to find exact functions/zones causing slowdowns
Escalate when:
- Triage shows GPU compute-bound but you need to know if it's physics or rendering
- FPS is inexplicably low despite healthy system metrics
- The user needs frame-by-frame timing breakdown
- Comparing performance between two versions or configurations
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

