帯域外モニター
この記事は、インテル® デベロッパー・ゾーンに掲載されている「Measuring application power consumption on the Linux* operating system」(http://software.intel.com/en-us/blogs/2013/06/18/measuring-application-power-consumption-on-linux-operating-system) の日本語参考訳です。
電力消費は、HPC、クラウド、エンタープライズにかかわらず、大規模な計算システムにおける共通の懸念事項です。施設の電力制限やスペースの制約により、計算ニーズの急激な拡大を支えることはますます難しくなっています。そのため、ハードウェアからソフトウェアまで、さまざまなレベルで電力消費を抑える最良の方法を模索する必要があります。ここでは、この課題に取り組むための一般的なアプローチとツールについて説明します。
「ニーズ」を減らすことができない場合 (これはすぐには無理でしょう)、電力消費に対するアプローチには次のものがあります。
- より高速なアプリケーションを使用する (ソフトウェアをアウトソーシングしている場合) か、あるいは自社開発ソフトウェアでは並列処理を実装する。これにより、各計算ユニットの消費電力が少なくなります。最終的には、データセンターでより多くの処理が可能になり、施設を拡張する必要性は少なくなるでしょう。
- 使用していない不要なコンポーネントをハードウェアから取り外す。これには、不要なサーバーだけでなく、システム内のボード/コンポーネントも含まれます。
- 不要なソフトウェア・コンポーネントを無効にするか削除し、ジョブの「サイクル」を解放する。例えば、オペレーティング・システム・レベルの不要なサービスルーチンを無効にします。
- 消費電力が少ないシステムへアップグレードする。電力管理の進歩により、たいてい新しいハードウェアほど消費電力は少なくなります。
- システムやアプリケーションで消費する電力量を制限する (スループット全体に影響する可能性があります)。これは、システムの外部から実行するソフトウェア (インテル® ノード・マネージャーなど)、あるいはシステム内で実行するソフトウェアによって行えます。例えば、システムの BIOS 設定で省電力モードを有効にすることができます。さらに、仮想マシンモニター (VMM) では、使われていない仮装マシンをオフにするように設定したり、CPU の消費電力を制限できます。
設備投資を行う回数を減らしたい場合は、ソフトウェアをよく見直すべきでしょう。より高速に動かす以外に、次の点を考えてみます。
- 電力効率を高められるか?
- 実行時のソフトウェアの消費電力を把握する方法はあるか?
- 一般的にアプリケーションの電力フットプリントを向上または低下させる構成や手法はあるか?
私はこの質問をインテルの Linux* エキスパート達に聞いてみました。その回答を以下に説明します。多くの HPC クラスターやクラウドが Linux* で稼働しているため、ここでは Linux* に焦点を当てています。
電力のモニタリング・ツールには次の 2 つのカテゴリーがあります。
- 帯域外モニター
- 帯域内モニター
a. 帯域外モニター:
このモニターはシステム全体の消費電力に関する情報を示します。そのため、どのアプリケーションが大きく電力を消費しているかを確認することができません。利点は、統計の収集中、システムの消費電力には影響しないことです。帯域外モニターの 1 つの例は、インテル® ノード・マネージャーです。インテル® ノード・マネージャーは消費電力をレポートします。データは IPMI を介してアクセスできます。帯域内操作も可能ですが、データのサンプリングを頻繁にとりすぎると、高負荷のアプリケーションではオーバーヘッドが生じます。1 秒間隔では効率良いサンプリングはできないので、3-5 秒間隔にすることを推奨します。
b. 帯域内モニター:
帯域内モニターツールの多くは、(MSR を通じた) RAPL (Running Average Power Limit) カウンターなど、ハードウェア・レジスターを介した電力カウンターを基にしています。Sandy Bridge (開発コード名) マイクロアーキテクチャー・ベースのインテル® Xeon® プロセッサー E5 ファミリーはこのようなカウンターを備えています。これにより、高い消費電力のアプリケーションを特定できる詳細情報が得られる可能性があります。ただし、このアプローチのマイナス面は、データの収集自体が電力を消費してしまうことです。RAPL カウンターはミリ秒間隔で更新され、実際のデータではなく、内部プロセッサー・ヒューリスティックに基づいて、電力消費の推定値を提供します。これまでの経験則によると、データの精度は TDP (熱設計電力) レベルでは良く、低電力負荷レベルでは 10% ほど誤差があります。また、RAPL は、CPU とメモリーの電力情報のみ提供します。完全なプラットフォームの電力情報は提供しません。 Linux* 上のユーザー空間 (非特権) アプリケーションで消費電力統計を収集するには、msr.ko カーネルモジュールをロードします。アプリケーションには /dev/cpu/*/msr の読み取り権限が必要です。以下の表にあるほとんどのツールは、帯域内モニターツールと見なされます。
それぞれのニーズに最適な測定方法は、消費電力データをどのように使用するかによって異なります。インテルのエンジニアは、多くの場合、両方を利用します。電力効率の調査は単純なものではありません。次のような疑問について考える必要があります。
- オペレーティング・システムを使って電力を計測するべきか?
- システム全体の電力を測定する必要があるか?
- 電力効率からアプリケーションをどのように特定できるか?
- 問題を起こしているアプリケーションのコード領域へどのようにドリルダウンするか?
解析には帯域外モニターと帯域内モニターの両方のデータを使うことを推奨します。アプリケーションで何が行われているか、より完全なイメージを掴めるでしょう。問題のアプリケーションを特定したら、インテル® VTune™ Amplifier XE、インテル® Energy Checker SDK (以下の表を参照)、または pyTimechart を利用してドリルダウンできます。
次の表に、現在インテルのエンジニアが利用しているツール (とその目的) をまとめています。
| ツール | 説明と利点/欠点 |
| powertop (https://01.org/powertop/) | アプリケーションが何を行っているかを高レベルで表示します (‘top’ コマンドの出力表示に似ています)。コンピューターがアイドル状態のときに動作が不定となるプログラムを見つけるのに役立ちます。インテルの Linux* ユーザーによく使われています。 |
| インテル® Vtune™ Amplifier XE 2013 |
有償の GUI ツール。Linux* カーネル (2.6.32 以降) の電力解析をサポートします。この解析は、インテル® Xeon® システム (2010 年以降) および Android* を搭載するインテル® プロセッサー・ベースのタブレットやスマートフォンで実行できます。測定できる項目については、「How to use the power analysis types of Intel® VTune™ Amplifier XE 2013 on Linux」(http://software.intel.com/en-us/articles/how-to-use-the-power-analysis-types-of-intel-vtune-amplifier-xe-2013-on-linux) を参照してください。 |
| インテル® Energy Checker | アプリケーションのカウンターをインポート/エクスポートする関数を提供する API。ソフトウェア・インストルメンテーションを通じて、アプリケーションが行う「有益な処理」が分かります。 |
| インテル® Power Governor | 細粒度 (数十ミリ秒) で電力を監視し制御できるユーティリティーとライブラリー。パッケージ、コア、グラフィックス、アンコア、DRAM に利用できます。 |
| インテル® Performance Counter Monitor | 最新のインテル® Xeon® プロセッサーおよびインテル® Core™ プロセッサーの内部リソース使用状況を推定するサンプル C++ ルーチンとユーティリティーを提供します。 |
| turbostat | CPU 周波数と C ステートを追跡します。 |
| ipmitool とインテル® ノード・マネージャー | 帯域外データをサンプリングする組み合わせ。両ツールを一緒に使用すると、アプリケーションで何が行われているか、より完全なイメージを掴めます。インテルのサーバー・プラットフォームで ipmitool を使用する例を次に示します。
ipmitool -H ipmihost -U root -P root delloem powermonitor |
| Likwid | マルチノードの HPC アプリケーションをモニターするのに最適な軽量のパフォーマンス測定ツール。主に、メモリー/キャッシュの使用率とスレッド・コア・アフィニティーを測定します。 |
| インテル® Performance Bottleneck Analyzer | インテル® アーキテクチャー上でパフォーマンスに影響するコンポーネントを見つけて優先順位を付けます。パーシャルフラグ/レジスターストール、ストア・フォワーディング、L2 ミスなどのアーキテクチャー上の問題を検出します。Linux* アプリケーションのサポートは制限されています。詳細は、ユーザーガイドを参照してください。 |
| PyTimechart | C ステート終了を引き起こすイベントを確認できます。これには、システムを頻繁にウェイクアップさせる (消費電力の増大につながる) イベントも含まれます。 |
多くの電力を消費しているアプリケーションを突き止めたら、次はどうしますか?
ソフトウェア開発の経験則がどのように電力消費を左右するかについて、多くのリソースが提供されています。インテルの電力効率コミュニティー (http://software.intel.com/en-us/energy-efficient-software) には良いアドバイスが掲載されています。『Energy Aware Computing』という書籍では、データセンターにおける電力効率の良いソフトウェアについて述べています。これらの情報に目を通すことをお勧めします。
一般的な概念としては、不要な処理を最小限に抑えることです。例えば、gettimeofday() の過度の呼び出しや繰り返されるイベントを確認します。システムコールを最小限にすることも重要です。一部の API とシステムコールは多くの電力を消費します。アプリケーションの詳細な解析から I/O パターンを把握し (キャッシュミスが多いかどうかなど)、データ授受を高めるとともに、(システム時間に対して) ユーザー時間を最大限にします。これらすべてを考慮してください。
電力効率コミュニティー・フォーラム (http://software.intel.com/en-us/forums/power-efficiency) もぜひご利用ください。
コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。
