Characterizing the I/O Behavior of HPC Applications through Modeling and Simulation

• Parallel applications can underperform because of resource contention, network congestion, and inefficient I/O, including contention from simultaneous accesses.Source: §I · p. 1
• Modeling I/O workloads supports storage evaluation, bottleneck identification, and improved scheduler decisions, but accurate models are difficult because hardware and input parameters affect performance.Source: §I · p. 1
• The framework uses HPCIO application profiles and creates ElastiSim applications that reproduce repository traces under different resource utilization levels.Source: §I · pp. 1–2
• The work evaluates real use cases for I/O congestion and validates ElastiSim with Jacobi and EpiGraph on real and simulated HPC platforms.Source: §I · p. 2

• Existing HPC I/O performance techniques include statistical analysis, predictive analytics, replay-based methods, and workload generation.Source: §II · p. 2
• Predictive approaches analyze historical data to identify performance issues in advance, while autotuning systems reduce the complexity exposed by the I/O stack.Source: §II · p. 2
• Replay-based approaches analyze historical traces to generate workloads that reproduce the original application's I/O behavior.Source: §II · p. 2
• This work uses real HPCIO traces to replicate application I/O access patterns in ElastiSim and analyze congestion based on those patterns.Source: §II · p. 2

• ElastiSim supports performance models for computation and I/O tasks and focuses on rigid, malleable, and evolving workloads.Source: §III · p. 2
• ElastiSim is a discrete-event simulator whose application models specify the load introduced to the simulated platform.Source: §III · p. 2
• The use cases include Quantum Espresso distributions for electronic-structure calculations and materials modeling.Source: §IV · p. 2
• Nek5000 is an open-source solver, while WaComM++ supports simulations and predictions of pollutant transport and dispersion in coastal environments.Source: §IV · p. 2
• Validation applications include Jacobi for iterative linear-system solutions and EpiGraph for stochastic simulations of COVID-19 propagation.Source: §IV · p. 3

Framework overview

• The framework collects native traces and execution-environment information before constructing simulated application profiles.Native traces record read/write volumes over equal-duration intervals, while native platforms are examined by I/O bandwidth and computation power.Source: §V · p. 3
• The application profile algorithm estimates computation and I/O durations for every native trace interval.It assumes CPU and I/O times exceed communication times, so communication overhead is omitted in the current framework version.Source: §V · p. 3
• The converter translates profiles from multiple native systems to a single reference platform using CPU-power and I/O-bandwidth differences.This enables comparison of trace behaviors in one simulated execution environment.Source: §V · p. 3, A. Trace importing and application… · pp. 3–4
• The sampling phase converts simulated profiles into sampled I/O traces containing interval-specific data amounts and computation durations.A sampling window may contain one or more intervals and is defined by its start and end times.Source: §V · p. 3, A. Trace importing and application… · p. 3

Trace importing and application profiles

• QePh illustrates the workflow by comparing native JUWELS execution with simulated reference-platform traces and profiles.Platform-performance differences can make simulated interval times differ from original times; faster platforms reduce CPU and I/O durations.Source: Figure 2 · p. 4, A. Trace importing and application… · p. 4

Application profile sampling

• The sampling algorithm processes profile intervals within a specified window to generate the simulated I/O trace.It uses the sampled data amount, window start and end times, and interval execution times to determine sample sizes.Source: B. Application profile sampling and… · p. 4

Model calibration

• The calibrated application model alternates CPU and I/O phases, with each I/O phase processing the data amount assigned to its corresponding trace interval.The initial model contains as many phases as the I/O trace has intervals.Source: B. Application profile sampling and… · p. 4
• Algorithm 1 takes task times, an application model, and a threshold as input and outputs an updated application model.Its loop continues while the error exceeds the threshold and updates the model after comparing I/O times and phase durations.Source: B. Application profile sampling and… · p. 5
• Calibration iteratively adjusts phase Flops upward or downward until simulated phase durations match sampled-trace intervals within a threshold.The procedure reduces Flops when observed duration is too long and increases them when it is too short.Source: B. Application profile sampling and… · p. 5

Evaluation

• The study analyzes modeled applications under interference scenarios and separately validates simulation against real benchmark executions.Jacobi and EpiGraph are the benchmark applications used for comparing simulated and real execution times.Source: §VI · p. 5

System platform characterization

• The reference platform contains 4300 nodes with 48 cores each and a modeled peak node performance of 3.2 Tflops.Each processor is specified as an Intel Xeon Platinum 8160 24C at 2.1 GHz.Source: A. System platform characterization · p. 5
• Its parallel file system is modeled as one shared storage tier accessible to all compute nodes.The storage tier uses the MareNostrum 4 GPFS 4.2.2.0 type.Source: A. System platform characterization · p. 5

• The modeled use cases are Quantum Expresso-PHonon, Quantum Expresso Car-Parrinello, Nek5000, and WaComM++.Source: B. Application modelling · p. 5
• Figure 4 encodes I/O data volume per interval against node count and interval number.The z-axis is I/O data volume, the y-axis is nodes, and the x-axis is trace intervals.Source: B. Application modelling · p. 5
• Each trace retains the same number of intervals across node counts, normalizing traces even though execution time decreases with more nodes.Source: B. Application modelling · p. 5

• Application models generated on the HPC4AI cluster are tested for reproducing Jacobi and EpiGraph behavior on UC3M’s C3 cluster.Source: C. Framework and ElastiSim validation · pp. 5–6
• Jacobi and EpiGraph traces are captured with Darshan, converted into ElastiSim-compatible traces, and used to generate application performance models.Source: C. Framework and ElastiSim validation · pp. 5–6
• Figure 5 compares simulated and real I/O phases using timestamps and execution-time accuracy for Jacobi and EpiGraph.Each bar represents an application I/O phase.Source: C. Framework and ElastiSim validation · p. 6, Figure 5 · p. 6
• EpiGraph’s checkpoint spacing changes across simulated COVID-19 waves, yet the HPC4AI-derived model reproduces this complex pattern on C3.Source: C. Framework and ElastiSim validation · p. 6
• 98.8% and 98.1% accuracy are reported for reproducing the performance behavior of Jacobi and EpiGraph with ElastiSim.Source: C. Framework and ElastiSim validation · p. 6

Experimental setup

• The experiments assume same-type jobs with equal node allocations, different submit times, no resource oversubscription, and sufficient simulated CPU cores.Source: D. Performance evaluation · p. 7

Concurrent applications

• Increasing concurrent QePh jobs reduces one application's I/O throughput because they compete for parallel-file-system bandwidth.QePh reaches the 250 GB/s file-system bandwidth with two simultaneous jobs; contention is lower near the final 20% of execution.Source: D. Performance evaluation · p. 7
• WaComM++ I/O throughput is affected only when a much larger number of jobs runs simultaneously.Source: D. Performance evaluation · p. 7

Increasing job size

• Increasing QePh job size degrades one application's throughput under both uniform and distributed data patterns.With uniform data, replicated data increases I/O pressure; with distributed data, aggregated throughput exceeds parallel-file-system throughput.Source: D. Performance evaluation · p. 7
• The distributed pattern reduces contention during the final 20% of execution because data is distributed across nodes, lowering filesystem pressure.Source: D. Performance evaluation · p. 7

Mixed workloads

• When QePh and Nek constitute 10% of a distributed workload, degradation begins at 32 concurrent jobs and remains below 20%.At 25% and 50% I/O-intensive workload profiles, degradation begins with fewer jobs and becomes larger.Source: D. Performance evaluation · p. 8

• The framework creates ElastiSim applications that reproduce real-world I/O traces from the HPCIO repository.Source: §VII · p. 8
• Evaluation across real-world application use cases indicates feasible and accurate reproduction of native applications in simulation.Source: §VII · p. 8
• The framework enables fine-grained insights into platform performance from the I/O perspective.Source: §VII · p. 8
• Future work includes simulating malleable jobs, developing I/O-aware malleable scheduling, adding burst buffers, and refining performance models.Source: §VII · p. 8