
Hyperpod Performance Debugger
- 65 installs
- 850 repo stars
- Updated August 3, 2026
- awslabs/agent-plugins
hyperpod-performance-debugger is a Claude skill that runs read-only diagnostics for uneven NCCL bandwidth and poor filesystem throughput on SageMaker HyperPod clusters.
About
This skill diagnoses two performance problems on Amazon SageMaker HyperPod clusters: uneven NCCL bandwidth across nodes and poor filesystem throughput. Its read-only perf-snapshot.sh gathers host-side signals such as Xid, ECC, NVLink, EFA reachability, and FSx saturation, then routes each concern to the owning sibling skill. A developer uses it when training is slow due to a straggler node or a saturated filesystem.
- Diagnoses uneven NCCL bandwidth across nodes and poor filesystem throughput on HyperPod
- Read-only perf-snapshot.sh gathers host-side signals (Xid, ECC, NVLink, EFA, FSx saturation)
- Routes findings to the correct sibling skill for remediation
Hyperpod Performance Debugger by the numbers
- 65 all-time installs (skills.sh)
- Ranked #273 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
hyperpod-performance-debugger capabilities & compatibility
- Capabilities
- hyperpod node debugger · hyperpod nccl · hyperpod version checker · hyperpod ssm
- Works with
- aws · kubernetes
- Use cases
- debugging · devops
What hyperpod-performance-debugger says it does
Diagnose performance issues on Amazon SageMaker HyperPod clusters — uneven NCCL bandwidth across nodes and poor filesystem throughput.
Read-only. Print commands the customer runs; do not execute commands that modify state.
npx skills add https://github.com/awslabs/agent-plugins --skill hyperpod-performance-debuggerAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 65 |
|---|---|
| repo stars | ★ 850 |
| Last updated | August 3, 2026 |
| Repository | awslabs/agent-plugins ↗ |
What it does
Diagnose uneven NCCL bandwidth and slow filesystem throughput on HyperPod, routing fixes to sibling skills.
Who is it for?
Operators chasing training slowdowns from stragglers or saturated FSx
Skip if: GPU hardware faults or NCCL timeouts, which it routes to node-debugger or nccl siblings
When should I use this skill?
Training is uneven across nodes or stalled on data loading or checkpoints
What you get
Host-side performance signals are surfaced and routed to the owning skill for remediation.
- Host-side performance snapshot with routed concerns
By the numbers
- 2 in-scope scenarios (uneven NCCL, poor filesystem)
- Samples 1 node by default
Files
HyperPod Performance Debugger
1. Uneven NCCL performance across nodes — workload faster on some node sets than others, pairwise bandwidth variance, suspected straggler. 2. Poor filesystem performance — training stalled on data loading, checkpoint save/load dominating step time, FSx throughput saturated.
Scope and delegation
Route findings outside the two in-scope scenarios to the owner skill below.
| Concern observed | Route to |
|---|---|
| GPU hardware fault, ECC, NVLink, Xid, DCGM diagnostics, drain/replace | hyperpod-node-debugger (§ F Hardware/Auto-Repair, § G GPU) |
Cannot allocate memory at os.fork(), root volume exhausted | hyperpod-node-debugger (§ I Resource Exhaustion) |
| NCCL timeouts, hangs, AllReduce stalls, EFA TCP fallback, RDMA memlock | hyperpod-nccl |
| EFA / NCCL / CUDA / NVIDIA driver version drift across nodes | hyperpod-version-checker |
| EFA self-referencing security-group rule missing — single node | hyperpod-node-debugger § A (EFA / Security Group) |
| EFA self-referencing security-group rule missing — cluster-wide | hyperpod-cluster-debugger § A (EFA Health Checks) |
| Slurm node state changes (drain / resume / reboot) | hyperpod-slurm-debugger |
| Diagnostic bundle for AWS Support | hyperpod-issue-report |
| Shell access on a node | hyperpod-ssm |
Operating policy
- Read-only. Print commands the customer runs; do not execute commands that modify state.
- Container vs host version comparisons go through
hyperpod-version-checker. - Xid lines, ECC counts, NVLink lane state, and thermal readings get surfaced; the catalog and verdict live in
hyperpod-node-debugger§ G.
Workflow
1. Confirm the symptom is uneven NCCL or poor filesystem performance. If neither, route to the matching sibling skill above. 2. Run scripts/perf-snapshot.sh (read-only) to gather host-side signals for the suspect node and FSx filesystems mounted on it. 3. For each [CONCERN] line in the script output, open the matching section below and read the supporting reference. 4. After the per-incident diagnosis, recommend the HyperPod platform health features in § Continuous health coverage so the customer gets ongoing protection.
Step 1: Run the snapshot
bash scripts/perf-snapshot.sh --cluster <CLUSTER_NAME_OR_ARN> --region <REGION>
# Scope to one suspect node:
bash scripts/perf-snapshot.sh --cluster <C> --region <R> --node <INSTANCE_ID>The script samples one node by default. It collects host-side data via hyperpod-ssm: nvidia-smi output (temperature, SM clocks, PCIe link width, ECC, NVLink, topo -m), recent dmesg Xid lines, EFA port state and fi_info provider visibility, EFA installer + kernel module versions, CPU governor, NVL72 Fabric Manager state, FSx CloudWatch utilization, df -h / lfs df -h per mount, host iowait, /dev/shm size, and root-volume usage. All read-only.
Tags: [OK] healthy · [CONCERN] signal worth investigating (carries a → pointer to the owner skill) · [INFO] informational.
Host vs container scope. The script runs on the host via SSM and reports host-scope values. Many setups ship the EFA / libfabric / OFI-NCCL / CUDA stack inside the training container by design — a host value of unknown is not by itself a defect. What matters for performance is the stack the workload actually uses. Verify versions inside the container (and across nodes) via hyperpod-version-checker before drawing conclusions.
Step 2: Match signal → section
| Observation | Section |
|---|---|
| Pairwise NCCL bandwidth varies across node pairs / suspected straggler | [A: Uneven NCCL Performance](#a-uneven-nccl-performance) |
| Nodes spread across AZs / network-node-layer labels / UltraServer boundaries | [A](#a-uneven-nccl-performance) |
| EFA port not ACTIVE on a node, missing OFI plugin, or FI provider not visible | [A](#a-uneven-nccl-performance) + route to hyperpod-node-debugger § A; hyperpod-version-checker for cross-node version compare |
iostat shows high iowait, FSx CloudWatch utilization sustained near 100% | [B: Poor Filesystem Performance](#b-poor-filesystem-performance) |
| DataLoader stalls, checkpoint dominates step time | [B](#b-poor-filesystem-performance) |
Xid line in dmesg, uncorrectable ECC, inactive NVLink lane, GPU ≥ 88°C | Route to hyperpod-node-debugger § G |
| Container vs host version drift suspected | Route to hyperpod-version-checker |
Cannot allocate memory at os.fork(), root volume full, OOM events | Route to hyperpod-node-debugger § I |
NCCL timeout, hang, TCP fallback (NET/OFI Using TCP), RDMA memlock | Route to hyperpod-nccl |
---
A: Uneven NCCL Performance
The customer reports identical training jobs running with different step times on different node sets, pairwise bandwidth variance, or some allocations consistently slower than others despite identical code.
Per the official troubleshooting guide, the common contributing factors are network topology differences between nodes (cross-AZ, cross-rack, cross-UltraServer), degraded EFA performance on some nodes, mixed instance types or generations within an instance group, and CPU frequency scaling differences.
Diagnostic pass (read-only)
The host-side data points — GPU thermal/ECC/PCIe/clocks, Xid, NVLink lanes, EFA port state and provider visibility, CPU governor, EFA/OFI/driver versions, nvidia-smi topo -m — are all collected by scripts/perf-snapshot.sh (Step 1 above). The script tags [CONCERN] with thresholds and emits routing pointers; rerun it per suspect node via --node <INSTANCE_ID>.
For driver / CUDA / NCCL / EFA / OFI version drift across nodes, run hyperpod-version-checker skill.
Pairwise NCCL bandwidth test
Run the standard nccl-tests recipes from awslabs/awsome-distributed-training. For an N-node cluster, run all-reduce across every pair and record busbw for each pair. Pairs more than ~5% below the run mean (the threshold the AWS validation script flags) are problematic candidates.
Expected busbw per SKU is published in the AI-on-HyperPod NCCL test guide. Benchmark the specific instance type before relying on a number.
Pairwise scripts, HyperPod topology surfaces (HyperPod API, EKS labels, Slurm topology.conf), and GB200 NVL72 specifics are in references/perf-details.md § Uneven NCCL.
Topology verification
HyperPod exposes topology through three operator-visible surfaces:
- HyperPod API:
aws sagemaker describe-cluster-nodereturnsNodeDetails.Placement.AvailabilityZone/AvailabilityZoneIdandNodeDetails.UltraServerInfo.Id(UltraServer SKUs only). - EKS labels:
topology.kubernetes.io/zone,topology.k8s.aws/network-node-layer-{1,2,3}(highest-numbered = closest to instance),topology.k8s.aws/ultraserver-id. - Slurm: HyperPod auto-generates
topology.conf. Inspect viascontrol show topology.
Tightly coupled work shares the same AZ, the same highest-numbered network-node-layer label (EKS) or the same Slurm topology block, and — for NVL72 jobs — the same UltraServerInfo.Id / topology.k8s.aws/ultraserver-id. If the cluster is spread across AZs or layers, topology must be re-established at provisioning time. Route provisioning changes to hyperpod-cluster-debugger § B (Capacity & AZ).
---
B: Poor Filesystem Performance
The customer reports training bottlenecked on data loading, checkpoint save/load dominating step time, executables/scripts loading slowly, or iowait high.
Per the official troubleshooting guide, the resolution path follows this order:
1. Check CloudWatch metrics on the filesystem. 2. Check the provisioned performance configuration against workload requirements. 3. Investigate which operations are causing the I/O — workload demand vs inefficient pattern. 4. Consider upgrading provisioned performance. 5. Choose the filesystem type that matches the I/O pattern.
This skill covers steps 1–3. Steps 4–5 are customer decisions; surface the data and let the customer pick.
Diagnostic pass (read-only)
scripts/perf-snapshot.sh (Step 1 above) covers the on-node side of this pass: it discovers FSx mounts, calls aws cloudwatch get-metric-statistics on DataReadBytes and (for OpenZFS) FileServerDiskIopsUtilization, prints df -h for /fsx /opt/dlami/nvme /opt/sagemaker, runs lfs df -h per Lustre mount, and reports iostat iowait. It tags [CONCERN] when OpenZFS IOPS utilization sustains ≥ 80% or iowait > 20%.
For longer windows or additional metrics (DataWriteBytes, Lustre DiskIopsUtilization, OpenZFS FileServerDiskThroughputUtilization), drive the query directly:
aws cloudwatch get-metric-statistics --region <REGION> \
--namespace AWS/FSx --metric-name DataReadBytes \
--dimensions Name=FileSystemId,Value=<FSID> \
--start-time "$(date -u -d '3 hours ago' +%Y-%m-%dT%H:%M:%S)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
--period 60 --statistics Sum MaximumThe full per-filesystem-type metric catalog is in references/perf-details.md § Filesystem.
Branches
Provisioned capacity is saturated. CloudWatch utilization sustained near 100% across the workload window. Customer decision: scale up the filesystem.
- FSx for Lustre throughput scales with
StorageCapacity × PerUnitStorageThroughput; capacity changes are non-disruptive. - FSx for OpenZFS — increase provisioned IOPS or throughput.
I/O pattern is inefficient. CloudWatch shows headroom but the workload is still I/O-bound. Customer decision: change the application.
- DataLoader: raise
num_workers, setpin_memory=True,persistent_workers=True. - Checkpointing: use async + sharded (
torch.distributed.checkpoint.async_saveplus FSDPSHARDED_STATE_DICT).FULL_STATE_DICTserializes through rank 0 and is a frequent root cause. - Small-file workloads: Lustre is optimized for large sequential I/O. For millions of small files, use WebDataset / tar shards, FSx for OpenZFS, or NVMe scratch.
Filesystem-selection guidance and the async-checkpoint pattern are in references/perf-details.md § Filesystem.
---
Continuous health coverage
Once the immediate incident is diagnosed, recommend HyperPod's built-in health features so problems are caught before the next training run rather than after another customer-reported regression.
- Enable `NodeRecovery=Automatic` on the cluster. The Health Monitoring Agent (HMA) continuously monitors GPU- and Trainium-based instances and marks instances unhealthy on detected failure. With auto-recovery enabled, HyperPod reboots or replaces the node — no operator intervention.
- Enable `OnStartDeepHealthChecks` on every GPU instance group with both check categories:
InstanceStress—stress-ngon CPU/memory/disk, GPU and PCI device count verification, DCGM level-4 diagnostics (memory test included), and EFA loopback bandwidth/latency.InstanceConnectivity— multi-node NCCL all-reduce.
Every newly provisioned or auto-replaced node passes the same hardware bar before accepting jobs.
- Run on-demand deep health checks when this skill or any sibling surfaces a hardware concern but the cluster is mid-workload.
aws sagemaker start-cluster-health-checkruns the same checks against a specific instance group; nodes are placed in a Slurm maintenance reservation and the check is queued until any running job completes (not preempted). Console: HyperPod → Clusters → Instances → Run deep health checks.
Not supported when NodeProvisioningMode=Continuous; one on-demand request per cluster at a time. Requires the latest AMI — run UpdateClusterSoftware first.
Logs land in CloudWatch at /aws/sagemaker/Clusters/<cluster_name>/<cluster_id> under DeepHealthCheckResults/<log_stream_id>, and on each node at /var/log/aws/clusters/sagemaker-deep-health-check.log.
References
- references/perf-details.md — pairwise NCCL test recipes, HyperPod topology check, GB200 NVL72 placement; CloudWatch metric catalog per filesystem type, async-checkpoint pattern, filesystem selection guide.
External:
- Amazon SageMaker HyperPod troubleshooting guide (official): <https://github.com/aws/sagemaker-hyperpod-cluster-setup/blob/troubleshooting-doc-20250917/troubleshoot/index.md>
- AI-on-HyperPod NCCL performance tests (expected
busbwper SKU): <https://awslabs.github.io/ai-on-sagemaker-hyperpod/docs/slurm-orchestration/validation-and-testing/performance-testing/nccl-tests> - Amazon SageMaker HyperPod resiliency (NodeRecovery, HMA, auto-resume): <https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency.html>
- Amazon SageMaker HyperPod deep health checks: <https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-deep-health-checks.html>
- StartClusterHealthCheck API: <https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html>
- Amazon EC2 instance topology / network-node-layer labels: <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-topology-works.html>
- Amazon FSx for Lustre performance: <https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html>
- Amazon FSx for OpenZFS metrics: <https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/fsx-openzfs-metrics.html>
- AWS Elastic Fabric Adapter and NCCL: <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start-nccl.html>
- awslabs/awsome-distributed-training NCCL tests: <https://github.com/awslabs/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests>
Performance Details
Supplementary detail for hyperpod-performance-debugger. Two sections, matching the two scenarios the parent SKILL.md covers.
Contents
1. Uneven NCCL 2. Filesystem 3. References
---
Uneven NCCL
Pairwise NCCL all-reduce test
Use the nccl-tests recipes from awslabs/awsome-distributed-training. The repo ships micro-benchmarks/nccl-tests/slurm/nccl-tests-container.sbatch and a topology-aware pairwise sweep under micro-benchmarks/nccl-tests/slurm/topology-aware-nccl-tests/. For an N-node cluster, run all-reduce across every pair and record busbw for each pair. Pairs more than ~5% below the run mean (the threshold the AWS validation script flags) are straggler candidates.
The topology-aware submit script uses sbatch --array to fan out pairwise jobs. The repo also ships process_nccl_results.sh as a CSV post-processor for the raw test output; it does not itself apply an outlier threshold — compare results against the published expected busbw.
Single-pair run on Slurm:
sbatch -N 2 -w <NODE_A>,<NODE_B> nccl-tests-container.sbatchN-node aggregate run from a prebuilt container with NCCL + nccl-tests + aws-ofi-nccl baked in:
srun -N <N> --mpi=pmix /path/in/container/all_reduce_perf -b 8 -e 8G -f 2 -g 8Expected bandwidth
Always benchmark the specific SKU before relying on a number — averages across message sizes are misleading; focus on the message sizes the workload actually uses. AWS publishes expected busbw per SKU in the AI-on-HyperPod NCCL test guide.
EFA error-counter check (host)
Non-zero per-port counters mean packet loss or link issues. The data point names a specific node; route to hyperpod-node-debugger § A (EFA / Security Group) for the deeper read.
Check per-port EFA error counters via SSM:
for dev in /sys/class/infiniband/*/; do
name=$(basename "$dev")
rcv_err=$(cat "$dev/ports/1/counters/port_rcv_errors" 2>/dev/null)
xmit_disc=$(cat "$dev/ports/1/counters/port_xmit_discards" 2>/dev/null)
if [ "$rcv_err" != "0" ] || [ "$xmit_disc" != "0" ]; then
echo "PROBLEM: $name rcv_errors=$rcv_err xmit_discards=$xmit_disc"
fi
doneEFA firmware should also match across nodes (compare via hyperpod-version-checker):
cat /sys/class/infiniband/*/fw_ver 2>/dev/nullHyperPod topology surfaces
HyperPod models co-location through three operator-visible surfaces — check each one that applies to the cluster.
Validate per-node AZ and UltraServer assignment via the HyperPod API:
for id in $(aws sagemaker list-cluster-nodes --cluster-name <C> --region <R> \
--query 'ClusterNodeSummaries[*].InstanceId' --output text); do
aws sagemaker describe-cluster-node --cluster-name <C> --region <R> \
--node-id "$id" \
--query 'NodeDetails.{ID:InstanceId,AZ:Placement.AvailabilityZone,AZID:Placement.AvailabilityZoneId,UltraServer:UltraServerInfo.Id}' \
--output table
doneCheck EKS topology labels:
kubectl get nodes -L \
topology.kubernetes.io/zone,\
topology.k8s.aws/network-node-layer-1,\
topology.k8s.aws/network-node-layer-2,\
topology.k8s.aws/network-node-layer-3,\
topology.k8s.aws/ultraserver-idCheck Slurm topology:
scontrol show topology
grep -E 'TopologyPlugin|BlockSizes' \
/var/spool/slurm/slurm.conf /var/spool/slurm/topology.conf 2>/dev/nullTightly coupled work should share the same AZ, the same highest-numbered network-node-layer-* label (EKS) or the same Slurm topology block, and — for NVL72 jobs — the same UltraServerInfo.Id / topology.k8s.aws/ultraserver-id. If the cluster is spread across AZs or layers, co-location has to be re-established at provisioning time. Route provisioning changes to hyperpod-cluster-debugger § B (Capacity & AZ).
EFA version consistency
All nodes in the training group must run identical EFA and OFI-NCCL versions. Mismatches can materially degrade pairwise bandwidth. Compare across nodes via hyperpod-version-checker.
GB200 NVL72 UltraServer
p6e-gb200.36xlarge is fundamentally different from p5/p6-b200. One UltraServer = 18 instances × 4 Blackwell GPUs = 72 GPUs inside one NVLink domain, stitched across the 18 instances by NVIDIA IMEX.
For uneven-NCCL triage on NVL72:
- If the variance is inside one UltraServer, the IMEX / NVLink fabric is a candidate. Surface
nvidia-smi topo -mandsystemctl status nvidia-fabricmanageras data points; route tohyperpod-node-debugger§ G for the deeper read. Fabric failures hard-fail CUDA init with SXid errors rather than silently degrading, so a cleannvidia-smitypically rules out the fabric. - If the variance is across UltraServers, the workload placement could be wrong — the NVL72 is meant to contain a single tight-coupled group. Verify the auto-configured
topology/block(Slurm,BlockSizes=18) or the EKStopology.k8s.aws/ultraserver-idlabel.
---
Filesystem
CloudWatch metrics per filesystem type
All metrics live in the AWS/FSx namespace. Dimension: FileSystemId.
FSx for Lustre (FileSystemType: LUSTRE)
| Metric | What it means | Statistic |
|---|---|---|
DataReadBytes | Aggregate read throughput (Bytes) | Sum |
DataWriteBytes | Aggregate write throughput (Bytes) | Sum |
MetadataOperations | File-open, stat, readdir rate (Count) | Sum |
FreeDataStorageCapacity | Remaining bytes — low values throttle writes | Minimum |
DiskIopsUtilization | % of provisioned IOPS in use (Percent) | Maximum |
Lustre throughput scales as StorageCapacity_TiB × PerUnitStorageThroughput_MBps. Capacity changes are non-disruptive.
FSx for OpenZFS (FileSystemType: OPENZFS)
| Metric | What it means | Statistic |
|---|---|---|
DataReadBytes / DataWriteBytes | Aggregate throughput (Bytes) | Sum |
DataReadOperations / DataWriteOperations | Client IOPS (Count) | Sum |
NetworkThroughputUtilization | % of provisioned network throughput in use | Average, Maximum |
FileServerDiskIopsUtilization | % of disk IOPS in use | Average, Maximum |
FileServerDiskThroughputUtilization | % of disk throughput in use | Average, Maximum |
CPUUtilization | File server CPU % | Average, Maximum |
The utilization metrics (percent) are the authoritative saturation signals. There is no ReadIOPS metric in AWS/FSx — that is an EBS metric.
EBS (AWS/EBS namespace)
VolumeReadOps, VolumeWriteOps, VolumeQueueLength. A sustained VolumeQueueLength > 1 typically indicates the volume is the bottleneck. For gp3, also compare against the provisioned IOPS / throughput configured on the volume.
NVMe (instance-local)
Mounted at /opt/dlami/nvme. Ephemeral — data is lost on stop, replace, or hardware failure. Use for scratch and caches, not persistent state. Available capacity varies by instance type.
Secondary EBS volume (/opt/sagemaker)
The secondary EBS volume is the persistent per-instance storage HyperPod attaches at /opt/sagemaker. It is configured per instance group via ClusterEbsVolumeConfig (root volume is fixed; secondary is what you size). When the volume backing it fills up and the customer needs more space, there are two paths.
Path 1 — Resize via the instance group (takes effect on replacement)
ClusterEbsVolumeConfig carries VolumeSizeInGB on each instance group. Update the instance group with a larger value via UpdateCluster call or CloudFormation/Terraform.
Important: the new size applies to newly provisioned or replaced nodes, not to running nodes. Existing nodes keep their original secondary EBS until they're replaced (auto-recovery, on-demand deep health check that fails, or BatchReplaceClusterNodes).
When to use this path:
- The customer wants the new size to be the standard for the instance group going forward.
- A rolling replacement is acceptable (data on
/opt/sagemakerof the existing nodes does not survive replacement — checkpoints / artifacts on shared storage like FSx are unaffected).
Path 2 — Attach an extra EBS volume to a running node (EKS only)
AttachClusterNodeVolume attaches an existing EBS volume to a running HyperPod EKS node without replacement. This is the EBS CSI driver path — typically driven by Kubernetes PersistentVolumeClaims rather than called directly, but the API is available for ad-hoc attachment.
Constraints (per the API):
- EKS-orchestrated cluster only; the cluster must be
InService. - The target node cannot be in a Restricted Instance Group (RIG).
- The EBS volume must already exist and be in the
availablestate, in the same AZ as the node. - A complementary
DetachClusterNodeVolumeremoves the volume.
Filesystem selection by pattern
| Pattern | Best fit | Why |
|---|---|---|
| Large sequential I/O | FSx for Lustre | Striping scales with OSTs |
| Small random I/O, mixed reads | FSx for OpenZFS | POSIX + better small-file performance |
| Temporary high-perf scratch | NVMe (/opt/dlami/nvme) | High aggregate throughput, zero network |
| Single-node persistent | EBS (/opt/sagemaker) | 100 GiB root is too small; EBS sized |
| Datasets (cold + warm) | S3 + Mountpoint-S3 for streaming reads | Scales infinitely, no provisioned limit |
For HyperPod Slurm, the default lifecycle script offers FSx for OpenZFS as an alternative to Lustre for home directories — useful when the home tree has small-file metadata pressure.
---
References
- Amazon SageMaker HyperPod troubleshooting guide (official): <https://github.com/aws/sagemaker-hyperpod-cluster-setup/blob/troubleshooting-doc-20250917/troubleshoot/index.md>
- AI-on-HyperPod NCCL performance test guide (expected
busbwper SKU): <https://awslabs.github.io/ai-on-sagemaker-hyperpod/docs/slurm-orchestration/validation-and-testing/performance-testing/nccl-tests> - AI-on-HyperPod GPU stress testing: <https://awslabs.github.io/ai-on-sagemaker-hyperpod/docs/validation-and-testing/performance-testing/gpu-stress-testing>
- Amazon SageMaker HyperPod resiliency (NodeRecovery, Health Monitoring Agent, auto-resume): <https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency.html>
- Amazon SageMaker HyperPod deep health checks: <https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-deep-health-checks.html>
- AWS Elastic Fabric Adapter and NCCL: <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start-nccl.html>
- Amazon FSx for Lustre performance: <https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html>
- Amazon FSx for OpenZFS metrics: <https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/fsx-openzfs-metrics.html>
- awslabs/awsome-distributed-training NCCL tests: <https://github.com/awslabs/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests>
- Amazon EC2 instance topology (network-node-layer ordering): <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-topology-works.html>
#!/usr/bin/env bash
# perf-snapshot.sh
#
# Read-only host-side snapshot for the two performance scenarios that
# hyperpod-performance-debugger covers:
#
# A. Uneven NCCL performance (host-side EFA reachability, NVLink, Fabric
# Manager, recent dmesg events that contextualize bandwidth variance)
# B. Poor filesystem performance (FSx CloudWatch utilization for actually
# mounted filesystems, on-node iowait)
#
#
# Usage:
# bash perf-snapshot.sh --cluster <NAME|ARN> --region <REGION>
# bash perf-snapshot.sh --cluster <N> --region <R> --node <INSTANCE_ID>
# bash perf-snapshot.sh --cluster <N> --region <R> --no-color > report.txt
#
# Required IAM (on the calling principal):
# sagemaker:DescribeCluster, sagemaker:ListClusterNodes,
# sagemaker:DescribeClusterNode
# fsx:DescribeFileSystems
# cloudwatch:GetMetricStatistics
# ssm:StartSession, ssm:TerminateSession
#
# Note: HyperPod-managed instances are not reliably addressable via
# ec2:DescribeInstances from the operator role, so this script stays on
# SageMaker HyperPod APIs + IMDS (via SSM) for per-instance metadata.
#
# Prerequisites on the calling machine:
# aws CLI v2, jq, session-manager-plugin (for the SSM calls),
# unbuffer (from the `expect` package; works around a session-manager-plugin
# stdout race — see ssm_run below).
set -uo pipefail
# ---------------------------------------------------------------------------
# Argument parsing
# ---------------------------------------------------------------------------
CLUSTER=""
REGION="${AWS_DEFAULT_REGION:-us-east-1}"
TARGET_NODE=""
NO_COLOR="${NO_COLOR:-}"
usage() {
sed -n '2,40p' "$0" | sed 's/^# \{0,1\}//'
}
while [[ $# -gt 0 ]]; do
case "$1" in
--cluster) CLUSTER="${2:-}"; shift 2 ;;
--region) REGION="${2:-}"; shift 2 ;;
--node) TARGET_NODE="${2:-}"; shift 2 ;;
--no-color) NO_COLOR=1; shift 1 ;;
-h|--help) usage; exit 0 ;;
*) echo "Unknown arg: $1" >&2; usage; exit 2 ;;
esac
done
# ---------------------------------------------------------------------------
# Input validation — these values flow into AWS API calls and SSM payloads.
# ---------------------------------------------------------------------------
[[ -z "$CLUSTER" ]] && { echo "Error: --cluster required" >&2; exit 2; }
# Cluster name or ARN (see AWS SageMaker BatchReplaceClusterNodesRequest pattern)
if ! [[ "$CLUSTER" =~ ^(arn:aws[a-z-]*:sagemaker:[a-z0-9-]*:[0-9]{12}:cluster/[a-z0-9]{12})$|^[a-zA-Z0-9][-a-zA-Z0-9]{0,62}$ ]]; then
echo "Error: invalid cluster name or ARN: $CLUSTER" >&2
exit 2
fi
# Region
if ! [[ "$REGION" =~ ^[a-z]{2}-[a-z]+-[0-9]{1,2}$ ]]; then
echo "Error: invalid region: $REGION" >&2
exit 2
fi
# Optional node — EC2 instance ID
if [[ -n "$TARGET_NODE" ]] && ! [[ "$TARGET_NODE" =~ ^i-[a-f0-9]{8,17}$ ]]; then
echo "Error: invalid --node (expected i-<hex>): $TARGET_NODE" >&2
exit 2
fi
# Dependency check
for cmd in aws jq; do
command -v "$cmd" >/dev/null 2>&1 || { echo "Error: '$cmd' is required" >&2; exit 2; }
done
if ! command -v session-manager-plugin >/dev/null 2>&1; then
echo "Warning: session-manager-plugin not found; on-node probes will fail" >&2
fi
if ! command -v unbuffer >/dev/null 2>&1; then
echo "Warning: 'unbuffer' (from the 'expect' package) not found — SSM calls" >&2
echo " can intermittently return empty output. Install with" >&2
echo " 'sudo yum install expect' / 'sudo apt install expect' / 'brew install expect'." >&2
fi
# ---------------------------------------------------------------------------
# Output helpers (TTY-gated; respect NO_COLOR)
# ---------------------------------------------------------------------------
if [[ -t 1 ]] && [[ -z "$NO_COLOR" ]]; then
GREEN=$'\033[0;32m'; YELLOW=$'\033[1;33m'
CYAN=$'\033[0;36m'; BOLD=$'\033[1m'; NC=$'\033[0m'
else
GREEN=""; YELLOW=""; CYAN=""; BOLD=""; NC=""
fi
section() { printf "\n${BOLD}${CYAN}== %s ==${NC}\n" "$1"; }
ok() { printf " ${GREEN}[OK ]${NC} %s\n" "$1"; }
concern() { printf " ${YELLOW}[CONCERN]${NC} %s\n" "$1"; }
info() { printf " %s\n" "$1"; }
# Pointers (sibling skill / SKILL.md section to read after a [CONCERN] line)
NEXT=()
# ---------------------------------------------------------------------------
# Cluster + node list
# ---------------------------------------------------------------------------
DESC=$(aws sagemaker describe-cluster --cluster-name "$CLUSTER" --region "$REGION" --output json 2>&1) \
|| { echo "Error: describe-cluster failed: $DESC" >&2; exit 3; }
CLUSTER_ID=$(echo "$DESC" | jq -r '.ClusterArn' | awk -F/ '{print $NF}')
NODES=$(aws sagemaker list-cluster-nodes --cluster-name "$CLUSTER" --region "$REGION" --output json 2>&1) \
|| { echo "Error: list-cluster-nodes failed: $NODES" >&2; exit 3; }
# Pick target node
if [[ -n "$TARGET_NODE" ]]; then
TGT_ID="$TARGET_NODE"
else
TGT_ID=$(echo "$NODES" | jq -r '
[.ClusterNodeSummaries[] | select(.InstanceGroupName|test("controller|head";"i")|not)][0].InstanceId
// .ClusterNodeSummaries[0].InstanceId // empty')
fi
[[ -z "$TGT_ID" ]] && { echo "Error: no nodes found in cluster" >&2; exit 3; }
TGT_GROUP=$(echo "$NODES" | jq -r --arg id "$TGT_ID" \
'.ClusterNodeSummaries[] | select(.InstanceId==$id) | .InstanceGroupName // empty')
[[ -z "$TGT_GROUP" ]] && { echo "Error: node $TGT_ID not found in cluster" >&2; exit 3; }
SSM_TARGET="sagemaker-cluster:${CLUSTER_ID}_${TGT_GROUP}-${TGT_ID}"
# Instance type from list-cluster-nodes output (already fetched). No EC2 call.
INSTANCE_TYPE=$(echo "$NODES" | jq -r --arg id "$TGT_ID" \
'.ClusterNodeSummaries[] | select(.InstanceId==$id) | .InstanceType // empty')
IS_NVL72=0
if [[ "$INSTANCE_TYPE" =~ ^ml\.p6e-gb200|^ml\.p6e-gb300|^p6e-gb200|^p6e-gb300 ]]; then
IS_NVL72=1
fi
# ---------------------------------------------------------------------------
# SSM helper — injection-safe (commands passed via file-based CLI input).
# Bounded to 60s per call to avoid hangs on unreachable nodes.
# ---------------------------------------------------------------------------
ssm_run() {
local target="$1"
local cmd="$2"
local json_file runner
json_file=$(mktemp)
# shellcheck disable=SC2064
trap "rm -f '$json_file'" RETURN
jq -n --arg t "$target" --arg c "$cmd" '{
Target: $t,
DocumentName: "AWS-StartNonInteractiveCommand",
Parameters: { command: [ ("bash -c " + ($c | @sh)) ] }
}' > "$json_file"
if command -v unbuffer >/dev/null 2>&1; then
runner=(unbuffer aws)
else
runner=(aws)
fi
timeout 60 "${runner[@]}" ssm start-session --region "$REGION" \
--cli-input-json "file://${json_file}" 2>/dev/null \
| sed -e 's/\x1b\[[0-9;]*m//g' \
-e '/^Starting session/d' \
-e '/^Exiting session/d' \
-e '/^Cannot perform start session: EOF$/d'
}
# ssm_json: run a payload that is expected to print a single JSON document on
# stdout. On parse failure (probe missing, jq absent, command timeout) returns
# the empty object so callers can use jq with safe defaults.
ssm_json() {
local target="$1" cmd="$2" out
out=$(ssm_run "$target" "$cmd")
if printf '%s' "$out" | jq -e . >/dev/null 2>&1; then
printf '%s' "$out"
else
printf '{}'
fi
}
# ---------------------------------------------------------------------------
# A. Uneven NCCL — placement and EFA reachability data points
# ---------------------------------------------------------------------------
section "A. NCCL topology & EFA reachability"
# AZ placement — use sagemaker:DescribeClusterNode which returns
# Placement.AvailabilityZone. No ec2:DescribeInstances needed.
#
# DescribeClusterNode has no batch form, so this is O(N) API calls. Cap the
# sample to keep runtime bounded; a single outlier AZ is enough to surface
# the concern. Customer can run sagemaker list-cluster-nodes for a full audit.
mapfile -t ALL_IDS < <(echo "$NODES" | jq -r '.ClusterNodeSummaries[].InstanceId // empty')
AZ_SAMPLE_CAP=20
if [[ "${#ALL_IDS[@]}" -eq 0 ]]; then
info "no instance IDs in cluster node list; skipping placement check"
else
SAMPLE_N=${#ALL_IDS[@]}
TRUNCATED=0
if (( SAMPLE_N > AZ_SAMPLE_CAP )); then
SAMPLE_N=$AZ_SAMPLE_CAP
TRUNCATED=1
fi
AZS=""
for ((i = 0; i < SAMPLE_N; i++)); do
id="${ALL_IDS[$i]}"
az=$(aws sagemaker describe-cluster-node --cluster-name "$CLUSTER" --region "$REGION" \
--node-id "$id" --query 'NodeDetails.Placement.AvailabilityZone' --output text 2>/dev/null) || az=""
[[ -n "$az" && "$az" != "None" ]] && AZS+="${az}"$'\n'
done
UNIQ_AZ=$(echo "$AZS" | awk 'NF' | sort -u | wc -l)
if (( UNIQ_AZ > 1 )); then
concern "sampled nodes span $UNIQ_AZ AZs — cross-AZ placement is a known cause of uneven NCCL"
info "→ SKILL.md § A (Uneven NCCL); for re-provisioning, → hyperpod-cluster-debugger § B"
NEXT+=("A")
elif (( UNIQ_AZ == 1 )); then
ok "sampled nodes share a single AZ"
else
info "no AZ returned by DescribeClusterNode; skipping placement check"
fi
(( TRUNCATED )) && info "sampled first $AZ_SAMPLE_CAP of ${#ALL_IDS[@]} nodes; sagemaker list-cluster-nodes for a full audit"
fi
# EFA + container toolkit stack versions — sample from the target node so the
# customer has a starting point. For cross-node comparison, route to
# hyperpod-version-checker rather than re-implementing it here.
STACK_JSON=$(ssm_json "$SSM_TARGET" '
pkgver() {
pkg=$1
if command -v dpkg >/dev/null 2>&1; then
v=$(dpkg-query -W -f="\${Version}" "$pkg" 2>/dev/null)
fi
if [ -z "${v:-}" ] && command -v rpm >/dev/null 2>&1; then
v=$(rpm -q --qf "%{VERSION}-%{RELEASE}" "$pkg" 2>/dev/null)
case "$v" in [0-9]*) ;; *) v="" ;; esac
fi
printf "%s" "${v:-}"
}
efa_inst=$(grep -iE "^EFA[[:space:]]+(installer[[:space:]]+)?version" \
/opt/amazon/efa_installed_packages 2>/dev/null \
| head -1 | sed -E "s/.*[:=][[:space:]]*//")
efa_mod=$(modinfo efa 2>/dev/null | awk "/^version:/ {print \$2; exit}")
ofi=$(pkgver aws-ofi-nccl)
libfabric=$(fi_info -v 2>/dev/null | awk -F": " "/libfabric/{print \$2; exit}")
driver=$(nvidia-smi --query-gpu=driver_version --format=csv,noheader 2>/dev/null | head -1)
nvct=$(pkgver nvidia-container-toolkit)
jq -n \
--arg efa_installer "$efa_inst" \
--arg efa_kmod "$efa_mod" \
--arg ofi_nccl "$ofi" \
--arg libfabric "$libfabric" \
--arg driver "$driver" \
--arg nvct "$nvct" \
"{efa_installer:\$efa_installer, efa_kmod:\$efa_kmod, ofi_nccl:\$ofi_nccl, libfabric:\$libfabric, driver:\$driver, nvct:\$nvct}"
')
# Render to operator output. `// "unknown"` keeps the column non-empty when a
# component is intentionally not on the host.
while IFS=$'\t' read -r k v; do
info "$TGT_ID host: ${k}=${v}"
done < <(echo "$STACK_JSON" | jq -r '
def nz(x): if (x // "") == "" then "unknown" else x end;
. as $s
| [
["EFA", (nz($s.efa_installer) + " (kmod=" + nz($s.efa_kmod) + ")")],
["OFI_NCCL", nz($s.ofi_nccl)],
["LIBFABRIC", nz($s.libfabric)],
["DRIVER", nz($s.driver)],
["NVCT", nz($s.nvct)]
]
| .[] | @tsv
')
info "values above are host-scope; the workload may use a different EFA/OFI/CUDA stack inside the container — verify via hyperpod-version-checker"
info "for cross-node version comparison, → hyperpod-version-checker"
# EFA fabric reachability — port state and provider visibility. SG-level rules
# are not directly inspectable from this role; route to hyperpod-cluster-debugger
# § A for the cluster-wide EFA SG check.
EFA_JSON=$(ssm_json "$SSM_TARGET" '
total=0; active=0
for p in /sys/class/infiniband/*/ports/1/state; do
[ -e "$p" ] || continue
total=$((total+1))
grep -q ACTIVE "$p" 2>/dev/null && active=$((active+1))
done
if fi_info -p efa >/dev/null 2>&1; then
fi_info_ok=true
else
fi_info_ok=false
fi
jq -n \
--argjson total "$total" \
--argjson active "$active" \
--argjson fi_info_ok "$fi_info_ok" \
"{ports:{total:\$total, active:\$active}, fi_info_ok:\$fi_info_ok}"
')
EFA_TOTAL=$(echo "$EFA_JSON" | jq -r '.ports.total // 0')
EFA_ACTIVE=$(echo "$EFA_JSON" | jq -r '.ports.active // 0')
EFA_FI_OK=$(echo "$EFA_JSON" | jq -r '.fi_info_ok // false')
if (( EFA_TOTAL == 0 )); then
concern "no EFA devices visible on $TGT_ID"
info "→ hyperpod-node-debugger § A (EFA / Security Group)"
NEXT+=("A")
elif (( EFA_ACTIVE != EFA_TOTAL )); then
concern "EFA port state on $TGT_ID: ${EFA_ACTIVE}/${EFA_TOTAL} ACTIVE"
info "→ hyperpod-node-debugger § A (EFA / Security Group)"
NEXT+=("A")
else
ok "EFA port state on $TGT_ID: ${EFA_ACTIVE}/${EFA_TOTAL} ACTIVE"
fi
if [[ "$EFA_FI_OK" != "true" ]] && (( EFA_TOTAL > 0 )); then
concern "libfabric does not see the EFA provider on $TGT_ID — NCCL would fall back to TCP"
info "→ hyperpod-nccl § 13 (EFA TCP fallback) / hyperpod-cluster-debugger § A"
NEXT+=("A")
fi
info "EFA self-referencing security-group rule is a cluster-wide check — → hyperpod-cluster-debugger § A"
# GPU/NIC topology snapshot — raw informational print so the operator can see
# how PCIe / NVLink edges connect GPUs to NICs without re-running on the node.
TOPO=$(ssm_run "$SSM_TARGET" "nvidia-smi topo -m 2>/dev/null")
if [[ -n "$TOPO" ]]; then
info "nvidia-smi topo -m on $TGT_ID:"
echo "$TOPO" | sed 's/^/ /'
fi
# ---------------------------------------------------------------------------
# B. Filesystem — CloudWatch utilization + on-node iowait
# ---------------------------------------------------------------------------
section "B. Filesystem saturation"
# Scope FSx query to filesystems actually mounted on the target node.
FSIDS_JSON=$(ssm_json "$SSM_TARGET" '
ids=$(mount | awk "/lustre|zfs/ {print \$1}" | grep -oE "fs-[a-f0-9]+" | sort -u)
if [ -z "$ids" ]; then
echo "[]"
else
printf "%s\n" "$ids" | jq -R . | jq -s .
fi
')
mapfile -t FSID_ARRAY < <(echo "$FSIDS_JSON" | jq -r '.[]?')
if [[ ${#FSID_ARRAY[@]} -eq 0 ]]; then
info "no FSx filesystems mounted on $TGT_ID"
else
FSX_DESC=$(aws fsx describe-file-systems --region "$REGION" \
--file-system-ids "${FSID_ARRAY[@]}" --output json 2>/dev/null || echo '{}')
FSCOUNT=$(echo "$FSX_DESC" | jq '.FileSystems | length // 0')
if (( FSCOUNT == 0 )); then
info "FSx filesystems ${FSID_ARRAY[*]} are mounted but describe-file-systems returned nothing (cross-account?)"
else
while IFS=$'\t' read -r fsid fstype; do
[[ -z "$fsid" ]] && continue
val=$(aws cloudwatch get-metric-statistics --region "$REGION" \
--namespace AWS/FSx --metric-name DataReadBytes \
--dimensions "Name=FileSystemId,Value=${fsid}" \
--start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -v-1H +%Y-%m-%dT%H:%M:%S)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
--period 60 --statistics Maximum --output json 2>/dev/null \
| jq -r '[.Datapoints[].Maximum] | max // 0')
info "${fstype} ${fsid}: max 1h DataReadBytes = ${val} bytes/min"
if [[ "$fstype" == "OPENZFS" ]]; then
util=$(aws cloudwatch get-metric-statistics --region "$REGION" \
--namespace AWS/FSx --metric-name FileServerDiskIopsUtilization \
--dimensions "Name=FileSystemId,Value=${fsid}" \
--start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -v-1H +%Y-%m-%dT%H:%M:%S)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
--period 60 --statistics Maximum --output json 2>/dev/null \
| jq -r '[.Datapoints[].Maximum] | max // 0')
info " max 1h FileServerDiskIopsUtilization = ${util}%"
util_int=${util%.*}
if [[ "$util_int" =~ ^[0-9]+$ ]] && (( util_int >= 80 )); then
concern "OpenZFS $fsid disk IOPS utilization sustained ≥ 80% (peak ${util}%)"
info "→ SKILL.md § B (Poor Filesystem Performance)"
NEXT+=("B")
fi
fi
done < <(echo "$FSX_DESC" | jq -r '.FileSystems[]? | [.FileSystemId, .FileSystemType] | @tsv')
info "review the FSx dashboards for sustained near-provisioned-limit usage (script reports peaks only)"
fi
fi
# On-node mount-point capacity — surface usage on FSx / NVMe / SageMaker paths.
# Includes lfs df per Lustre mount so the operator can see OST/MDT fill.
DF_JSON=$(ssm_json "$SSM_TARGET" '
mounts="[]"
for p in /fsx /opt/dlami/nvme /opt/sagemaker; do
[ -e "$p" ] || continue
line=$(df -h "$p" 2>/dev/null | awk "NR==2") || continue
[ -z "$line" ] && continue
fs=$(echo "$line" | awk "{print \$1}")
sz=$(echo "$line" | awk "{print \$2}")
used=$(echo "$line" | awk "{print \$3}")
avail=$(echo "$line" | awk "{print \$4}")
pct=$(echo "$line" | awk "{print \$5}")
entry=$(jq -n \
--arg path "$p" --arg fs "$fs" --arg size "$sz" \
--arg used "$used" --arg avail "$avail" --arg pct "$pct" \
"{path:\$path, fs:\$fs, size:\$size, used:\$used, avail:\$avail, pct:\$pct}")
mounts=$(jq --argjson e "$entry" ". + [\$e]" <<< "$mounts")
done
lustre="[]"
while IFS= read -r mnt; do
[ -z "$mnt" ] && continue
out=$(lfs df -h "$mnt" 2>/dev/null) || continue
[ -z "$out" ] && continue
rows=$(printf "%s\n" "$out" | jq -R . | jq -s .)
entry=$(jq -n --arg mnt "$mnt" --argjson rows "$rows" \
"{mount:\$mnt, rows:\$rows}")
lustre=$(jq --argjson e "$entry" ". + [\$e]" <<< "$lustre")
done < <(mount | awk "/lustre/ {print \$3}")
jq -n \
--argjson mounts "$mounts" \
--argjson lustre "$lustre" \
"{mounts:\$mounts, lustre:\$lustre}"
')
while IFS=$'\t' read -r path fs size used avail pct; do
[[ -z "$path" ]] && continue
info "df ${path}: ${used} used / ${size} (${pct}, ${avail} free) on ${fs}"
done < <(echo "$DF_JSON" | jq -r '.mounts[]? | [.path, .fs, .size, .used, .avail, .pct] | @tsv')
LAST_LFS_MNT=""
while IFS=$'\t' read -r mnt row; do
[[ -z "$mnt" ]] && continue
if [[ "$mnt" != "$LAST_LFS_MNT" ]]; then
info "lfs df -h ${mnt}:"
LAST_LFS_MNT="$mnt"
fi
info " ${row}"
done < <(echo "$DF_JSON" | jq -r '.lustre[]? | . as $e | $e.rows[] | [$e.mount, .] | @tsv')
# On-node iowait via iostat
IOWAIT=$(ssm_run "$SSM_TARGET" "iostat -c 1 2 2>/dev/null | awk 'END{print \$4}'")
IOWAIT=$(echo "$IOWAIT" | tr -d '\r \n')
if [[ -n "$IOWAIT" ]]; then
IOWAIT_INT=${IOWAIT%.*}
if [[ "$IOWAIT_INT" =~ ^[0-9]+$ ]]; then
info "$TGT_ID iowait: ${IOWAIT}%"
if (( IOWAIT_INT > 20 )); then
concern "iowait on $TGT_ID is ${IOWAIT}%"
info "→ SKILL.md § B (Poor Filesystem Performance)"
NEXT+=("B")
fi
fi
fi
# ---------------------------------------------------------------------------
# Adjacent host data points — out of scope for this skill but commonly relevant.
# Reported as data points only; remediation is owned by sibling skills.
# ---------------------------------------------------------------------------
section "Adjacent data points (out of scope — see sibling skills)"
# GPU thermal / ECC / NVLink / Xid — surface as concerns; routing goes to
# hyperpod-node-debugger § G. Do NOT classify cause from a single reading.
GPU_OUT=$(ssm_run "$SSM_TARGET" "nvidia-smi --query-gpu=index,temperature.gpu,clocks.current.sm,clocks.max.sm,pcie.link.width.current,pcie.link.width.max,ecc.errors.uncorrected.volatile.total,ecc.errors.uncorrected.aggregate.total --format=csv,noheader,nounits 2>&1 | head -16")
if echo "$GPU_OUT" | grep -qiE 'command not found|no devices|NVIDIA-SMI has failed'; then
info "no NVIDIA GPU detected on $TGT_ID"
else
HOT=0; UNCORR_VOL=0; UNCORR_AGG=0; GPUS=0; PCIE_DEGRADED=0; SM_THROTTLED=0
while IFS=',' read -r idx temp sm_cur sm_max pcie_cur pcie_max unc_vol unc_agg; do
idx=$(echo "$idx" | tr -d ' '); [[ -z "$idx" ]] && continue
temp=$(echo "$temp" | tr -d ' ')
sm_cur=$(echo "$sm_cur" | tr -d ' ')
sm_max=$(echo "$sm_max" | tr -d ' ')
pcie_cur=$(echo "$pcie_cur" | tr -d ' ')
pcie_max=$(echo "$pcie_max" | tr -d ' ')
unc_vol=$(echo "$unc_vol" | tr -d ' ')
unc_agg=$(echo "$unc_agg" | tr -d ' ')
GPUS=$((GPUS+1))
[[ "$temp" =~ ^[0-9]+$ && "$temp" -ge 88 ]] && HOT=$((HOT+1))
[[ "$unc_vol" =~ ^[0-9]+$ && "$unc_vol" -gt 0 ]] && UNCORR_VOL=$((UNCORR_VOL+1))
[[ "$unc_agg" =~ ^[0-9]+$ && "$unc_agg" -gt 0 ]] && UNCORR_AGG=$((UNCORR_AGG+1))
if [[ "$pcie_cur" =~ ^[0-9]+$ && "$pcie_max" =~ ^[0-9]+$ ]] && (( pcie_cur < pcie_max )); then
PCIE_DEGRADED=$((PCIE_DEGRADED+1))
fi
# Workload-time clock check would need correlation; skip silently when idle.
if [[ "$sm_cur" =~ ^[0-9]+$ && "$sm_max" =~ ^[0-9]+$ ]] && (( sm_max > 0 )) \
&& (( sm_cur * 100 < sm_max * 50 )) && [[ "$temp" =~ ^[0-9]+$ ]] && (( temp >= 80 )); then
SM_THROTTLED=$((SM_THROTTLED+1))
fi
done <<< "$GPU_OUT"
info "$GPUS GPUs visible on $TGT_ID"
if (( HOT > 0 )); then
concern "$HOT GPU(s) at or above the H100 SXM5 software-throttle point (≥ 88°C)"
info "data point only — correlate with workload before drawing a conclusion"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
fi
if (( PCIE_DEGRADED > 0 )); then
concern "$PCIE_DEGRADED GPU(s) report PCIe link width below max"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
fi
if (( SM_THROTTLED > 0 )); then
concern "$SM_THROTTLED GPU(s) running SM clock < 50% of max while ≥ 80°C — possible thermal throttling"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
fi
if (( UNCORR_VOL > 0 )); then
concern "$UNCORR_VOL GPU(s) report uncorrectable ECC (volatile)"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
fi
if (( UNCORR_AGG > 0 )); then
concern "$UNCORR_AGG GPU(s) report uncorrectable ECC (aggregate / lifetime)"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
fi
if (( HOT == 0 && UNCORR_VOL == 0 && UNCORR_AGG == 0 && PCIE_DEGRADED == 0 && SM_THROTTLED == 0 )); then
ok "no thermal / ECC / PCIe / clock concerns visible on $TGT_ID"
fi
fi
# CPU frequency governor — uneven across nodes is a known straggler cause.
GOV=$(ssm_run "$SSM_TARGET" "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>/dev/null")
GOV=$(echo "$GOV" | tr -d '\r\n ')
if [[ -n "$GOV" ]]; then
info "CPU governor on $TGT_ID: ${GOV}"
if [[ "$GOV" != "performance" ]]; then
concern "CPU governor is '${GOV}' (not 'performance') on $TGT_ID — known cause of uneven NCCL"
info "→ SKILL.md § A (Uneven NCCL); compare across nodes with hyperpod-version-checker"
NEXT+=("A")
fi
fi
# Recent Xid lines — surface, do NOT classify
XID=$(ssm_run "$SSM_TARGET" "dmesg -T 2>/dev/null | grep -i 'Xid' | tail -5")
if [[ -n "$XID" ]]; then
concern "recent Xid line(s) in dmesg on $TGT_ID — surface only; → hyperpod-node-debugger § G for the catalog"
echo "$XID" | sed 's/^/ /'
NEXT+=("G")
else
ok "no Xid lines in recent dmesg"
fi
# NVLink lane status / errors — concern, don't classify
NVLINK=$(ssm_run "$SSM_TARGET" '
nvidia-smi nvlink -s 2>/dev/null
echo "----"
nvidia-smi nvlink -e 2>/dev/null
')
if echo "$NVLINK" | grep -qiE 'has no supported GPU|command not found|no devices'; then
info "NVLink: not supported on this instance (skipped)"
else
INACTIVE=$(echo "$NVLINK" | awk '/^GPU/{gpu=$0; next} /[Ii]nactive/ {print gpu":"$0}' | wc -l)
ERR_LINES=$(echo "$NVLINK" | awk 'BEGIN{errs=0} /^GPU/{gpu=$0; next} /[Ee]rror/{for(i=1;i<=NF;i++) if($i ~ /^[0-9]+$/ && $i>0) errs++} END{print errs}')
if (( INACTIVE > 0 )); then
concern "$INACTIVE NVLink lane(s) report inactive on $TGT_ID"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
elif (( ERR_LINES > 0 )); then
concern "NVLink error counters non-zero on some lanes on $TGT_ID"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
else
ok "NVLink lanes active, no error counters"
fi
fi
# Fabric Manager — required on NVL72 UltraServers
if (( IS_NVL72 )); then
FM=$(ssm_run "$SSM_TARGET" 'systemctl is-active nvidia-fabricmanager 2>/dev/null || echo missing')
FM=$(echo "$FM" | tr -d '\r\n ')
case "$FM" in
active)
ok "Fabric Manager active (required for $INSTANCE_TYPE NVLink fabric)"
;;
*)
concern "Fabric Manager state=${FM:-missing} on $INSTANCE_TYPE"
info "→ hyperpod-node-debugger § G (GPU / Accelerator)"
NEXT+=("G")
;;
esac
fi
# /dev/shm and root-volume usage — surface, don't act
HOST_INFO_JSON=$(ssm_json "$SSM_TARGET" '
shm_present=false
shm_size_gib=0
shm_used_gib=0
if [ -d /dev/shm ]; then
shm_present=true
read -r size_k used_k _ < <(df -k /dev/shm 2>/dev/null | awk "NR==2{print \$2, \$3}")
shm_size_gib=$(awk -v k="${size_k:-0}" "BEGIN{printf \"%.1f\", k/1024/1024}")
shm_used_gib=$(awk -v k="${used_k:-0}" "BEGIN{printf \"%.1f\", k/1024/1024}")
fi
root_pct=$(df / 2>/dev/null | awk "NR==2 {gsub(\"%\",\"\",\$5); print \$5+0}")
root_avail_k=$(df -k / 2>/dev/null | awk "NR==2 {print \$4}")
root_avail_gib=$(awk -v k="${root_avail_k:-0}" "BEGIN{printf \"%.1f\", k/1024/1024}")
jq -n \
--argjson shm_present "$shm_present" \
--argjson shm_size_gib "$shm_size_gib" \
--argjson shm_used_gib "$shm_used_gib" \
--argjson root_pct "${root_pct:-0}" \
--argjson root_avail_gib "$root_avail_gib" \
"{shm:{present:\$shm_present, size_gib:\$shm_size_gib, used_gib:\$shm_used_gib}, root:{used_pct:\$root_pct, avail_gib:\$root_avail_gib}}"
')
SHM_PRESENT=$(echo "$HOST_INFO_JSON" | jq -r '.shm.present // false')
SHM_SIZE=$(echo "$HOST_INFO_JSON" | jq -r '(.shm.size_gib // 0) | . * 10 | floor / 10 | tostring | if test("\\.") then . else . + ".0" end')
SHM_USED=$(echo "$HOST_INFO_JSON" | jq -r '(.shm.used_gib // 0) | . * 10 | floor / 10 | tostring | if test("\\.") then . else . + ".0" end')
ROOT_PCT=$(echo "$HOST_INFO_JSON" | jq -r '.root.used_pct // 0')
ROOT_AVAIL=$(echo "$HOST_INFO_JSON" | jq -r '(.root.avail_gib // 0) | . * 10 | floor / 10 | tostring | if test("\\.") then . else . + ".0" end')
if [[ "$SHM_PRESENT" != "true" ]]; then
concern "/dev/shm not present on host"
info "→ hyperpod-node-debugger § I (Resource Exhaustion) / hyperpod-nccl § 17"
NEXT+=("I")
else
info "/dev/shm (host): ${SHM_USED} GiB used of ${SHM_SIZE} GiB"
SHM_INT=${SHM_SIZE%.*}
if [[ "$SHM_INT" =~ ^[0-9]+$ ]] && (( SHM_INT < 16 )); then
concern "/dev/shm (host) is ${SHM_SIZE} GiB"
info "container view may differ (EKS emptyDir, enroot ipc-unshare); → hyperpod-node-debugger § I"
NEXT+=("I")
fi
fi
if [[ "$ROOT_PCT" =~ ^[0-9]+$ ]]; then
info "/ used: ${ROOT_PCT}% (${ROOT_AVAIL} GiB free of fixed 100 GiB root)"
if (( ROOT_PCT >= 90 )); then
concern "/ is ${ROOT_PCT}% full on $TGT_ID"
info "→ hyperpod-node-debugger § I.2 (Root Volume Exhausted)"
NEXT+=("I")
fi
fi
# ---------------------------------------------------------------------------
# Summary
# ---------------------------------------------------------------------------
section "Summary"
if [[ ${#NEXT[@]} -eq 0 ]]; then
ok "no concerns surfaced for the in-scope perf categories"
info "if the customer still reports slowness, route to the matching sibling skill (hyperpod-nccl, hyperpod-node-debugger, hyperpod-version-checker)"
else
mapfile -t UNIQ < <(printf '%s\n' "${NEXT[@]}" | sort -u)
for h in "${UNIQ[@]}"; do
case "$h" in
A) printf " ${BOLD}see SKILL.md § A (Uneven NCCL Performance)${NC}\n" ;;
B) printf " ${BOLD}see SKILL.md § B (Poor Filesystem Performance)${NC}\n" ;;
G) printf " ${BOLD}see hyperpod-node-debugger § G (GPU / Accelerator) — adjacent data point${NC}\n" ;;
I) printf " ${BOLD}see hyperpod-node-debugger § I (Resource Exhaustion) — adjacent data point${NC}\n" ;;
esac
done
fi
printf "\n"
info "sampled one node: $TGT_ID (${INSTANCE_TYPE:-unknown-type}) in group $TGT_GROUP"
info "re-run with --node <INSTANCE_ID> to target a specific node"
info "for continuous coverage of GPU / EFA / multi-node NCCL health, enable HyperPod NodeRecovery (HMA) and OnStartDeepHealthChecks"
Related skills
FAQ
Does this skill fix the problem itself?
No. It is read-only, surfaces host-side signals, and routes each concern to the owning sibling skill for remediation.
Why does a host version show unknown?
Many setups ship the EFA/libfabric/CUDA stack inside the training container, so a host value of unknown is not by itself a defect; verify inside the container via hyperpod-version-checker.