こんにちは、レッドハットサポートのクリスです。
大体、コンピュータの稼動に使われる電気エネルギーのほとんどは化石燃料によって生成されているので、気候変動に影響を与えます。電気も高いので、ITのエネルギー消費を把握するのは大切です。エネルギーを節約するための活動も増えています。2031 年までに消費電力を 40%削減するために協力している企業もあります。
Red Hat Enterprise Linux (RHEL) の Performance Co-Pilot (PCP) スイートは、パフォーマンス、デバッグ、可視化が出来ます。PCP には pmda-denki (日本語の電気という言葉で名付けた) が含まれています。pmda-denkiツールを使うと、電力消費量を測定できます。
powertopではリアルタイムでエネルギー消費量を測定できますが、長期的な測定はできません。PCPのメトリクスでは、メトリクスの保存、可視化、急激な増加への対応など利用できます。ワークロードの消費電力を比較するのは面白いと思いませんか？すでに多くの企業が、コミットしたばかりのソースコードの性能ベンチマークを行っている。コミットの消費電力を測定することで、新しいコードが効率的にはよくなったか、悪くなったか、分かります。
pmda-denkiは何ができるのか？
現在のシステムには、消費電力を測定するための専用センサーはほとんどありません。この記事では、3つのデータソースを使用して、コンピュータのワークロードの電力消費が分かります：
- RAPL：最新のx86システムのほとんどはRAPLでCPU、RAM、オンボードGPUの電力消費が測れます
- バッテリーの充電状態： バッテリーを搭載したノートパソコンのようなシステムでは、電源プラグを外し、バッテリーからワークロードを実行することができます。バッテリーの放電を観察することで、消費量を計算することができます
- スマートプラグ： スマートプラグは、電源コンセントとコンピューターシステムのような電気消費機器の間に挿入できるデバイスです。スマートプラグは、WLANまたはRJ-45を介してネットワークに接続し、接続された消費者の消費電力を報告する
上記の3つの方法には長所と短所があります。RAPLはx86アーキテクチャでしか利用できず、システム全体の消費量を測定できません。バッテリーとスマートプラグは、特定のハードウェアを要ります。では、いくつかのワークロードの消費電力を測定しましょう。
研究環境
システム2台を使いましょう：
- 制御システム：データの収集と可視化のシステム。SUT を準備し、テストを開始するために、PCP と Ansible エンジンがインストールされています
- 消費量を測定する被試験システム（System Under Test, SUT）。今回は、Thinkpad L480を使いました。Thinkpad L480は、3つの方法すべてが利用可能で、Linuxのサポートが良いので、選びました
このテストでは、ワークロードを間実行し、3 つの方法でエネルギー消費量を測定します。その後、さまざまな方法で測定された消費量を比較し、システムがどの程度効率的であったか、また単一のジョブに対してどの程度のエネルギーを消費したかを計算することができます。
初期設定
制御システムはFedora 38とPCP 6を使用します。代わりにRHEL 8またはRHEL 9システムを使用することもできます。
$ sudo dnf -y install pcp-zeroconf pcp-pmda-denki $ cd /var/lib/pcp/pmdas/denki/ && sudo ./Install $ cd /var/lib/pcp/pmdas/openmetrics/ && sudo ./Install
SUT は RHEL 9 を実行し、pcp と pmda-denkiをインストールし、制御シス テムが SUT から直接メトリクスを読み込めるように pmcd を構成しました。
$ sudo dnf -y install pcp pcp-pmda-denki pcp-system-tools $ cd /var/lib/pcp/pmdas/denki/ && sudo ./Install $ sudo echo 'PMCD_LOCAL=0' >>/etc/sysconfig/pmcd $ sudo systemctl restart pmcd $ sudo systemctl enable pmcd
これを実行すると、制御システムの電気関係のメトリクスが読めます：
$ pmrep -h <IP-of-SUT> denki
次に、スマートプラグのメトリクスを利用可能にします。詳細は、特定のスマート・プラグによって異なります。上品のプラグは、RJ-45イーサネットコネクターを使って消費メトリクスを提供します。この記事では、オープンソースのファームウェアTasmotaでサポートされているスマートプラグを使いました。スマートプラグは無線ネットワークに接続しています。制御システム上で、/etc/pcp/openmetrics/tasmotalive4.shというファイルを配置し、/var/lib/pcp/pmdas/openmetrics/config.d/tasmotalive4.shへのシンボリックリンクを作成しました。
このコマンドを実行してメトリックを照会すると、tasmotalive4.shが起動します：
$ pmrep openmetrics.tasmotalive4
tasmotalive4.shというスクリプトはこれを出力されます：
$ curl -s http://ip/cm?cmnd=Status%208
スクリプトは出力から消費電力を抽出します。このメトリクスはopenmetricsに渡され、pmrepで利用できるようになります。
3種類のメトリクスはすべて、制御システムから読むことができます。pmrepのようなクライアントで読み込むこともできるし、後で調べるためにアーカイブファイルに記録することもできます。
これでメトリクスにアクセスできるようになりました。例えば、以下はRAPL（1～4でラベル付けされた列）とtasmota（5列）のメトリクスであります：
$ pmrep -g denki.rapl.rate -p openmetrics.tasmotalive4.Power
[ 1] - denki.rapl.rate["package-0"] - /s
[ 2] - denki.rapl.rate["core"] - /s
[ 3] - denki.rapl.rate["uncore"] - /s
[ 4] - denki.rapl.rate["dram"] - /s
[ 5] - openmetrics.tasmotalive4.Power["0 var:out"] - none
1 2 3 4 5
17:38:13 N/A N/A N/A N/A N/A
17:38:15 4.578 2.289 0.000 0.183 8.000
17:38:16 4.973 3.978 0.000 0.000 0.000
17:38:17 4.855 2.913 0.000 0.971 12.000
17:38:18 5.046 3.027 0.000 0.000 12.000
17:38:19 6.208 4.138 0.000 1.035 12.000
ここの図形が出来ます：
今回のワークロード
上記のメトリクスが利用できるようになったので、SUT 上でワークロードを実行し、3 つの方法を使用して消費量を測定することができます。制御システム上で実行する Python3 ラッパースクリプトを作成しました。このスクリプトは、以下のタスクを実行します：
- Ansible playbook が SSH 経由で SUT にログインし、必要なパッケージがインストールします。Playbook はまた、実際の負荷スクリプトのようなファイルを SUT にコピーします
- スマートプラグの測定値が収集される場合、Ansible プレイブックは、制御システムが測定値をファイルにアーカイブするようにします。これにより、後でアーカイブファイルを確認し、負荷が実行されている間にスマートプラ グによって測定された消費電力を計算することができます
- その後、実際のワークロードが始まります。最初の負荷は、デフォルトで SUT 上でスリープを実行します。これは、後で計算ジョブに起因する負荷を適切に測定するために、可能な限り低くなければならないシステムのアイドル消費電力を提供する
- 次に、スクリプトにより SUT の全 CPU コアを負荷状態にします。最大消費量を測ります
- スクリプトは、ループで tar.xz ファイルを抽出し、抽出されたファイルを削除し、あらためて実行します。メモリ内で実行します。今回は、Apacheウェブ・サーバーのソースを抽出しています
- 最後に、スクリプトが少なくとも300秒間ループします。その期間、Apacheのソースをコピーし、'configure'を実行し、Apacheをコンパイルします
各ジョブの実行中の平均消費量を計算します。例えば、1回のApacheコンパイルにどれだけのエネルギーが消費されたかを計算します。
ここのスクリプトは例です。自分のワークロードを実行し、消費量を測定してください。例えば、あなたが書いたソフトウェアの2つのバージョンを実行し、それらの消費量を比較することができます。
ワークロードの消費量の測定
コンパイル・ジョブを実行したときの例：
### Running job_httpd_compile.sh for at least 300 sec..
executing: ssh -x chris@dennou "cd /dev/shm; ./job_httpd_compile.sh 300"
Workload did run 8 times, a single job did run 37.5 sec.
### RAPL
Average power consumption: 11.46 W
Single job run, power consumption: 0.11934 Wh
### Battery
Average power consumption: 16.68 W
Single job run, power consumption: 0.17375 Wh
それぞれの方法で測った消費量：
Job name | RAPL | Battery | Tasmota sleep | 0.2W | 1.4W | 2.7W just-load | 18.4W | 23.6W | 28.2W httpd-src-extract | 11.5W | 15.7W | 18.2W httpd-compile | 11.5W | 16.7W | 17.6W
最初のジョブは5分間システムをスリープさせます。Thinkpad L480で実行すると、この5分間で平均0.2Wが消費されたことがRAPLから報告されました。バッテリー測定では1.4W、スマートプラグでは2.7Wと報告されています。このパターンは他の負荷でも発生します： RAPLはCPU/メモリ/GPUのみを対象としており、最も低い測定値を報告しています。バッテリーの測定は、マザーボード、USBデバイスなどをカバーしています。その測った値はもっと高いです。スマートプラグの値はもっと高いです。
ジャストロード・ジョブでは、md5sum /dev/urandomのインスタンスを４つも動かしています。RAPLは18.4Wになります。この負荷でファンも回転しています。この追加消費は、バッテリーとTasmotaメトリクスの値に入っています。
他の2つのジョブでは、全部のcpuコアが使われていないので、消費は下がります。
重要なことは、様々な方法は異なる値を報告しますが、どの方法もワークロードを比較するには適しているということです。あるソフトウェアの2つのバージョンがある場合、これらの方法はすべて消費量の比較に役立ちます。
制御システム上で実行するスクリプト（SUT上でジョブを実行する）と、それから準備のためのAnsibleスクリプトは、私のGitリポジトリ から入手できます。ディレクトリdenki-jobrunnerにはジョブスクリプトがあり、openmetricsにはTasmotaスマートプラグからメトリクスを取得するスクリプトがあります。
それを気軽に使ってもよいですが、レッドハットサポート外となります。
消費電力メトリクス
消費電力メトリクスを利用可能にする方法と、さまざまなワークロードの消費電力を比較する方法が分かりました。利用可能な場合、pmda-denkiのバッテリーベースのメトリクスは、システム全体の消費電力を計算する事ができます。RAPLは一部のサブシステムをカバーしているだけですが、ほぼすべてのサーバーで利用可能です。PCP、pmda-denki、pmieを使用すれば、消費電力が突然上昇した場合にアラートを送信する事もできます。
KDEは持続可能性に関わるecoプロジェクトを開始し、フリーソフトウェアは持続可能なソフトウェアであるに関してのプレゼンテーションも増えています。pmda-denki のようなツールは、ワークロードの消費電力を比較し、新しいgitコミットが消費電力を増加させることに気づくのに役立ちます。
- PCP/Grafanaをインストール、pmda-denkiメトリクスを可視化する方法のブログ記事
- PCPのセットアップについての製品ドキュメントになります。新しいRHELバージョンがリリースされるとともに、更新されます。
- PCP/Grafanaを設定するための対ラボもあります
- pmda-denkiハンドブックにはインストールと使用例に関する詳細があります
この記事の英語版もあります。
