電力管理ガイド fedora 14€¦ · 電力管理ガイド ドラフト fedora 14...
TRANSCRIPT
Fedora 14
電力管理ガイド
Fedora における電力消費の管理について
Domingo Don [FAMILY Given]
Landmann Rüdiger [FAMILY Given]
電力管理ガイド ドラフト
Fedora 14 電力管理ガイドFedora における電力消費の管理についてエディッション 1
著者 Domingo Don [FAMILY Given]著者 Landmann Rüdiger [FAMILY
Given][email protected]
Copyright © 2010 Red Hat Inc. and others.
The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document,and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA.In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the InfinityLogo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and othercountries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the UnitedStates and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union andother countries.
All other trademarks are the property of their respective owners.
このドキュメントでは、Fedora 14 システムで効果的に電力消費を管理する方法を説明しています。以下のセクションでは電力消費を低減する異なる技術（サーバーとラップトップの両方）と、各技術がシステムの全体的なパフォーマンスにいかに影響するかを説明します。なお、このドキュメントはまだ開発中であり、大幅に変更される可能性があります。そのため現時点でプレビューとして提供されています。本文中にある内容と指導事項はまだ完全でなく、注意して取り扱う必要があります。
ドラフト ドラフト
iii
序文 v1. 表記方法 ......................................................................................................................... v
1.1. 印刷における表記方法 ............................................................................................ v1.2. 引用における表記方法 ........................................................................................... vi1.3. 注記および警告 ................................................................................................... vii
2. フィードバック .................................................................................................................. vii
1. 概説 11.1. 電力管理の重要性 ........................................................................................................ 11.2. 電力管理の基礎 ............................................................................................................ 2
2. 電力管理の監査と分析 52.1. 監査と分析の概要 ......................................................................................................... 52.2. PowerTOP .................................................................................................................. 52.3. Diskdevstat と netdevstat ............................................................................................ 72.4. Battery Life Tool Kit ................................................................................................. 102.5. Tuned と ktune ......................................................................................................... 11
2.5.1. tuned.conf ファイル ......................................................................................... 122.5.2. Tuned-adm .................................................................................................... 14
2.6. UPower .................................................................................................................... 162.7. GNOME Power Manager .......................................................................................... 172.8. 監査用の他の手段 ...................................................................................................... 17
3. コアインフラストラクチャとメカニクス 193.1. CPU のアイドル状態 .................................................................................................... 193.2. CPUfreq Governors の使用 ......................................................................................... 19
3.2.1. CPUfreq Governor のタイプ ............................................................................ 203.2.2. CPUfreq のセットアップ .................................................................................... 213.2.3. CPUfreq のポリシーと速度のチューニング ........................................................... 22
3.3. サスペンドとレジューム ................................................................................................. 233.4. Tickless カーネル ....................................................................................................... 233.5. Active-State Power Management .............................................................................. 243.6. Aggressive Link Power Management ......................................................................... 243.7. Relatime ディスクアクセスの最適化 .............................................................................. 253.8. パワーキャッピング（Power Capping） ............................................................................ 263.9. Enhanced Graphics Power Management .................................................................. 273.10. RFKill ...................................................................................................................... 283.11. ユーザースペースの最適化 ......................................................................................... 28
4. 使用ケース 314.1. 例 — サーバー ........................................................................................................... 314.2. 例 — ラップトップ ........................................................................................................ 32
A. 開発者へのヒント 35A.1. スレッドを使用 ............................................................................................................. 35A.2. Wake-ups（目覚め） .................................................................................................... 36A.3. Fsync ........................................................................................................................ 37
B. 改訂履歴 39
iv
ドラフト ドラフト
v
序文
1. 表記方法本ガイドは特定の単語や語句を強調したり、 記載内容の特定部分に注意を引かせる目的で次のような表記方法を使用しています。
PDF版 および印刷版では、 Liberation Fonts1 セットから採用した書体を使用しています。 ご使用のシステムに Liberation Fonts セットがインストールされている場合、 HTML 版でもこのセットが使用されます。 インストールされていない場合は代替として同等の書体が表示されます。 注記: Red Hat Enterprise Linux 5 およびそれ以降のバージョンにはデフォルトで Liberation Fonts セットが収納されます。
1.1. 印刷における表記方法特定の単語や語句に注意を引く目的で 4 種類の表記方法を使用しています。 その表記方法および適用される状況は以下の通りです。
等幅の太字
シェルコマンド、ファイル名、パスなどシステムへの入力を強調するために使用しています。またキー配列やキーの組み合わせを強調するのにも使用しています。 例えば、
現在作業中のディレクトリ内のファイル my_next_bestselling_novel の内容を表示させるには、 シェルプロンプトで cat my_next_bestselling_novel コマンドを入力してから Enterを押してそのコマンドを実行します。
上記にはファイル名、シェルコマンド、キーが含まれています。 すべて等幅の太字で表されているため文中内で見分けやすくなっています。
キーが 1 つの場合と複数のキーの組み合わせになる場合を区別するため、 その組み合わせを構成するキー同士をハイフンでつないでいます。 例えば、
Enter を押してコマンドを実行します。
1 番目の仮想ターミナルに切り替えるは、 Ctrl+Alt+F2 を押します。 X-Windows セッションに戻るには、 Ctrl+Alt+F1 を押します。
最初の段落では押すべき 1 つのキーを特定して強調しています。 次の段落では同時に押すべき 3 つのキーの組み合わせが 2 種類ありそれぞれ強調されています。
ソースコードの説明では 1 段落内で提示されるクラス名、 メソッド、 関数、 変数名、 戻り値を上記のように 等幅の太字 で表示します。 例えば、
ファイル関連のクラス群はファイルシステムに対しては filesystem、 ファイルには file、 ディレクトリには dir をそれぞれ含みます。 各クラスは個別に関連する権限セットを持っています。
プロポーショナルの太字
アプリケーション名、 ダイアログボックスのテキスト、ラベル付きボタン、 チェックボックスとラジオボタンのラベル、 メニュータイトルとサブメニュータイトルなどシステム上で見られる単語や語句を表します。 例えば、
1 https://fedorahosted.org/liberation-fonts/
序文 ドラフト
vi
メインメニューバーから システム > 個人設定 > マウス の順で選択し マウスの個人設定 を起動します。 ボタン タブ内で 左ききのマウス チェックボックスをクリックしてから 閉じる をクリックしマウスの主要ボタンを左から右に切り替えます (マウスを左ききの人が使用するのに適した設定にする)。
gedit ファイルに特殊な文字を挿入する場合は、 メインメニューバーから アプリケーション >アクセサリ > 文字マップ の順で選択します。 次に 文字マップ メニューバーから 検索 > 検索… と選択して 検索 フィールド内にその文字名を入力し 次 をクリックします。 探している文字が 文字表 内で強調表示されます。 この強調表示された文字をダブルクリックすると コピーするテキスト フィールド内に置かれるので次に コピー ボタンをクリックします。 ここでドキュメントに戻り gedit メニューバーから 編集 > 貼り付け を選択します。
上記には、 アプリケーション名、 システム全体のメニュー名と項目、 アプリケーション固有のメニュー名、 GUIインタフェースで見られるボタンやテキストがあります。 すべてプロポーショナルの太字で表示されているため文中内で見分けやすくなっています。
等等等等等等等等等等 または 等等等等等等等等等等等等等等等等
等幅の太字やプロポーショナルの太字はいずれであっても斜体の場合は置換可能なテキストか変化するテキストを示します。 斜体は記載されている通りには入力しないテキスト、あるいは状況に応じて変化する出力テキストを表します。 例えば、
ssh を使用してリモートマシンに接続するには、 シェルプロンプトで [email protected] と入力します。 リモートマシンが example.com であり、 そのマシンで使用しているユーザー名が john なら ssh [email protected] と入力します。
mount -o remount file-system コマンドは指定したファイルシステムを再マウントします。 例えば、 /home ファイルシステムを再マウントするコマンドは mount -o remount /homeになります。
現在インストールされているパッケージのバージョンを表示するには、 rpm -q package コマンドを使用します。 結果として次を返してきます、 package-version-release。
上記の太字斜体の単語 — username、 domain.name、 file-system、 package、 version、 release に注目してください。 いずれもコマンドを発行するときに入力するテキスト用のプレースホルダーかシステムにより出力されるテキスト用のプレースホルダーになっています。
タイトル表示のような標準的な使用の他、 斜体は新しい重要な用語が初めて出現する場合にも使用されます。 例えば、
Publican は DocBook の発行システムです。
1.2. 引用における表記方法端末の出力とソースコード一覧は、視覚的に周囲の文から区別されています。
端末に送信される出力は mono-spaced roman (等幅の Roman) にセットされるので以下のように表示されます。
books Desktop documentation drafts mss photos stuff svnbooks_tests Desktop1 downloads images notes scripts svgs
ソースコードの一覧も mono-spaced roman (等幅の Roman) でセットされますが、以下のように強調表示されます。
package org.jboss.book.jca.ex1;
ドラフト 注記および警告
vii
import javax.naming.InitialContext;
public class ExClient{ public static void main(String args[]) throws Exception { InitialContext iniCtx = new InitialContext(); Object ref = iniCtx.lookup("EchoBean"); EchoHome home = (EchoHome) ref; Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); }}
1.3. 注記および警告情報が見過ごされないよう 3 種類の視覚的なスタイルを使用して注意を引いています。
注記
注記は説明している部分に対するヒントや近道あるいは代替となる手段などになります。注記を無視しても悪影響はありませんが知っておくと便利なコツを見逃すことになるかもしれません。
重要
重要ボックスは見逃しやすい事項を詳細に説明しています。現在のセッションにのみ適用される設定上の変更点、 更新を適用する前に再起動が必要なサービスなどがあります。重要ボックスを無視してもデータを喪失するような結果にはなりませんがイライラ感やフラストレーションが生じる可能性があります。
警告
警告は無視しないでください。警告を無視するとデータを喪失する可能性が非常に高くなります。
2. フィードバック
本ガイドに誤植を見つけられた場合や本ガイドの改善案をお持ちの場合はぜひお知らせください。 Bugzillahttp://bugzilla.redhat.com/bugzilla/ にて、 Product には Fedora Documentation. を選びレポートの提出をお願いいたします。
バグレポートを提出される場合は、 そのガイドの識別子となる power-management-guide を必ず明記して頂くようお願いします。
序文 ドラフト
viii
ドキュメントに関する改善のご意見についてはできるだけ具体的にお願いいたします。 エラーを発見された場合は、 セクション番号および該当部分の前後の文章も含めてご報告頂くと照合が容易になります。
ドラフト ドラフト
1
概説コンピュータに使用する電力を制限していくということは、グリーン IT という観点でもっとも重要となる課題のひとつであり、このグリーンITはリサイクルできる資源の利用、ハードウェアの製造により環境に及ぼす影響、システム設計やシステム導入における環境意識などといった点についても配慮しています。本ガイドではFedora 14 が稼働するシステムでの電力管理について説明しています。
1.1. 電力管理の重要性
電力管理の中核には、各システムコンポーネントの電力消費をいかに効果的に最適化すべきかの理解があります。これにはシステムが実行する異なるタスクの研究を必要とします。そして各コンポーネントを設定してその仕事に対してパフォーマンスが適切であることを確実にしなければなりません。
電力管理の主な理由には次のようなものがあります。
• コスト節約のための全体的な消費電力の削減
電力管理の正しい活用は以下の結果を生みます:
• サーバーとデータセンターの熱削減
• 冷却、空間、ケーブル、発電機、および UPS (無無無無無無無) を含む二次コストの削減
• ノート PC のバッテリー寿命の延長
• CO2排出量の低減
• グリーン IT に関して政府の規則、または法的要請に適合すること。例えば、Energy Starなど
• 新システムにおける企業のガイドラインに適合すること
原則としては、特定コンポーネント（またはシステム全体）の消費電力を低減することは、発生熱の低下になり、そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低下を、特にミッションクリティカルな システムに於いて研究してテストするべきです。
システムが実行する諸々のタスクを研究して、ジョブに対してパフォーマンスがちょうど十分であるように各コンポーネントを設定することで、 エネルギーを節約し、発熱を減らし、そしてラップトップのバッテリ寿命を最適化することができます。電力消費に関するシステムの分析と チューニングの為の原則の多くはパフォーマンスチューニングの原則と良く似ています。システムは通常、パフォーマンスか電力に向けて最適化してあるため、ある程度は電力管理とパフォーマンスチューニングはシステム設定に於いて対立するアプローチを取ります。本ドキュメントでは、 Fedora Project が提供するツールとこのプロセスでユーザーを支援するために弊社が開発してきた技術を説明しています。
Fedora 14 は多くの新しい電力管理機能を搭載しており、デフォルトで有効になっています。これらはすべて、標準的なサーバーまたはデスクトップ使用のパフォーマンスに影響を与えないように配慮されています。しかし、特殊な利用ケースで最大のスループット、最小の遅延、また最高の CPU パフォーマンスが絶対的に要求される状態では、これらのデフォルト設定の見直しが必要でしょう。
本ドキュメントで説明してある技術を使用してマシンを最適化すべきかどうかの判断には、以下のような自問をして見てください:
問： 電力を最適化すべきですか？
答： 電力最適化の重要性は、企業が追従すべきガイドラインを持っているかどうか、または達成すべき基準があるかどうかによって変化します。
第1章 概説 ドラフト
2
問： どれくらい最適化する必要がありますか ?
答： ここで紹介してある技術のいくつかは、マシンの詳細に渡る監査と分析の全プロセスを実践することを要求しません。しかし、その代わりに標準的な電力使用を普通に最適化できる方法のセットを提供します。これらの方法はもちろん手動のシステム監査と最適化ほど良くはありませんが、 十分な妥当性を提供します。
問： 最適化はシステムパフォーマンスを容認できないレベルまで下げますか ?
答： このドキュメント内に説明してあるほとんどの技術は使用システムに認識できるほどの影響を与えます。Fedora 14 内にすでに設定されてあるデフォルト値を超過するような電力管理の実装を選択した場合、電力最適化を実行した後のシステムパフォーマンスを監視して、 パフォーマンス損失が容認できるかどうかを判断する必要があります。
問： 最適化に時間やリソースを費した場合、そこから得られる結果より負担の方が大きくなってしまいますか？
答： 1台のシステムを全プロセスにしたがい手作業で最適化を行っても、その時間やリソースはマシンの寿命が尽きるまでに得られるであろう利便性をはるかに上回ってしまうため意味がありません。 一方、 1 万台のデスクトップシステムが複数のオフィスに分散しているが構成および設定は同じものを使用している場合なら、最適化した設定をひとつ構成してそれを 1 万台すべてのマシンに適用していけば十分に役立つ可能性が高くなります。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシステムに効果を与えるかを説明しています。
1.2. 電力管理の基礎
効率的な電力管理は以下のような原則の上に確立されています:
アイドル状態の CPU は必要な時にだけ活動すべきであるFedora のカーネルは各 CPU に対して定期的なタイマーを使用していました。このタイマーは、プロセスが実行中であるかどうかに関係なく、毎回のタイマーイベント（セッティングにより数ミリ秒毎に発生）で CPU がプロセスすることを要求するため、CPU が本当にアイドル状態に入ることを妨げていました。効率的な電力管理の大部分は CPU が目覚める頻度を低減することに関連します。
この理由で、Fedora 14 内の Linux カーネルは定期的なタイマーを取り除いています。その結果、CPU の アイドル状態は 無無無無無無無tickless無です。これが、CPU のアイドル時には CPU が不要な電力消費を防止します。しかし、システムが不要なタイマーイベントを作り出すアプリケーションを持っている場合にはこの機能からの利便性は、オフセットされてしまいます。ポーリングイベント（音量の変更、マウス動作、その他をチェックするもの）はそのようなイベントの例になります。
Fedora 14 には、CPU 使用率を基にしたアプリケーションの識別と監査をできるツールが含まれています。その詳細には、2無無無無無無無無無無無 を参照して下さい。
使用していないハードウェアとデバイスは完全に無効にすべきである稼働部品を持つデバイス（例えば、ハードディスク）には特に分かりやすい例でしょう。これに加えて、一部のアプリケーションは使用中でなくても有効なデバイスを「オープン」状態で維持するものがあります。これが発生すると、カーネルはデバイスは「使用中」だと想定してデバイスが節電状態に入ることを妨げてしまいます。
ドラフト 電力管理の基礎
3
低活動は低ワット数と解釈すべきであるしかし多くのケースでは、この事は最新のハードウェアと正しい BIOS 設定に依存します。旧式のシステムコンポーネントは多くの場合、 現在 Fedora 14 がサポートする新しい省電力機能の一部をサポートしません。お使いのシステムに最新の公式なファームウェアを使用していることと、BIOS 内の電力管理設定、またデバイス設定のセクションが電力管理を有効にしていることを確認して下さい。 ここで確認すべき機能には以下が含まれます。
• SpeedStep
• PowerNow!
• Cool'n'Quiet
• ACPI (C-状態)
• Smart
使用中のハードウェアがこれらの機能をサポートしていて、BIOS 内で有効になっている場合は、Fedora 14は、それらをデフォルトで使用します。
異なる形式の CPU の状態とその効果ACPI (Advanced Configuration and Power Interface) を持つ最近の CPU は、次の3つの異なる電力状態を持ちます。
• Sleep (C-状態)
• Frequency (P-状態)
• 発熱 (T-状態もしくは温度状態)
最低可能なスリープ状態で実行している CPU は最小ワット数を消費しますが、必要な時にこの状態から起こす時に無視できない時間を必要とします。 稀なケースでは、CPU がスリープに入る度にすぐに起きる必要がある状況になります。この状況は結果として常に多忙な CPU を生み出して 他の状態を使用する場合に達成可能なはずの節電を実現できなくなります。
オフになっているマシンは最低限の電力を使用する当たり前のように聞こえますが、確実に節電をする最良の方法の1つはシステムの電源をオフにすることです。例えば、所属する企業が「グリーン IT」の意識に焦点を置く企業文化を定め、昼食時や帰宅時にマシンの電源オフにするガイドラインを策定することができます。また、数台の物理サーバーを1つの大きなサーバーに統合して、Fedora 14 で提供されている仮想化技術を使用してサーバーを仮想化をすることもできます。
4
ドラフト ドラフト
5
電力管理の監査と分析
2.1. 監査と分析の概要
通常、単独システムの詳細に渡る手動の監査、分析、およびチューニングの実行にかかる時間と経費は、システムチューニングの最後の操作から得ることができる結果よりもが大きくなるためそれは特例的なものです。しかし、全てのシステムに同じ設定を繰り返すことができるようなほとんど同一の大規模なシステム群においてはこれらのタスクを一度実行すると、非常に便利になります。例えば、マシンがほぼ同一の数千台のデスクトップ、また HPC クラスター の導入を想像して下さい。監査と分析を実行するもう1つの理由は将来のシステム動作に於ける後退や変化を識別するための比較を提供することです。この分析の結果はハードウェア、BIOS、またはソフトウェアの更新が定期的に発生して電力消費に関する予想外事態を避けたい場合に役立ちます。一般的に徹底的な監査と分析は特定のシステムで発生している現状を把握できるようにしてくれます。
電力消費に関しての監査と分析は、最新のシステムを使用しても比較的に難しいものです。ほとんどのシステムはソフトウェアを介した 電力使用の測定をするのに必要な手段を提供しません。ただし、例外はあります。Hewlett Packard のサーバーシステムにある iLO の管理コンソールは Web を通じてアクセス可能な電力管理モジュールを持っています。IBM は BladeCenter 電力管理モジュールで同様なソリューションを提供しています。一部の Dell システムでも、IT Assistant が電力監視能力を提供しています。他のベンダーもそれぞれサーバープラットフォーム用に似たような機能を提供する可能性はありますが、お判りのように全てのベンダーに対応するような１つのソリューションが存在することはありません。ご使用のシステムが電力消費を測定する手段を組み込んでいない場合は、いくつか他の選択肢が存在します。USB 経由で電力消費情報を提供する特殊な電力供給を インストールすることが可能です。Gigabyte Odin GT 550 W 電源ユニットはその例の1つです。そして Linux において、これらの値を取得できるソフトウェアとしては、外部の http://mgmt.sth.sze.hu/~andras/dev/gopsu/ から入手できます。最後の手段として、USB コネクタを持つ外付けのワットメーター Watts up? PRO も存在します。
電力消費の一元的な測定は、多くの場合可能な限り最大限の節減をする必要があるだけです。但し他の方法で、変更が反映されているかどうかや、システムがどのように動作しているかなどを測定することもできます。この章では、そのための必要なツールについて説明しています。
2.2. PowerTOPFedora でのティックレスカーネル (無Tickless 無無無無無 を参照) の導入により、CPU がもっと高い頻度で アイドル状態に入るようになりました。これにより消費電力を低減し電力管理を向上しています。 この新しいPowerTOP ツールはカーネルと、CPU を頻繁に目ざますユーザーアプリケーションの特定コンポーネントを識別 します。PowerTOP は、無無無無無無無無無無無無無無 に説明してある 監査を実行するために開発部門で使用されていました。それがこのリリースに於いて多くのアプリケーションがチューンされる結果となり、 不要な CPU の目覚めを約 10分の１に低減したのです。
以下のコマンドを使用して PowerTOP をインストールします:
yum install powertop
以下のコマンドを使用して PowerTOP を実行します:
powertop
PowerTOP を実行するには、root 権限を使用してアプリケーションが役立つ作業をするようにしなければなりません。
実行すると、PowerTOP はシステムから統計を収集して CPU に最も頻繁に起こす（ウェイクアップ）を 送信しているコンポーネントの一覧をユーザーに提示します。PowerTOP はまた、省電力のためにシステムの
第2章 電力管理の監査と分析 ドラフト
6
チューニング方法も提案します。これらの提案は画面の底辺に表示され、そして PowerTOP の提案を確定するために押すキーを指定します。PowerTOP は定期的にリフレッシュするため、更なる提案が表示されます。無2.1無PowerTOP 無無無無 では、提案、increase the VM dirty writeback time とその提案を確定するために押すキー (W) に注目して下さい。
実行すると、PowerTOP はまたシステムから統計を収集してユーザーにいくつかの重要な情報の一覧を提示します。 その最初には CPU コアが各使用可能な C 状態と P 状態に滞在した時間の長さの一覧があります。CPU がより高い C 状態又は P 状態に長く滞在すれば するほど、良くなり（C3 より C4 が高い）、これはシステムが CPU 活用について良くチューンされている ことの指標になります。ユーザーの目標は、システムがアイドル中には最高の C 状態、又は P 状態に 90% 以上在留することです。
情報の２つ目はマシンの秒毎の実際の目覚めの要約です。秒毎の目覚め回数はシステムの電力消費に関してサービス又はデバイス、及びカーネルの ドライバーがどれくらい効率良く稼働しているかを知るための指数となります。秒毎でより多くの目覚めがあると、より多くの電力消費がある為、ここではその数値が低い方が良いことになります。
次に PowerTOP は取得できる場合はシステムの実際の電力消費の概算を提供します。 ラップトップがバッテリモードになっている時、PowerTOP がこの数値を報告することを期待して下さい。
Any available estimates of power usage are followed by a detailed list of the components thatsend wakeups to the CPU most frequently. At the top of the list are those components that youshould investigate more closely to optimize your system to reduce power usage. If they are kernelcomponents, (indicated by the name of the component being listed in <>) then the wakeups areoften associated with a specific driver that causes them. Tuning drivers most usually requireskernel changes which go beyond the scope of this document. However, userland processes thatsend wakeups are more easily managed. First, identify if this service or application should run atall on this system. If not, simply deactivate it. To turn off a service permanently, run:
chkconfig servicename off
コンポーネントが実際に実行する動作の詳細が必要な場合は、以下を実行します:
ps -awux | grep componentname strace -p processid
トレースがそれ自身を繰り返しているように見える場合は、多分、ビジーループに遭遇したことになります。これを修復するには、その コンポーネント内でコード変更が必要となり、これも本ドキュメントの範囲から外れます。
最後に、PowerTOP は省電力のためにシステムのチューニング方法も提案します。これらの提案は画面の下に表示され、そして PowerTOP からの提案を適用するために押すキーを指定します。PowerTOP は定期的にリフレッシュするため、更なる提案が表示されます。無2.1無PowerTOP 無無無無 では、提案、increase the VMdirty writeback time とその提案を適用するために押すキー (W) に注目して下さい。これらの変更は恒久的ではなく次の再起動までしか有効でありません。この変更の恒久的に維持する手助けのために PowerTOP はその最適化を実践するために実行する精確なコマンドを表示します。このコマンドを好みのテキストエディタで/etc/rc.local ファイルなどに追記して、現在ご利用のコンピュータが起動する度にこの変更が反映されるようにします。
ドラフト Diskdevstat と netdevstat
7
図2.1 PowerTOP の実践
Less Watts のウェブサイトは、PowerTOP が CPU をアクティブに保つと判定した アプリケーションの一覧を発行しています。http://www.lesswatts.org/projects/powertop/known.php を参照して下さい。
2.3. Diskdevstat と netdevstat
Diskdevstat と netdevstat はシステム上で稼働している全てのアプリケーションについてディスク活動とネットワーク活動の詳細情報を収集する SystemTap ツールです。これらのツールは 全てのアプリケーションに起因する秒毎の CPU の目覚め回数を示す PowerTOP を土台にしたものです (無PowerTOP無 を参照)。これらのツールが収集する統計により、少ない回数で大きな運用をせずに多くの小規模 I/O 運用を 繰り替えして電力を無駄にしているアプリケーションを識別できるようになります。転送スピードのみを測定する他の監視ツールはこのタイプの 識別には助けにはなりません。
以下のコマンドを使用して SystemTap と共にこれらのツールをインストールします:
yum install systemtap tuned-utils kernel-debuginfo
次のコマンドでツールを実行します:
diskdevstat
あるいは、コマンド:
第2章 電力管理の監査と分析 ドラフト
8
netdevstat
両方のコマンドは以下のように、３つまでのパラメータを取ります:
diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
update_interval
ディスプレイの更新までの秒表示の間隔。デフォルト: 5
total_duration
実行完了にかかる時間の秒数。デフォルト: 86400 (1 日)
display_histogram
実行終了後に全ての収集データ用のヒストグラムを表示するかどうかのフラグ。
出力は PowerTOP の出力に似ています。以下に KDE 4.2 を稼働している Fedora 10 システム上の長期のdiskdevstat 実行からのサンプル出力を示します:
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 15494 0 sda1 0 0.000 0.000 0.000 758 0.000 0.012 0.000 0logwatch 15520 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15549 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15585 0 sda1 0 0.000 0.000 0.000 108 0.001 0.002 0.000 perl 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 15429 0 sda1 0 0.000 0.000 0.000 62 0.009 0.009 0.000 crond 15379 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15473 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15415 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15433 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15425 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15375 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15477 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15469 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15419 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15481 0 sda1 0 0.000 0.000 0.000 61 0.000 0.001 0.000 crond 15355 0 sda1 0 0.000 0.000 0.000 37 0.000 0.014 0.001 laptop_mode 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd 15575 0 sda1 0 0.000 0.000 0.000 16 0.000 0.000 0.000 cat
ドラフト Diskdevstat と netdevstat
9
15581 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15582 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15579 0 sda1 0 0.000 0.000 0.000 12 0.000 0.001 0.000 perl 15580 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 12 0.000 0.170 0.014 sh 15584 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15548 0 sda1 0 0.000 0.000 0.000 12 0.001 0.014 0.001 perl 15577 0 sda1 0 0.000 0.000 0.000 12 0.001 0.003 0.000 perl 15519 0 sda1 0 0.000 0.000 0.000 12 0.001 0.005 0.000 perl 15578 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15583 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15547 0 sda1 0 0.000 0.000 0.000 11 0.000 0.002 0.000 perl 15576 0 sda1 0 0.000 0.000 0.000 11 0.001 0.001 0.000 perl 15518 0 sda1 0 0.000 0.000 0.000 11 0.000 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 10 0.053 0.053 0.005 lm_lid.sh
これらのカラムは:
PIDアプリケーションのプロセス ID
UIDアプリケーションの実行元となるユーザー ID
DEVI/O が発生するデバイス
WRITE_CNT書き込み操作の全回数
WRITE_MIN連続した２回の書き込みに要した最短の時間 (秒)
WRITE_MAX連続した２回の書き込みに要した最長の時間 (秒)
WRITE_AVG連続した２回の書き込みに要した平均時間 (秒)
READ_CNT読み込み操作の全回数
READ_MIN連続した２回の読み込みに要した最短時間 (秒)
READ_MAX連続した２回の読み込みに要した最長時間 (秒)
第2章 電力管理の監査と分析 ドラフト
10
READ_AVG連続した２回の読み込みに要した平均時間 (秒)
COMMANDプロセスの名前
この例では、３つの非常に目立つアプリケーションが突出しています:
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd
これらの３つのアプリケーションは、0 以上の WRITE_CNT を持っており、これは測定中に なんらかの書き込みを実行したことを意味します。その中で、plasma が大差をもって最大の悪事をしています。最多の書き込み操作を実行しているため、当然書き込みまでの間隔は最短の平均時間を示します。そのため、電力効率の悪いアプリケーションに懸念がある場合には、Plasma が調査の最大のターゲットとなります。
strace コマンドと ltrace コマンドを使用して、任意のプロセス ID の 全てのシステムコールを追跡することによりアプリケーションをもっと詳しく検査できます:
strace -p 2789
この例では、strace の出力は、書き込み用にユーザーの KDE アイコンキャッシュファイルを開いて、その直後にファイルを閉じる動作を 45秒毎に繰り返す同じパターンを含んでいました。この繰り返しが、ファイルメタ情報（特に、修正時間）の変更時に、ハードディスクへの必要な物理的書き込みになったのです。最終的な修復は、アイコンへの更新が発生していない時にこれらの不要なコールを阻止することでした。
2.4. Battery Life Tool KitBLTK（Battery Life Tool Kit）はこれはバッテリの寿命とパフォーマンスをシミュレーションにて解析するテストスイートです。BLTK は 特定のユーザーグループに対してシミュレーションをするタスクのセットを実行してその結果を報告することで、その目的を達成します。特にノートブックのパフォーマンスをテストするために開発されたのですが、BLTK は -a を付けて開始すると、デスクトップコンピュータのパフォーマンスも報告できます。
BLTK の使用により、実際のマシン使用と比較できる再現可能なワークロードを生成できるようになります。例えば、office のワークロードはテキストを書き込み、その中の間違いを修正します。そしてスプレッドシートも同じ事をします。BLTK を PowerTOP 、または他の監査用や、解析用ツールと一緒に実行すると、ユーザーが実行する最適化はマシンが アイドル時ではなく、活発に使用されている時に効果を持つかどうかをテストできるようになります。異なる設定を評価したい場合、全く同一のワークロードを複数回にわたり実行できるため、その結果を異なる設定を比較することができます。
以下のコマンドを使用して BLTK をインストールします:
yum install bltk
以下のコマンドで BLTK を実行します:
bltk workload options
例えば、idle のワークロードを 120 秒間実行するには:
bltk -I -T 120
ドラフト Tuned と ktune
11
デフォルトで使用できるワークロードは次の通りです:
-I, --idleシステムはアイドル状態です。他のワークロードとの比較でベースとして使用します。
-R, --readerドキュメントを読み込むシミュレーション（デフォルトで、Firefox を使用）
-P, --playerCD 又は DVD のマルチメディアファイルを見ているシミュレーションをします（デフォルトで、mplayer を使用）
-O, --officeOpenOffice.org スイートを使用してドキュメントの編集をシミュレーションします
その他、指定できるオプション:
-a, --ac-ignoreAC 電源が使用可能であるかどうかを無視（デスクトップ上で実行時に必要）
-T number_of_seconds, --time number_of_secondsテストを実行する期間（秒）を指定できます。なお、このオプションは idle ワークロードで使用します
-F filename, --file filename特定のワークロードで使用されるファイルを指定します。例えば、CD か DVD ドライブにアクセスする代わりに、再生する player ワークロードのためのファイル
-W application, --prog application特定のワークロードで使用されるアプリケーションを指定します。例えば、reader ワークロード用に、Firefox 以外のブラウザ。
BLTK は数多くの特殊化したオプションをサポートします。その詳細情報には bltk man ページを 参照してください。
BLTK は、生成する結果をデフォルトで /etc/bltk.conf 設定ファイルに指定してあるディレクトリに保存します。 ~/.bltk/workload.results.number/ 例えば、 ~/.bltk/reader.results.002/ ディレクトリはreader ワークロードの３つめのテスト結果を保持します （１つめのテストは番号無し）。結果はいくつかのテキストファイルに拡散します。これらの結果を読み取りが簡単な形式に凝縮するには、 以下を実行します:
bltk_report path_to_results_directory
これでその結果は、結果ディレクトリの Report と言う名前のテキストファイル内に表示されます。代わりに ターミナルエミュレータでその結果を表示するには、-o オプションを使用します:
bltk_report -o path_to_results_directory
2.5. Tuned と ktuneTuned はシステムコンポーネントの使用を監視して、その監視情報を基にして動的にシステムセッティングをチューンするデーモンです。動的なチューニングは、任意のシステム用のアップタイム期間を通じて各種システムコンポーネントが異なる方法で使用される決定要素となります。例えば、ハードドライブは起動時とログイン時に重労働となります。しかし、その後、ユーザーが主に OpenOffice や 電子メールクライアントのようなアプリケーションで作業をする時には稀にしか使用されません。同様に CPU とネットワークデバイスは異なる時期に異なる使い方を受けます。Tuned はこれらのコンポーネントの活動を監視して、それらの使用への変化に対応します。
第2章 電力管理の監査と分析 ドラフト
12
実際的な例として、オフィスにある標準的なワークステーションを考慮してみましょう。ほとんどの時間帯でイーサネットカードのインターフェイスは頻繁に通信は行っていないでしょう。数件の電子メールが時々届くか、またはウェブページをいくつか開くぐらいでしょう。このようなの負荷にはイーサーネットカードはデフォルト設定のようにいつも最高速度で動作する必要はありません。 Tuned はイーサーネットカード用の監視とチューニングのプラグインを持っており、これが低負荷を検出して自動的にそのイーサーネットカードのリンク速度を低下させます。それが一般的に使用電力の低減になります。例えば DVD イメージのダウンロードや、重い添付のある電子メールの開示などでインターフェイス上の活動が長期間に渡って劇的に増加すると、Tuned はこれを検出して活動レベルが高い間は最善のパフォーマンスを提供するためにイーサーネットカードのリンク速度を最速に設定します。この原理は CPU やハードディスクなどに対する他のプラグインにも使用されます。
スピードの変更はその効果を得るために数秒かかり、ユーザー使用に直接的及び視認可能なインパクトを与えるため、ネットワークデバイスはデフォルトではこのような方法で動作するようには設定されていません。同様の配慮が CPU とハードドライブのチューニングプラグインにも適用されます。ハードドライブが回転を落とした時、再度回転を上げるには数秒かかるためこの期間にはシステムの反応に遅延が見られます。この 遅延の副作用は CPU プラグインには最小限のものでユーザーには感知が困難なものですが、少なくとも測定可能な量です。
Tuned に並行して、今回のバージョンでは ktune を提供します。 ktune は特定の仕様用途でシステムのパフォーマンスを最適化するためのフレームワークとサービスとして導入されていました。その後、ktune は改良を重ねて、 現在ではシステムの全般的なチューニングを行うフレームワークの仕組みとして使用できるようになりました。これは、無Tuned-adm無 で説明されている事前定義のプロファイルの中で利用されます。
以下のコマンドを使用して tuned パッケージとその関連した systemtap スクリプトを インストールします:
yum install tuned
tuned パッケージをインストールすると、サンプルの設定ファイルも /etc/tuned.conf に設定されて、デフォルトプロファイルをアクティベートします。
以下を実行して tuned を開始します:
service tuned start
マシンが起動する度に tuned を開始するには、以下を実行します:
chkconfig tuned on
Tuned は、手動で実行している時に使用できる追加のオプションを持っています。利用可能なオプションは以下の通りです:
-d, --daemon前面の動作ではなく、デーモンとして tuned を開始します。
-c, --conffile設定ファイルは名前とパスを指定して使用します。例えば、--conffile=/etc/tuned2.conf。デフォルトでは /etc/tuned.conf となります。
-D, --debugロギングの最高レベルを使用します。
2.5.1. tuned.conf ファイルtuned.conf ファイルには、tuned 用の設定セッティングが含まれています。 デフォルトでは、ファイルは /etc/tuned.conf に置かれていますが、tuned に --conffile オプションを付けて開始することにより異なる名前と場所を指定することができます。
ドラフト tuned.conf ファイル
13
設定ファイルは常に、tuned の一般的なパラメータを定義する [main] セクションを 含んでいなければなりません。そうするとファイルは各プラグイン用にセクションを含みます。
[main] セクションは以下のオプションを含みます:
intervaltuned がシステムを監視してチューンすべき間隔を秒で表示します。デフォルト値は 10 です。
verbose出力が詳細であるべきかどうかを指定します。デフォルト値は False です。
loggingログすべきメッセージの最低の優先度を指定します。下降順になっている使用可能値は:critical、error、 warning、info、及び debug となります。デフォルト値は info です。
logging_disableログすべきメッセージの最高の優先度を指定します。この優先度、又はそれ以下の優先度を持つメッセージはログされません。下降順になっている 使用可能な値は: critical、error、 warning、info、及びdebug となります。値 notset はこのオプションを無効にします。
各プラグインはそれ自身のセクションを持っており、角括弧内に指定されたプラグイン名を持ちます。例えば:[CPUTuning]。 各プラグインはそれ自身のオプションを持つことができますが、以下は全てのプラグインに適用されます:
enabledプラグインが有効かどうかを指定します。デフォルト値は True です。
verbose出力が詳細であるべきかを指定します。このプラグイン用に指定されていないと、その値は [main] から継承されます。
loggingログすべきメッセージの最低の優先度を指定します。このプラグイン用にセットされていないと、その値は[main] から継承されます。
サンプルの設定ファイルは以下のようになります:
[main]interval=10pidfile=/var/run/tuned.pidlogging=infologging_disable=notset
# Disk monitoring section
[DiskMonitor]enabled=Truelogging=debug
# Disk tuning section
[DiskTuning]enabled=Truehdparm=Falsealpm=Falselogging=debug
# Net monitoring section
[NetMonitor]
第2章 電力管理の監査と分析 ドラフト
14
enabled=Truelogging=debug
# Net tuning section
[NetTuning]enabled=Truelogging=debug
# CPU monitoring section
[CPUMonitor]# Enabled or disable the plugin. Default is True. Any other value# disables it.enabled=True
# CPU tuning section
[CPUTuning]# Enabled or disable the plugin. Default is True. Any other value# disables it.enabled=True
2.5.2. Tuned-admシステムの詳細な監査と分析は多くの場合、非常に時間を費すためその結果として数ワットのみの節電は価値が無いかも知れません。以前は唯一の代替は単にデフォルトを使用することでした。そのため、Fedora 14にはそれらの2つの極端の間で１つの代替として 特定の使用ケースの為の個別の事前定義プロファイルが含まれています。それと共にコマンドラインで簡単にこれらプロファイルの切り替えができる tuned-adm ツールも提供しています。Fedora 14 には標準的な利用用途の場合の事前定義のプロファイルも数多く含まれており、その中から1つを選択して tuned-adm コマンドでアクティベートすれば適用されます。また、プロファイルをユーザー自身で作成、修正、および削除することも可能です。
全ての利用可能なプロファイルを一覧表示して現在稼働中のプロファイルを識別するには、以下を実行します:
tuned-adm list
現在機能中のプロファイルのみを表示するには、以下を実行します:
tuned-adm active
利用可能なプロファイルの１つへ切り替えるには、以下を実行します:
tuned-adm profile profile_name
例えば:
tuned-adm profile server-powersave
全てのチューニングを無効にするには:
tuned-adm off
Tuned をインストールする時、default プロファイルがアクティブになっています。 Fedora 14 は以下のような事前定義のプロファイルも収納しています:
ドラフト Tuned-adm
15
defaultデフォルトの節電プロファイルです。利用可能なプロファイルの中で電力節減に最も少ないインパクトを与え、 tuned の CPU とディスクのプラグインのみを有効にします。
desktop-powersaveデスクトップシステム対応の節電プロファイルです。SATA ホストアダプタ用の ALPM 節電 (無AggressiveLink Power Management無 参照) と更には、 tuned の CPU、イーサネット、及びディスクのプラグインを有効にします。
server-powersaveサーバーシステム対応の節電プロファイルです。SATA ホストアダプタ用の ALPM 節電を有効にして、HALを 介して CD-ROM ポーリングを無効にします (hal-disable-polling man ページ参照)。 そして、tunedの CPU とディスクのプラグインをアクティベートします。
laptop-ac-powersaveAC 電源で稼働中のラップトップ対応の中レベルインパクトの節電プロファイルです。SATA ホストアダプタ用の ALPM 節電、WiFi 節電、及び tuned の CPU とイーサネットとディスクのプラグインを有効にします。
laptop-battery-powersaveバッテリで稼働中のラップトップ対応のハイインパクト節電プロファイルです。これは、前述のプロファイルからの全ての節電メカニズムを アクティベートして更に、目覚め度の低いシステム用のマルチコア節電スケジューラを有効にすると共に、ondemand governor がアクティブである ことと AC97 オーディオ節電が有効であることを確実にします。このプロファイルを使用すると、バッテリ電源のラップトップだけでなく、どんな システムでも最大限の節電が出来ます。このプロファイルの犠牲は認識できるほどのパフォーマンスへのインパクトであり、特にディスクと ネットワーク I/O の遅延で顕著です。
throughput-performance典型的なスループットパフォーマンスチューニング用のサーバープロファイルです。これは tuned と ktuneの節電メカニズムを無効にして、ディスクとネットワーク I/O のスループットパフォーマンスを向上するsysctl セッティングを有効にし、そして deadline scheduler へ切り替えます。
latency-performance典型的な遅延パフォーマンスチューン用のサーバープロファイルです。これは、tuned と ktune の節電メカニズムを無効にして、ネットワーク I/O の遅延パフォーマンスを向上する sysctl セッティングを有効にします。
全てのプロファイルは /etc/tune-profiles の下の個別のサブディレクトリに格納されています。そのため、 /etc/tune-profiles/desktop-powersave には、そのプロファイルのための全ての必要なファイルとセッティングが含まれています。これらのディレクトリにはそれぞれ最大４つまでの以下のようなファイルが収納されています:
tuned.conftuned サービスがこのプロファイル用にアクティブになる設定
sysctl.ktunektune で使用される sysctl セッティングです。この形式は /etc/sysconfig/sysctl ファイルの形式と同じです (sysctl 及び sysctl.conf man ページを参照)。
ktune.sysconfigktune 自身の設定ファイルは、標準的に /etc/sysconfig/ktune です。
ktune.shktune サービスで使用される init スタイルのシェルスクリプトです。 これはシステムのチューンのために特定のコマンドをシステム起動時に実行できます。
第2章 電力管理の監査と分析 ドラフト
16
新しいプロファイルを開始する最も簡単な方法は既存のものをコピーすることです。laptop-battery-powersave プロファイル には、既にとても豊富なチューニングが含まれているため、便利な開始点となります。単に全ディレクトリを以下のように新しいプロファイル名に コピーします:
cp -a /etc/tune-profiles/laptop-battery-powersave/ /etc/tune-profiles/myprofile
新しいプロファイル内のファイルのいずれかを修正して個人的なニーズにマッチするようにします。例えば、CDの変更の検出が必要な場合は、 以下のようにして、ktune.sh スクリプト内の該当する行をコメントアウトすることにより、その最適化を無効にすることが出来ます:
# Disable HAL polling of CDROMS# for i in /dev/scd*; do hal-disable-polling --device $i; done > /dev/null 2>&1
2.6. UPowerFedora 11 では、 DeviceKit-power と HAL の一部である電源管理機能。以前のバージョンの Fedora では GNOME Power Manager (無GNOME Power Manager無 を参照してください。 Fedora 13 以降ではDeviceKit-power は UPower へ名前を変えました。 UPower はデーモンとして提供されます。API とコマンドラインツールも提供されます。それが物理装置であるかどうかに関係なく、システム上の電源はデバイスとして扱われます。例えば、ラップトップのバッテリーと AC 電源は両方ともデバイスとして扱われます。
upower というコマンドラインツールでアクセスすることができます。次のようなオプションが指定できます。
--enumerate, -eシステム上の電源デバイスのオブジェクトパスを表示します。例えば、次のように。
/org/freedesktop/UPower/devices/line_power_AC/org/freedesktop/UPower/devices/battery_BAT0
--dump, -dシステム上のすべての電源デバイスのパラメーターを表示します。
--wakeups, -wシステム上の CPU 起床(CPU wakeups)を表示します。
--monitor, -mシステム上の電源デバイスをモニターします。例えば、AC 電源に繋がっているか切断されているのか、バッテリー切れしているのか。 Ctrl+C キーを押すとシステムのモニタリングを中止します。
--monitor-detailシステム上の電源デバイスをモニターします。例えば、AC 電源に繋がっているか切断されているのか、バッテリー切れしているのか。 --monitor-detail は --monitor オプションよりも詳しい情報が取得できます。Ctrl+C キーを押すとシステムのモニタリングを中止します。
--show-info object_path, -i object_path特定のオブジェクトパスから取得できるすべての情報を表示します。例えば、/org/freedesktop/UPower/devices/battery_BAT0 というオブジェクトパスからシステム上のバッテリーに関する情報を入手することができます。例として次のようにコマンドを実行します。
devkit-power -i /org/freedesktop/UPower/devices/battery_BAT0
ドラフト GNOME Power Manager
17
2.7. GNOME Power ManagerGNOME Power Manager は、GNOME デスクトップの一部としてインストールされているデーモンです。Fedora の以前のバージョンで提供されていた GNOME Power Manager の電力管理機能の 大部分はFedora 13 の DeviceKit-power の構成要素となりました (無UPower無 参照) 。しかし、GNOME PowerManager はその機能のフロントエンドとして 残ります。システムトレイ上のアプレットを介して GNOME PowerManager は、バッテリから AC 電源への切り替えなどのシステムの電源状態の変化を通知します。また、バッテリの状態を報告するとともに、バッテリー電力が低下した時点に警告を出します。
また、GNOME Power Manager により基本的な電力管理のセッティングが設定できるようになります。これらの セッティングにアクセスするには、システムトレイ内の GNOME Power Manager アイコンをクリックして、 そこで Preferences（個人設定） をクリックします。
Power Management Preferences（電力管理の個人設定） 画面には３つのタブがあります:
• AC 電源使用時
• バッテリー使用時
• 全般
AC 電源使用時 タブと バッテリー使用時 タブを使用して、それぞれ活動停止時にディスプレイがオフになるまでの経過時間、活動停止時にスリープになるまでの経過時間、及び活動停止時にハードディスクの回転を落とすかどうかを指定します。 バッテリー使用時 タブでは、ディスプレイの輝度の設定、及び危険なほどのバッテリー低下時での動作の選択が可能になります。 例えば、GNOME Power Manager は、バッテリーが危険な低レベルに到達するとシステムにハイバネートさせます。 全般 タブを使用して、システム上の（物理的）電源ボタンとサスペンドボタンの動作をセットできると共に、 GNOME Power Manager アイコンがシステムトレイに出現すべき状態を指定できます。
2.8. 監査用の他の手段Fedora 14 はシステムの監査と分析を実行するためのツールを他にもいくつか提供します。それらのほとんどは既に発見している事項に対して立証したり、特定の部分に於いてより詳しい情報が必要な場合に補助ソースとして使用できるものです。 これらのツールの多くはパフォーマンスチューンにも使用されます。それは以下のようになります:
vmstatvmstat はプロセス、メモリー、ページング、ブロック I/O、トラップ、及び CPU の活動について 詳細情報を提供します。システム全体で実行している動作や多忙な部分を詳しく見るために使用します。
iostatiostat は vmstat と似ていますが、ブロックデバイスの I/O 専用です。 また、詳細な出力と統計を提供します。
blktraceblktrace は非常に詳細に渡るブロック I/O のトレースプログラムです。情報をアプリケーションに関連した単独のブロックに分割します。diskdevstat と一緒に使用すると大変役に立つものです。
18
ドラフト ドラフト
19
コアインフラストラクチャとメカニクス
3.1. CPU のアイドル状態x86 アーキテクチャを持つ CPU は各種状態をサポートし、CPU の一部の状態は不活性化してあるか、又は低いパフォーマンス設定になっています。 C-無無 として知られるこれらの状態は、使用されていない CPU を部分的に不活性化してシステムが電力を節減できるようにします。C-状態は、C0 から増加する番号が付いており、より高い番号が低下した CPU 機能を意味して高い節電能力を示します。 任意の番号の C-状態は広い意味で多くのプロセッサ全種に同様と言えますが、状態の特定機能セットの詳細はプロセッサファミリー間で異なります。C-状態 0–3 は 以下のように定義されます:
C0運用中、又は実行中の状態。この状態では、CPU は作業中であり全くアイドルではありません。
C1, 一時停止プロセッサがインストラクションを実行していない状態ですが、典型的な低い電力状態でもありません。CPU は実質的に遅延のない プロセッシングを継続できます。C-状態を提供する全てのプロセッサはこの状態をサポートする必要があります。Pentium 4 プロセッサは 実際により低い電力消費の状態になるC1E と呼ばれる拡張型の C1 状態をサポートします。
C2, クロック停止このプロセッサ用にクロックが凍結する状態ですが、そのレジスタとキャッシュ用に完全な状態を維持します。そしてクロックを再開始した直後に プロセッシングをスタートできます。これはオプションの状態です。
C3, スリーププロセッサが本当にスリープに入る状態です。キャッシュ更新を維持するはありません。このため、この状態から起き上がるには、 C2 から立ち上がるよりも時間がかかります。これもまたオプションの状態です。
"Nehalem" マイクロアーキテクチャを持つ最近の Intel CPU は新しい C-状態 C6 をを特徴とします。これはCPU の電圧供給をゼロに低下することができます。しかし、標準的には電力消費は 80% と 90% の間で低減されます。Fedora 14 内のカーネルはこの新しい C-state 用の最適化を含んでいます。
3.2. CPUfreq Governors の使用
使用システムで電力消費と発熱を低減する効果的な方法の１つは、CPUfreq を使用することです。CPU 速度スケーリングとも呼ばれる CPUfreq は プロセッサのクロック速度を即座に調節できるようにします。これにより、システムは低下したクロック速度で稼働して電力を節約します。 周波数の変換についての規則として、クロック速度を上げるか下げるかどうか、そして周波数を変換する時期は CPUfreq governor に よって決定されます。
governor はシステム CPU の電力特性を定義付けして、それが結果的に CPU のパフォーマンスに影響します。各 governor は作業負荷に関してそれ自身の独特の動作、目的、及び適合性を持っています。このセクションでは、CPUfreq governor の選択と設定の方法、各 governor の 特性、及び 各 governor に適している作業負荷の種類について説明しています。
電力管理に関する主な懸念は以下のようになります:
• サーバーの熱削減
• ラップトップ用のバッテリー寿命の延長
第3章 コアインフラストラクチャとメカニクス ドラフト
20
原則としては、特定コンポーネント（又はシステム全体として）の消費電力を低減することは、発生熱の低下になり、そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低下を、特にミッションクリティカルな システムに於いて研究してテストするべきです。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシステムに効果を与えるかを説明しています。
3.2.1. CPUfreq Governor のタイプ
このセクションでは、Fedora 14 で利用できる CPUfreq governors の異なるタイプを一覧表示して 説明しています。
cpufreq_performance
performance governor は CPU が可能な限り最高のクロック周波数を使用するように強制します。この周波数は静的にセットしてあるため、 変化しません。そのためこの特定の governor は無無無無無無無無無無無無無無 これは作業負荷が大きい時に適していますが、その期間中でも特に CPU が稀にしかアイドルに（又は決して）ならない時のみとなります。
cpufreq_powersave
それに比較して、powersave governor は CPU が可能な限り最低のクロック周波数を使用するように強制します。この周波数は静的にセットしてあるため、 変化しません。そのため、この特定の governor は最大の節電を提供しますが、無無無 CPU 無無無無無無無 の犠牲を持ちます。
「powersave」という言葉は時には勘違いを招きます。全面的負荷を受けている遅い CPU は（原則として）負荷のない高速の CPU よりも多くの電力を消費します。そのため、低活動が予期できる時には powersavegovernor を使用するように CPU を設定することが推奨されますが、この間に予期しない高負荷が発生するとシステムが実際には通常より多くの電力を消費する原因になります。
powersave governor は簡単な表現をすると、CPU にとっては節電よりも速度制限の意味を持ちます。これは、発熱が問題となるようなシステムや設置環境で最も役に立つ選択肢です。
cpufreq_ondemand
ondemand governor は動的に変化する governor です。これは負荷が高い時には最高のクロック周波数を達成して、システムがアイドルの時には 最低のクロック周波数を達成するように CPU を変化させます。これによりシステムはシステム負荷に応じて電力消費を調節可能にしますが、その 犠牲として無無無無無無無無無無を招きます。そのため遅延は、システムがアイドルと高負荷の間で頻繁に転換を 繰り返すとオンデマンドで提供されるパフォーマンスと節電効果を相殺してしまいます。
ほとんどのシステム上では、ondemand governor は 発生熱、消費電力、パフォーマンス、及び管理法の間で最良の妥協を提供します。 システムが１日の内で特定の時間帯にのみ多忙になる状態では、オンデマンドはそれ以上の介入を必要とせずに負荷に応じて最高と最低の 周波数の間で自動的に転換します。
cpufreq_userspace
userspace governor はユーザースペースプログラム（または root で実行している他のプロセス）が周波数をセットできるように します。この governor は通常、cpuspeed デーモンと共同で使用されます。全てのgovernor の内、 userspace governor は最もカスタマイズ可能なタイプであり、その設定によってはシステムにパフォーマンスと電力消費の最良の バランスを提供できます。
ドラフト CPUfreq のセットアップ
21
cpufreq_conservative
ondemand governor のように、conservative governor も使用状態に応じてクロック周波数を調節します（ondemand governor と同様）。 しかし、ondemand governor がより攻撃的な手法で最高と最低との周波数転換を達成するのに対して、conservative governor はもっと ゆっくりと周波数間の転換をします。
これが意味することは、conservative governor は単に最高と最低の周波数を選択することではなく、負荷に対して適切と判断するクロック周波数に調整すると言うことです。これは電力消費に関して価値のある節約を提供する可能性を持ちますが、ondemand governor よりも 無無無無無 がその代償となります。
注記
cron ジョブを使用して governor を有効にすることができます。これにより、１日の特定の時間帯に特定のgovernor を自動的にセットすることが可能になります。そのため、アイドル時（例えば、終業後）には低周波数の governor を指定して、 高負荷となる時間帯には高周波数に戻ることが出来ます。
特定の governor を有効にする方法についての案内には、無CPUfreq 無無無無無無無無 内の 無無3.2無CPUfreqGovernor 無無無無無無無 を参照して下さい。
3.2.2. CPUfreq のセットアップ
CPUfreq governor を選択して設定する前に、最初に適切な CPUfreq ドライバーを追加する必要があります。
手順3.1 CPUfreq ドライバーの追加方法
1. 以下のコマンドを使用して自分のシステムにどの CPUfreq ドライバーが使用可能かを表示します:
ls /lib/modules/[kernel version]/kernel/arch/[architecture]/kernel/cpu/cpufreq/
2. modprobe を使用して適切な CPUfreq ドライバーを追加します。
modprobe [CPUfreq driver]
上記のコマンドを使用する時、ファイル名の接尾辞 .ko を忘れずに削除して下さい。
重要
適切な CPUfreq ドライバーを選択している時、p4-clockmod より優先して 常に acpi-cpufreq を選択して下さい。p4-clockmod ドライバーの使用は CPU のクロック周波数を低減しますが、電圧は低下しません。 その反面、acpi-cpufreq は CPU のクロック周波数と共に電圧も低減しますので、パフォーマンスの低減レベル毎に少ない電力消費と低発熱を可能にします。
第3章 コアインフラストラクチャとメカニクス ドラフト
22
3. CPUfreq ドライバーがセットアップされると、システムがどの governor を使用しているか以下を使用して表示できます:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
また、特定の CPU の使用の為に利用可能な governors を以下を使用して表示できます:
cat /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_available_governors
一部の CPUfreq governors は利用可能ではないかも知れません。そのような場合は、modprobe を使用して使用したい特定の CPUfreq governor を有効にするのに必要なカーネルモジュールを追加します。これらのカーネルモジュールは /lib/modules/[kernel version]/kernel/drivers/cpufreq/ 内で取得できます。
手順3.2 CPUfreq Governor を有効にする
1. 特定の governor が自分の CPU 用の利用可能一覧にない場合は、 modprobe を実行して使用したいgovernor を有効にします。例えば、自分の CPU 用に ondemand governor が利用可能でない場合は、以下のコマンドを使用します:
modprobe cpufreq_ondemand
2. governor が自分の CPU 用に利用可能と表示されると、以下を使用してそれを有効にします:
echo [governor] > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
3.2.3. CPUfreq のポリシーと速度のチューニング
適切な CPUfreq governor を選択したら、 /sys/devices/system/cpu/[cpu ID]/cpufreq/ で見つけることができるチューン可能項目を使用して、各 CPU の動作クロックを更にチューニングできます。これらのチューン可能項目は以下のようになります。
• cpuinfo_min_freq — は CPU の利用可能な最低限の周波数を表示します (KHz)。
•cpuinfo_max_freq — は CPU の利用可能な最大限の周波数を表示します (KHz)。
•scaling_driver — この CPU で周波数をセットするために使用される CPUfreq ドライバーを表示します。
•scaling_available_governors — このカーネル内で利用可能な CPUfreq governor を表示します。このファイル内に一覧表示されていない CPUfreq governor を使用したい場合は、その方法の案内を見るために 無CPUfreq 無無無無無無無無 内の 無無3.2無CPUfreq Governor 無無無無無無無 を参照して下さい。
•scaling_governor — Shows what CPUfreq governor is currently in use. To use a differentgovernor, simply use echo [governor] > /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_governor (refer to 無無3.2無CPUfreq Governor 無無無無無無無 in 無CPUfreq 無無無無無無無無 for moreinformation).
ドラフト サスペンドとレジューム
23
•cpuinfo_cur_freq — CPU の現在の速度を示します (KHz)。
•scaling_available_frequencies — は CPU 用に使用可能な周波数を一覧表示します。KHz 単位。
•scaling_min_freq と scaling_max_freq — CPU の 無無無無無 無無を KHz でセットします。
重要
ポリシーの限度をセットしている時は、scaling_min_freq の前に scaling_max_freq を セットする必要があります。
•affected_cpus — 周波数調整ソフトウェアを必要とする CPU を一覧表示します。
•scaling_setspeed — CPU のクロック速度を変更するのに使用されます （KHz）。CPU のポリシー限度内で 速度をセットできるだけです（scaling_min_freq と scaling_max_freq と同様）
各チューン可能項目の現在の値を表示するには、cat [tunable] を使用します。 例えば、cpu0 の現在の速度を (KHz で) 表示するには、次を使用します:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq.
To change the value of each tunable, use echo [value] > /sys/devices/system/cpu/[cpu ID]/cpufreq/[tunable]. For example, to set the minimum clock speed of cpu0 to 360 KHz, use:
echo 360000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
3.3. サスペンドとレジュームシステムがサスペンド状態になると、カーネルはドライバーを呼び出してその状態を保存し、それからドライバーをアンロードします。システムがレジュームする時には、ドライバーをリロードするためドライバーがデバイスを再プログラム化します。このタスクを達成するドライバーの能力はシステムが正常に復帰できるかどうかを左右します。
この点では、ビデオドライバーが特に問題です。その理由は、ACPI (Advanced Configuration and PowerInterface) 仕様がシステムファームウェアのビデオハードウェアに対する再プログラム化能力を要求していないからです。そのため、ビデオドライバーがハードウェアを完全な未初期化状態からプログラム化できない限りは、それがシステムの復帰を阻止してしまいます。
Fedora 14 には、新しいグラフィックチップセット用のより強力なサポートが含まれています。これにより、 サスペンドとレジュームは以前より多くのプラットフォームで機能します。特に、NVIDIA チップセット用のサポートは格別に向上しており、 NVIDIA GeForce 8800 シリーズには特に良くなりました。
3.4. Tickless カーネル以前は、Linux カーネルはプラットフォームに応じて事前設定した周波数 — 100 Hz、250 Hz、 あるいは1000 Hz でシステム上の各 CPU に定期的に割り込んでいました。カーネルは CPU が実行しているプロセス
第3章 コアインフラストラクチャとメカニクス ドラフト
24
についてクエリを出し、その結果をプロセスの計算とロードバランシングに使用していました。CPU の電力状態に関係なく、カーネルは 無無無無無無無無無timer tick無として知られるこの割り込みを実行していました。 そのため、アイドル状態の CPU でも最大で毎秒 1000 回もこれらの要求に応答していたのです。アイドル状態 CPU 用に省電力機能を実装してあるシステムでは、これらの省電力機能の利点を得るのに十分な CPU のアイドル状態の維持をタイマーティックが阻止していました。
Fedora 14 内のカーネルは 無無無無無無無tickless無で稼働します。これは旧式の オンデマンド型の定期タイマー割り込みに入れ替わるものです。そのため、アイドル状態の CPU は新しいタスクがプロセス用にキューされるまでは、 アイドル状態を持続できるようになります。そして低い電力消費状態にある CPU はその状態をより長く維持できます。
3.5. Active-State Power ManagementActive-State Power Management (ASPM) は 接続相手のデバイスが使用中でない時には PCIe リンク用に低い 電力状態に設定することで Peripheral Component Interconnect Express (PCI Express 又は PCIe)サブシステム内で 電力を節約します。ASPM はリンクの両側で電力状態を制御して、リンク末端のデバイスが最大電力状態にある場合でもリンク内で電力を節約します。
ASPM が有効になっていると、異なる電力状態間でのリンクを移転するのに必要な時間の為にデバイスレイテンシ(遅延）は増加します。 ASPM は電力状態を決定するために以下のような３つのポリシーを持ちます:
デフォルトシステム上のファームウェア（例えば、BIOS）で指定されたデフォルトに従って、PCIe リンクの電力状態をセットします。これが ASPM の デフォルト状態です。
電力節約（powersave）パフォーマンスへの犠牲に関係無く、できる限り電力を節約するように ASPM をセットします。
パフォーマンス（performance）ASPM を無効にして PCIe リンクが最大パフォーマンスで稼働できるようにします。
ASPM ポリシーは /sys/module/pcie_aspm/parameters/policy にセットしてありますが、 ブート時にpcie_aspm カーネルパラメータを使用して指定することもできます。このパラメータで、 pcie_aspm=off とすると、ASPM を無効にして、pcie_aspm=force とすると、ASPM をサポートしない デバイス上でも ASPM を有効にします。
警告 — pcie_aspm=force はシステムが反応しない原因になる可能性があります。
pcie_aspm=force がセットされると、ASPM をサポートしていないハードウェアではシステムが反応しない原因になる 可能性があります。 pcie_aspm=force をセットする前にシステム上の全ての PCIe ハードウェアが ASPM を サポートすることを確認して下さい。
3.6. Aggressive Link Power Management
Aggressive Link Power Management (ALPM) は、アイドル時（I/O が存在しない時）に SATA リンクを低電力設定に セットすることによりディスクの節電を手伝う節電技術です。ALPM は、I/O 要求がそのリンクにキューされると、自動的に SATA リンクを active 電力状態にセットし直します。
ALPM で導入された節電はディスク遅延の犠牲をもって達成されます。そのため、長期に渡る I/O 休止時間を予期できる場合にのみ ALPM を 使用すべきです。
ドラフト Relatime ディスクアクセスの最適化
25
ALPM は、Advanced Host Controller Interface (AHCI) を使用する SATA コントローラ上でのみ利用できます。 AHCI についての詳細情報には、http://www.intel.com/technology/serialata/ahci.htm を参照して下さい。
利用可能な時には、ALPM はデフォルトで有効になっています。ALPM は以下の３つのモードを持ちます:
min_power
このモードは、ディスク上に I/O が存在しない時には最低電力状態 (SLUMBER) にリンクします。このモードは長期に渡るアイドル時間が 予期される時には役に立ちます。
medium_power
このモードは、ディスク上に I/O が存在しない時に２番めに低い電力状態にリンクします。このモードはできるだけパフォーマンスに影響のないように リンクの電力状態の転換（例えば、多量の I/O とアイドル I/O の断続的な時期）を可能にするように設定されています。
medium_power モードは負荷に応じてリンクが PARTIAL（部分的）状態と ACTIVE（フルパワー）状態の間で状態遷移できるようにします。PARTIAL 状態から SLUMBER 状態へ直接遷移すること、および、その逆に遷移できないに注意して下さい。このような場合、どちらの電力状態も最初に ACTIVE 状態を経由して遷移しないと遷移ができません。
max_performance
ALPM は無効になっています。リンクはディスク I/O が発生していない時に低電力状態にはなりません。
SATA ホストアダプタが実際に ALPM に対応しているかどうかをチェックするには、ファイル、/sys/class/scsi_host/host*/link_power_management_policy が存在することを確認します。 セッティングを変更するには、このセクションに記述してある値をこのファイルに書き込むか、あるいは、ファイルを 表示して現在のセッティングをチェックします。
重要 — 一部の設定はホットプラグを無効にします。
ALPM の設定で min_power、または medium_power に設定すると、自動的にSATAの「ホットプラグ」機能を無効にします。
3.7. Relatime ディスクアクセスの最適化POSIX 基準はオペレーティングシステムが、各ファイルの最終アクセス時を記録するファイルシステムメタデータを維持するように要求します。このタイムスタンプは atime と呼ばれており、その維持にはストレージへの常時書き込み操作を必要とします。 これらの書き込みはストレージデバイスとそのリンクを頻繁に利用してしまいます。ただし、atime データを使用するアプリケーションが少ないため、このストレージデバイスの活動は電力の無駄使いとなります。重要なことはストレージデバイスへの書き込みは、ストレージデバイスからファイルが読み込まれた場合だけではなく、キャッシュから読み込まれた場合でも発生することです。しばらくの間、Linux カーネルは mount 用に noatime オプションをサポートしており、このオプションでマウントされたファイルシステムには atime データを書き込むことはありませんでした。しかし、単にこの機能をオフにすると、一部のアプリケーションが atime データに依存しているため、それが利用できない場合には問題になっていました。
第3章 コアインフラストラクチャとメカニクス ドラフト
26
Fedora 14 内のカーネルはもう１つの代替 — relatime をサポートします。 Relatime は atime データを維持しますが、ファイルがアクセスされる度ではありません。 このオプションが有効になっていると、atime データは、その最後の更新以降にファイルが変更された場合 (mtime) か、または一定の時間 (デフォルトでは １日) 以上前にファイルがアクセスされた場合にのみ、 ディスクに書き込まれます。
デフォルトでは、すべてのファイルシステムは今回、relatime を有効にしてマウントされています。この機能をシステム全体で 抑制するには、ブートパラメーター default_relatime=0 を追加してください。システムのデフォルトとしては relatime が有効になっていて、個別のファイルシステムにだけ抑制するにはオプションnorelatime でそのファイルシステムをマウントします。最後にシステムがファイルの atime データを更新するまでのデフォルト時間の長さを変化させるには、relatime_interval= ブートパラメーターを使用し、その期間を秒で指定します。デフォルト値は 86400 です。
3.8. パワーキャッピング（Power Capping）Fedora 14 は、HP Dynamic Power Capping (DPC) や Intel Node Manager (NM) テクノロジーなど、最近のハードウェアに内蔵されているパワーキャッピング（電力制限）機能をサポートします。このパワーキャッピングにより、管理者はサーバーによる電力消費を制限できるだけでなく、データセンターを設備増設などを効率的に計画できるようになります。その理由は既存の電力供給における過剰負荷のリスクが随分と減少するためです。管理者は同じサーバー設置スペースの内により多くのサーバー群を配置でき、サーバーの電力消費が制限された場合に、高負荷時の電力要求が利用可能電力上限を超過しないことを確信できます。
HP Dynamic Power CappingDynamic Power Capping は HP ProLiant と BladeSystem のサーバーで利用できる機能であり、システム管理者がサーバーの、あるいはサーバーグループに対して消費電力のキャップ（上限）を設定できるようにするものです。キャップとは、現在の作業負荷に関係無く、サーバーが超過しない明確な消費電力の限度のことです。キャップはサーバーがその消費電力の限度に到達するまでは何も機能しません。上限に到達した時点で、管理プロセッサーは CPU P-states とクロックスロットリング（clock throttling）を調節して電力消費を制限します。
Dynamic Power Capping はオペレーティングシステムから独立して CPU の動作を個別に修正しますが、HP の integrated Lights-Out 2 (iLO2) ファームウェアは、オペレーティングシステムが管理プロセッサーにアクセスできるようにするため、ユーザースペース内のアプリケーションは管理プロセッサーに対して動作状態の問い合わせをすることができます。Fedora 14 で使用されているカーネルは HP iLO と iLO2 の ファームウェア用のドライバーを含んでおり、プログラムから /dev/hpilo/dXccbN を経由し、管理プロセッサーに問い合わせができます。このカーネルには、パワーキャッピング機能をサポートするための hwmon sysfs インターフェイスの拡張と、sysfs インターフェイスを使用する ACPI 4.0 パワーメータ−用の hwmon ドライバーも含んでいます。これらの機能が一緒になってオペレーティングシステムとユーザースペースツールが、パワーキャップ用に設定された値とシステムの現在の電力消費を読み取りを可能にしています。
For further details, refer to the official site: HP Dynamic Power Capping1.
Intel Node ManagerIntel Node Manager は、プロセッサーの状態の P-states と T-states を使用してシステムにパワーキャップを課して、CPU パフォーマンスを制限することで電力消費を抑えます。管理者が電力管理ポリシーを設定することにより、例えば夜間や週末などのシステム負荷が低い時にシステムを少ない消費電力で動作できるように設定ができます。
Intel Node Manager は、標準の ACPI 無Advanced Configuration and Power Interface無 を通じて、OSPMOperating System-directed configuration and Power Management を使用することで CPU の パフォーマンスを調節します。Intel Node Manager が OSPM ドライバーに対して T-states への変更を要求を行う
1 http://h18013.www1.hp.com/products/servers/management/dynamic-power-capping/index.html
ドラフト Enhanced Graphics Power Management
27
と、OSPM ドライバーはその要求に相当する変更を P-states に行います。同様に Intel Node Manager がOSPM ドライバーに対して P-states への変更を通知すると、 ドライバーはそれに応じて T-states を変更します。これらの変更は自動的に発生し、オペレーティングシステムの介入を必要としません。管理者は Intel DCMIntel Data Center Manager ソフトウェアを使用して Intel Node Manager の設定と監視を行います。
For further details, refer to Node Manager — A Dynamic Approach To Managing Power In The DataCenter2
3.9. Enhanced Graphics Power ManagementFedora 14 はいくつかの不要な消費を取り除くことによってグラフィックスとディスプレイデバイスの電力を節減します。
LVDS 再クロッキングLow-voltage differential signalling (LVDS) とは、電子信号を銅線上で輸送するシステムです。このシステムの 重要な応用の１つにピクセル情報をノートブックコンピュータの 無無 (LCD) 画面に送信することがあります。全てのディスプレイは 無無無無無無無無無 を持っています。これはディスプレイがグラフィックコントローラからフレッシュなデータを受け取り、その度にイメージを画面に再描写するレートです。標準的に、画面はデータを毎秒 60 回受け取ります（60 Hz の周波数）。画面とグラフィックコントローラが LVDS でリンクされている時は、LVDS システムは毎回のフレッシュサイクルで電力を使用します。アイドル時は、 多くの LCD 画面のリフレッシュレートは、視認できる変化を与えないで 30 Hz まで低下できます（リフレッシュレートの低下が典型的な チラツキを起こすブラウン管（CRT）モニターと異なります）。Fedora 14 のカーネル内に組み込まれている Intel グラフィックスアダプタ用のドライバーは自動的にこの、無無無無無無無無無無無無無無無無を実行します。そして画面がアイドルの時に約 0.5 W の節電をします。
メモリーの自己リフレッシュを有効にするSynchronous dynamic random access memory (SDRAM) — グラフィックアダプタ内のビデオメモリー用に使用 されているこのメモリーは毎秒千回ものリチャージを受けて、個々のメモリーセルがその中のデータを維持できるようにします。メモリーの 内外へと移動するデータを管理するその主要機能の他に、メモリーコントローラは通常これらのリフレッシュサイクルを開始する役目を持って います。しかし、SDRAM はまた、低電圧 無無無無無無無無 モードも持っています。このモードでは、メモリーは 内部タイマーを使用してそれ自身のリフレッシュサイクルを生成します。これにより、現在メモリーに保存されているデータを危険に晒すこと無く システムがメモリーコントローラをシャットダウンできるようにします。Fedora 14 で使用されているカーネルは アイドル時に Intel グラフィックスアダプタ内でメモリーの自己リフレッシュを引き起こします。それが約 0.8 W だけ節電します。
GPU クロックの低減標準的なグラフィカルプロセッシングユニット (GPU) には、その内部回路の各種パーツを制御する内部クロックが含まれています。Fedora 14 で使用されているカーネルは、Intel 及び ATI の GPU 内の内部クロックの一部の周波数を低減することが できます。GPU コンポーネントが任意の時間内に実行するサイクル数を低減すると、それらが実行する必要のなかったサイクルで消費されていたはずの 電力を節減します。GPU のアイドル時にカーネルは自動的にそれらのクロックの速度を低減して、GPU の活動が増加するとそれを加速します。GPU のクロックサイクルを低減することで最大約 5 W の節電ができます。
GPU 電力停止Fedora 14 内の Intel と ATI グラフィックスドライバーは、アダプタにモニターが接続されていない状態を検出できますので、GPU を完全にシャットダウンすることができます。この機能は、常時モニターを接続していないサーバーに特に重要な ポイントとなります。
2 http://communities.intel.com/docs/DOC-4766
第3章 コアインフラストラクチャとメカニクス ドラフト
28
3.10. RFKill
多くのコンピュータシステムが、Wi-Fi、Bluetooth、及び 3G のデバイスを含む電波発信器を格納しています。これらのデバイスは電力を消費し、 使用されない時には無駄になります。
Linux カーネル内のサブシステムである RFKill は、コンピュータシステム内の電波発信器が、クエリ、アクティベート、 そしてディアクティベートされる土台のインターフェイスを提供します。発信器がディアクティベートされていると、それらはソフトウェアが 再アクティベートできる状態（無無無無無無無）に置かれるか、又はソフトウェアが再アクティベートできない状態 （無無無無無無無）に置かれます。
RFKill コアはサブシステム用にアプリケーションプログラミングインターフェイス (API) を提供します。RFkill をサポートするように設計されて いるカーネルドライバーは、この API を使用してカーネルで登録し、デバイスを有効にしたり無効にしたりする方法を含んでいます。更には、 RFKill コアはユーザーアプリケーションが解釈できる通知と、ユーザーアプリケーションが発信器の状態をクエリする方法を提供します。
RFKill インターフェイスは /dev/rfkill にありますが、ここにはシステム上にある全ての電波発信器の現在の状態が 含まれています。各デバイスの現在の RFKill 状態は、sysfs に登録されています。更には、RFKill はRFKill 対応のデバイス内の状態の各変化について uevents を発行します。
Rfkill は、システム上の RFKill 対応のデバイスをクエリして変更できるコマンドラインツールです。 このツールを取得するには、rfkill パッケージをインストールして下さい。
コマンド rfkill list を使用すると、デバイスの一覧が取得できます。それぞれのデバイスはそれに関連した 0から始まる無無無無無無無無を持っています。このインデックス番号を使用して rfkill に対してデバイスのブロックとアンブロックを指示します。例えば:
rfkill block 0
システム上の最初の RFKill 対応デバイスをブロックします。
また、rfkill を使用してデバイスの特定のカテゴリ、又は全ての をRFKill 対応のデバイスも ブロックできます。例えば:
rfkill block wifi
システム上の全ての Wi-Fi デバイスをブロックします。全ての RFKill 対応デバイスをブロックするには 以下を実行します:
rfkill block all
デバイスをアンブロックするには、rfkill block の代わりに rfkill unblock を 実行します。rfkill がブロックできるデバイスカテゴリの完全一覧を取得するには、rfkill help を実行して下さい。
3.11. ユーザースペースの最適化システムハードウェアで実行される処理を低減させることが節電における基本と言えます。そのため、3無無無無無無無無無無無無無無無無無無無 に説明してある変更はシステムが色々な低電力消費の状態で運用されるようにしますが、システムハードウェアから不要な処理を要求するユーザースペース内のアプリケーションは、ハードウェアがこれらの節電状態に入ることを妨げます。Fedora 14 は開発段階で、ハードウェア上の不要な処理を削減すべく以下の分野で監査を行いました。
ウェイクアップ（wakeups）の削減Fedora 14 は 無無無無無無無無無無無tickless kernel無（無Tickless 無無無無無 を参照）を使用して、CPU がより深いアイドル状態に長い時間維持できるようにします。しかし、無無無無無無無無無timer tick無 は、 CPU を頻繁にアイドル状態か
ドラフト ユーザースペースの最適化
29
ら起こしてしまう処理の唯一の原因ではなく、アプリケーションからの関数呼び出しも CPU がアイドル状態に入るか、または、アイドル状態を維持することを妨げる可能性があります。なお、不要な関数呼び出しは 50 個以上のアプリケーションで削減されました。
ストレージとネットワークの I/O の削減ストレージデバイスとネットワークインターフェイスへの入出力（I/O）はデバイスの電力消費を強要します。アイドル時に節電状態になる機能（例えば、ALPM や ASPM）を持つストレージデバイスとネットワークインタフェースで、この無駄なトラフィックはデバイスがアイドル状態に入ったり、アイドル 状態を維持することを阻止する可能性があります。ハードディスクを使用していない時にプラッタ（円盤）の回転減少することを阻止してしまう可能性があります。ストレージデバイスに対する不要な処理は、数種のアプリケーションで最低限に抑制されました。ハードディスクの回転数減少を邪魔する処理は特に抑制されています。
Initscript の監査要求に関係無く、自動的に開始するサービスは、いくつかのリソースを無駄にする可能性が多分にあります。それに対して可能な限りサービスが デフォルトで 「オフ」や「オンデマンド」になるようにすべきです。例えば、Bluetooth 機能を提供する BlueZ サービスは以前はシステム上に Bluetooth 機能がなくても、システムを開始する時に自動的に開始されていました。 BlueZ initscript は今では、サービスを開始する前にシステム上に Bluetooth ハードウェアが存在することをチェックします。
30
ドラフト ドラフト
31
使用ケースこの章では、２つの使用ケースを例に出してこのガイド内で説明してある分析と設定の方法を描写しています。最初の例では、標準的な サーバーを考慮し、２つ目の例では標準的なラップトップを考慮しています。
4.1. 例 — サーバー最近の一般的な標準のサーバーは、Fedora 14 でサポートされている必要なハードウェアが全て組み込まれています。 最初に考慮すべき事は、サーバーの主要な使用目的となるワークロードの種類です。この情報に基づいて省電力のために最適化されるべきコンポーネントを決定できます。
サーバーのタイプに関係無く、グラフィックスのパフォーマンスは一般に必要ありません。そのため、GPU の節電はオンのままで結構です。
ウェブサーバーウェブサーバーはネットワークとディスク I/O を必要とします。外部の接続スピードによっては、100 Mbit/s で十分かも知れません。 マシンがほとんど静的なページをサービスする場合は、CPU のパフォーマンスは非常に重要ではないでしょう。電力管理の選択には以下を含めます:
• tuned 用にはディスクやネットワークプラグイン無し
• ALPM をオンで維持
• ondemand governor をオンで維持
• ネットワークカードは 100 Mbit/s に制限
演算サーバー演算サーバーは主に CPU を必要とします。電力管理への選択には以下を含めます:
• ジョブとデータストレージが発生する場所に応じて、tuned 用のディスク、又はネットワークプラグイン。又はバッチモードシステム用には、完全にアクティブになった tuned
• 活用に応じて、多分 performance governor
メールサーバーメールサーバーには大体、ディスク I/O と CPU が必要です。電力管理の選択には以下を含めます:
• ondemand governor をオンで維持。CPU パフォーマンスの最後の数パーセントは重要でないことが理由です。
• tuned 用にはディスクやネットワークプラグイン無し
• メールは多くの場合、内部で発生するため、1 Gbit/s か 10 Gbit/s のリンクを利用できる理由でネットワークスピードは制限しません。
ファイルサーバーファイルサーバーの要件はメールサーバーの要件に似ています。しかし使用するプロトコル次第では、もっとCPU パフォーマンスが必要かも 知れません。一般的に Samba ベースのサーバーは NFS よりも CPU を要求して、NFS は一般的に iSCSI よりも CPU を要求します。そのため、 ondemand governor を使用できるはずです。
第4章 使用ケース ドラフト
32
ディレクトリサーバーディレクトリサーバーは一般的に、低い ディスク I/O 要求を持ちます。特に十分な RAM がある場合はそうです。ネットワーク遅延は重要ですが、 ネットワーク I/O はそれほどでもありません。ユーザーはより低いリンクスピードで遅延ネットワークチューンを考慮するかも知れませんが、 特定の使用中ネットワーク用に注意深くこれをテストする必要があります。
4.2. 例 — ラップトップ電力管理と節電が本当の効果を生むもう１つの非常に一般的な対象はラップトップです。設計的に元々、ラップトップはワークステーションやサーバーよりも劇的に低レベルのエネルギーを使用するタイプであるため、絶対的な節電の可能性は他のマシンよりも小さいものです。しかしバッテリモードの状態では、少しの節電でもラップトップのバッテリ寿命を数分でも延長する助けになります。このセクションでは、ラップトップのバッテリモード使用 に焦点を置いていますが、AC 電源の使用状態でもこれらのチューニングの一部、又は全てを活かすことができます。
単独のコンポーネントに対する節電は通常、ワークステーションで見られるよりも比較的に大きな相違をラップトップで認識できます。 例えば、100 Mbits/s で実行している 1 Gbit/s ネットワークインターフェイスはおよそ3–4 ワット節約します。 約 400 ワットの合計電力消費を持つ標準的なサーバーにはこの節約はおよそ 1 %です。約 40 ワットの合計電力消費を持つ ラップトップ上では、この１つのコンポーネント上の節電が合計およそ 10 % になります。
標準的なラップトップ上での特定の節電最適化には以下が含まれます:
• 使用しない全てのハードウェアを無効にするようにシステム BIOS を設定。例えば、パラレル、又はシリアルのポート、カードリーダ、ウェブカム、 WiFi, 及び Bluetooth などが設定可能な項目です。
• 画面を快適に読み取るのに最高輝度が必要無い暗めの場所では、ディスプレイ輝度を低下。これには、GNOME デスクトップ上では、システム+個人設定 → 電力管理 と進みます。KDE デスクトップ上では、アプリケーション起動キックオフ（Kickoff Application Launcher）+コンピュータ+システム設定+高度な設定→ 電力管理 と進みます。又は、コマンドラインで gnome-power-manager か、 xbacklight を使用するか、又はラップトップで function キーを使用します。
• Use the laptop-battery-powersave profile of tuned-adm to enable a whole set of power-savingmechanisms. Note that performance and latency for the hard drive and network interface areimpacted.
追加として（代替として）各種システム設定に小調節を実行することもできます:
• ondemand governor を使用（Fedora 14 ではデフォルトで有効）
• ラップトップモードを有効化（laptop-battery-powersave プロフィールの一部）:
echo 5 > /proc/sys/vm/laptop_mode
• ディスクへのフラッシュ時間を増加（laptop-battery-powersave プロフィールの一部）:
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
• disable nmi (non-maskable interrupt)1 watchdog (part of the laptop-battery-powersave profile):
1 http://en.wikipedia.org/wiki/Non-maskable_interrupt
ドラフト 例 — ラップトップ
33
echo 0 > /proc/sys/kernel/nmi_watchdog
• AC97 オーディオ節電機能を有効化（Fedora 14 ではデフォルトで有効）:
echo Y > /sys/module/snd_ac97_codec/parameters/power_save
• マルチコア節電を有効化（laptop-battery-powersave プロフィールの一部）:
echo Y > /sys/module/snd_ac97_codec/parameters/power_save
• USB 自動サスペンドを有効化:
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
Note that USB auto-suspend does not work correctly with all USB devices.
• ALPM 用の最低電力設定を有効化（laptop-battery-powersave プロフィールの一部）:
echo min_power > /sys/class/scsi_host/host*/link_power_management_policy
• relatime を使用してファイルシステムをマウント（Fedora 14 ではデフォルト）:
mount -o remount,relatime mountpoint
• ハードドライブ用に最善の節電モードをアクティベート（laptop-battery-powersave プロフィールの一部）:
hdparm -B 1 -S 200 /dev/sd*
• CD-ROM ポーリングを無効化（laptop-battery-powersave プロフィールの一部）:
hal-disable-polling --device /dev/scd*
• 画面の輝度を 50 かそれ以下に低下。例えば:
xbacklight -set 50
• スクリーンアイドル状態に DPMS をアクティベート:
xset +dpms; xset dpms 0 0 300
• Wi-Fi の電力レベルを低減（laptop-battery-powersave プロフィールの一部）:
for i in /sys/bus/pci/devices/*/power_level ; do echo 5 > $i ; done
• Wi-Fi を停止:
echo 1 > /sys/bus/pci/devices/*/rf_kill
第4章 使用ケース ドラフト
34
• 有線ネットワークを 100 Mbit/s に限定（laptop-battery-powersave プロフィールの一部）:
ethtool -s eth0 advertise 0x0F
ドラフト ドラフト
35
付録A 開発者へのヒント全ての良いプログラミング教本はメモリー割り当ての問題と特定機能のパフォーマンスを言及しています。自分自身のソフトウェアを開発する時、 そのソフトウェアが稼働するシステムで電力消費が増加する可能性の問題に注意して下さい。これらの配慮はコードの全ての行に影響するものでは ありませんが、頻繁にパフォーマンスのボトルネックになるエリアではコードを最適化する必要があるでしょう。
頻繁に問題を起こす技術には以下が含まれます:
• スレッドの使用
• 不必要な CPU の目覚めと目覚めを効率良く使用しない状態。目を覚ます必要がある場合は、全てを一度に（race to idle と呼ぶ）、出来るだけ 迅速に実行します。
• [f]sync() を不必要に使用
• 不必要なアクティブポーリング、又は短い通常のタイムアウトの使用。（代わりにイベントに反応）
• 目覚めを効率的に使用していない。
• 低効率のディスクアクセス。頻繁なディスクアクセスを回避するために大きめのバッファを使用して下さい。一度に大きなブロックを 書き込むことです。
• 低効率のタイマーの使用。可能な限りアプリケーション群（又はシステム群）に渡ってタイマーをグループ化する方がいいでしょう。
• 過度の I/O、電力消費、又はメモリー使用（メモリーリークを含む）
• 不必要な演算の実行。
以下のセクションでは、これらの分野をもっと詳しく検証していきます。
A.1. スレッドを使用スレッドの使用はアプリケーションのパフォーマンスをより良くより速くすると広く信じられていますが、これは全てのケースではありません。
PythonPython は Global Lock Interpreter 1 を使用しますので、 スレッディングは大規模な I/O 運用でのみ効果的になります。 Unladen-swallow 2 は Python のより迅速な実装ですからこれによってコードを 最適化できる可能性があります。
PerlPerl のスレッドは、本来フォーキングの無いシステム（32-bit Windows オペレーティングシステムを持つシステムなど）で実行している アプリケーション用に創造されています。Perl のスレッドでは、データは全ての単独スレッド用にコピー (Copy On Write) されます。ユーザーがデータ共有のレベルを定義できるべきであるため、データはデフォルトでは共有されません。データ共有の為には threads::shared モジュールが含まれる必要があります。しかし、データはそこでコピー (Copy On Write) されるだけでなく、モジュールはデータ用の結束した変数も作成します。これでもっと時間がかかり、余計に遅くなります。3
1 http://docs.python.org/c-api/init.html無thread-state-and-the-global-interpreter-lock2 http://code.google.com/p/unladen-swallow/3 http://www.perlmonks.org/?node_id=288022
付録A 開発者へのヒント ドラフト
36
CC のスレッドは同じメモリーを共有します。各スレッドはそれ自身のスタックを持ち、カーネルは新規のファイル記述子を作成したり、 新しいメモリースペースの割り当てをする必要がありません。C はより多くのスレッドのためにより多くの CPU のサポートを本当に活用できます。 そのため、スレッドのパフォーマンスを最大にするには、C か C++ などの低レベルの言語を使用すべきです。スクリプティング言語を使用している 場合は、C バインディングを考慮して下さい。プロファイラを使用すると、コード内の貧弱なパフォーマンス部分を識別できます。4
A.2. Wake-ups（目覚め）多くのアプリケーションが変更を確認するのに設定ファイルをスキャンします。多くのケースでは、このスキャンは例えば、毎分などと決まった 間隔で実行されます。スキャンはスローダウンしているディスクを強制的に目覚させるため、これが問題になります。最善の策は適切なチェック間隔や、適切なチェックメカニズムを見つけるか、又は inotify で変更をチェックして、イベントに対応することです。 inotify はファイルやディレクトリ上で多様な変更をチェックできます。
例えば:
int fd;fd = inotify_init();int wd;/* checking modification of a file - writing into */wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY);if (wd < 0) { inotify_cant_be_used(); switching_back_to_previous_checking();}...fd_set rdfs;struct timeval tv;int retval;FD_ZERO(&rdfs);FD_SET(0, &rdfs);
tv.tv_sec = 5;value = select(1, &rdfs, NULL, NULL, &tv);if (value == -1) perror(select);else { do_some_stuff();}...
このアプローチの優越性は実行できるチェックの多様性にあります。
主となる制限は、１つのシステムでは利用できる監視の数が限定されていることです。この数は /proc/sys/fs/inotify/max_user_watches から取得できます。変更は可能ですがそれは推薦できません。更には、 inotifyに障害がある場合、コードは異なるチェック手段に戻る必要がありますが、これは通常ソースコード内の #if#define の多発を意味します。
inotify についての詳細情報には、inotify man ページを参照して下さい。
4 http://people.redhat.com/drepper/lt2009.pdf
ドラフト Fsync
37
A.3. Fsyncfsync は I/O の高度なオペレーションとして知られます。しかしこれは完全に真実ではありません。例えば、Theodore Ts'o's の記事 Don't fear the fsync! 5 と、そのページの議論を参照してみて下さい。
Firefox は、ユーザーが新しいページに移動するためにクリックする度に sqlite ライブラリをコールしていました。sqlite は fsync をコールして、そのファイルシステム セッティング（主に data-ordered モードの ext3）のため、何も発生しないと長い遅延となっていました。同じタイミングで別のプロセスが 大きなファイルをコピーしている場合は、これは長い時間（最大30 秒）がかかっていました。
しかし、他のケースでは、fsync が全く使用されていない場所では、ext4 ファイルシステムへの切り替えの際に問題が発生していました。Ext3 は data-ordered モードでセットされていて、これが数秒毎にメモリーを一掃してファイルの内容をディスクに保存しました。 しかし、ext4 での laptop_mode は保存の間隔がもっと長く、システムが不意にオフになった場合に、データが消失する可能性がありました。 現在は、ext4 はパッチを適用しましたが、それでもまだ使用するアプリケーションを注意深く設計して適切に fsync を使用しなければなりません。
設定ファイルに対する以下の読み込みと書き込みの簡単な例は、ファイルのバックアップが作成されるステップとデータが喪失される流れを 示しています:
/* open and read configuration file e.g. ~/.kde/myconfig */fd = open("./kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);read(myconfig);...write(fd, bufferOfNewData, sizeof(bufferOfNewData));close(fd);
より良いアプローチは多分:
open("/.kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);read(myconfig);...fd = open("/.kde/myconfig.suffix", O_WRONLY|O_TRUNC|O_CREAT);write(fd, bufferOfNewData, sizeof(bufferOfNewData));fsync; /* paranoia - optional */...close(fd);rename("/.kde/myconfig", "/.kde/myconfig~"); /* paranoia - optional */rename("/.kde/myconfig.suffix", "/.kde/myconfig");
5 http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
38
ドラフト ドラフト
39
付録B 改訂履歴改訂 0.1 Thu Jul 29 2010 Landmann Rüdiger [FAMILY Given]
Bring upstream
40