Strategies to Measure Energy Consumption Using RAPL During Workflow Execution on Commodity Clusters

TL;DR

This paper explores three methods to measure energy consumption during scientific workflows on Kubernetes clusters using Intel RAPL, evaluating their accuracy, ease of implementation, and challenges, to promote energy-efficient computing.

Contribution

It introduces and compares three practical methods for RAPL-based energy measurement in Kubernetes environments, highlighting their advantages, limitations, and implementation considerations.

Findings

Shell script and Nextflow plugin methods are effective and easy to implement.

Single-task energy measurement is straightforward, but concurrent tasks require approximation.

Using CPU utilization metrics helps estimate energy for concurrent tasks.

Abstract

In science, problems in many fields can be solved by processing datasets using a series of computationally expensive algorithms, sometimes referred to as workflows. Traditionally, the configurations of these workflows are optimized to achieve a short runtime for the given task and dataset on a given (often distributed) infrastructure. However, recently more attention has been drawn to energy-efficient computing, due to the negative impact of energy-inefficient computing on the environment and energy costs. To be able to assess the energy-efficiency of a given workflow configuration, reliable and accurate methods to measure the energy consumption of a system are required. One approach is the usage of built-in hardware energy counters, such as Intel RAPL. Unfortunately, effectively using RAPL for energy measurement within a workflow on a managed cluster with the typical deep software infrastructure stack can be difficult, for instance because of limited privileges and the need for communication between nodes. In this paper, we describe three ways to implement RAPL energy measurement on a Kubernetes cluster while executing scientific workflows utilizing the Nextflow workflow engine. We compare them by utilizing a set of eight criteria that should be fulfilled for accurate measurement, such as the ability to react to workflow faults, portability, and added overhead. We highlight advantages and drawbacks of each method and discuss challenges and pitfalls, as well as ways to avoid them. We also empirically evaluate all methods, and find that approaches using a shell script and a Nextflow plugin are both effective and easy to implement. Additionally, we find that measuring the energy consumption of a single task is straight forward when only one task runs at a time, but concurrent task executions on the same node require approximating per-task energy usage using metrics such as CPU utilization.