電力管理ガイド - Fedora Documentation

Fedora 18
電力管理ガイド
Fedora における電力消費の管理について
Domingo Don [FAMILY Given]
Landmann Rüdiger [FAMILY Given]
Reed Jack [FAMILY Given]
電力管理ガイド
Fedora 18 電力管理ガイド
Fedora における電力消費の管理について
エディッション 1.0
著者
著者
著者
Domingo Don [FAMILY Given]
Landmann Rüdiger [FAMILY
Given]
Reed Jack [FAMILY Given]
[email protected]
Copyright © 2012 Red Hat Inc. and others.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is
available 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 must
provide 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 Infinity
Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other
countries.
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 United
States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and
other countries.
All other trademarks are the property of their respective owners.
このドキュメントでは、Fedora 17 システムで効果的に電力消費を管理する方法を説明しています。以下のセク
ションでは電力消費を低減する異なる技術（サーバーとラップトップの両方）と、各技術がシステムの全体的な
パフォーマンスにいかに影響するかを説明します。なお、このドキュメントはまだ開発中であり、大幅に変更され
る可能性があります。そのため現時点でプレビューとして提供されています。本文中にある内容と指導事項はま
だ完全でなく、注意して取り扱う必要があります。
序文
v
1. 表記方法 ......................................................................................................................... v
1.1. 印刷における表記方法 ............................................................................................ v
1.2. 引用における表記方法 ........................................................................................... vi
1.3. 注記および警告 ................................................................................................... vii
2. フィードバック .................................................................................................................. vii
1. 概説
1
1.1. 電力管理の重要性 ........................................................................................................ 1
1.2. 電力管理の基礎 ............................................................................................................ 2
2. 電力管理の監査と分析
5
2.1. 監査と分析の概要 ......................................................................................................... 5
2.2. PowerTOP .................................................................................................................. 5
2.3. Diskdevstat と netdevstat ............................................................................................ 7
2.4. Battery Life Tool Kit ................................................................................................. 10
2.5. Tunedとktune ........................................................................................................... 12
2.5.1. tuned.conf ファイル ......................................................................................... 13
2.5.2. Tuned-adm .................................................................................................... 14
2.6. UPower .................................................................................................................... 17
2.7. GNOME Power Manager .......................................................................................... 17
2.8. acpid ........................................................................................................................ 18
2.9. 監査用の他の手段 ...................................................................................................... 18
3. コアインフラストラクチャとメカニクス
3.1. CPUアイドル状態 ........................................................................................................
3.2. CPUfreq Governors の使用 .........................................................................................
3.2.1. CPUfreq Governor のタイプ ............................................................................
3.2.2. CPUfreq のセットアップ ....................................................................................
3.2.3. CPUfreq のポリシーと速度のチューニング ...........................................................
3.3. CPUモニター ..............................................................................................................
3.4. CPU 節電ポリシー ......................................................................................................
3.5. 一時停止と再開 ..........................................................................................................
3.6. ティックレス・カーネル ...................................................................................................
3.7. Active-State Power Management ..............................................................................
3.8. Aggressive Link Power Management .........................................................................
3.9. リアルタイム・ドライブ・アクセス最適化 ............................................................................
3.10. パワーキャッピング（Power Capping） ..........................................................................
3.11. Enhanced Graphics Power Management ................................................................
3.12. RFKill ......................................................................................................................
3.13. ユーザースペースの最適化 .........................................................................................
21
21
21
22
23
24
25
25
26
26
26
27
28
28
29
30
31
4. 使用ケース
33
4.1. 例 — サーバー ........................................................................................................... 33
4.2. 例 — ラップトップ ........................................................................................................ 34
A. 開発者へのヒント
A.1. スレッドを使用 .............................................................................................................
A.2. Wake-ups（目覚め） ....................................................................................................
A.3. Fsync ........................................................................................................................
37
37
38
39
B. 改訂履歴
41
iii
iv
序文
1. 表記方法
本ガイドは特定の単語や語句を強調したり、記載内容の特定部分に注意を引かせる目的で次のような表記方
法を使用しています。
1
PDF版および印刷版では、 Liberation Fonts セットから採用した書体を使用しています。ご使用のシステム
に 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/
v
序文
メインメニューバーからシステム > 個人設定 > マウスの順で選択しマウスの個人設定を
起動します。ボタンタブ内で左ききのマウスチェックボックスをクリックしてから閉じるをク
リックしマウスの主要ボタンを左から右に切り替えます (マウスを左ききの人が使用するのに
適した設定にする)。
gedit ファイルに特殊な文字を挿入する場合は、メインメニューバーからアプリケーション >
アクセサリ > 文字マップの順で選択します。次に文字マップメニューバーから検索 > 検
索… と選択して検索フィールド内にその文字名を入力し次をクリックします。探している
文字が文字表内で強調表示されます。この強調表示された文字をダブルクリックするとコ
ピーするテキストフィールド内に置かれるので次にコピーボタンをクリックします。ここでド
キュメントに戻り gedit メニューバーから編集 > 貼り付けを選択します。
上記には、アプリケーション名、システム全体のメニュー名と項目、アプリケーション固有のメニュー名、 GUI
インタフェースで見られるボタンやテキストがあります。すべてプロポーショナルの太字で表示されているため
文中内で見分けやすくなっています。
等等等等等等等等等等または等等等等等等等等等等等等等等等等
等幅の太字やプロポーショナルの太字はいずれであっても斜体の場合は置換可能なテキストか変化するテキ
ストを示します。斜体は記載されている通りには入力しないテキスト、あるいは状況に応じて変化する出力テキ
ストを表します。例えば、
ssh を使用してリモートマシンに接続するには、シェルプロンプトで 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
books_tests
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
ソースコードの一覧も mono-spaced roman (等幅の Roman) でセットされますが、以下のように強調表示され
ます。
package org.jboss.book.jca.ex1;
vi
注記および警告
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. フィードバック
本ガイドに誤植を見つけられた場合や本ガイドの改善案をお持ちの場合はぜひお知らせください。 Bugzilla
http://bugzilla.redhat.com/bugzilla/ にて、 Product には Fedora Documentation. を選びレポートの提出
をお願いいたします。
バグレポートを提出される場合は、そのガイドの識別子となる power-management-guide を必ず明記して頂
くようお願いします。
vii
序文
ドキュメントに関する改善のご意見についてはできるだけ具体的にお願いいたします。エラーを発見された場
合は、セクション番号および該当部分の前後の文章も含めてご報告頂くと照合が容易になります。
viii
概説
コンピュータに使用する電力を制限していくということは、グリーン IT という観点でもっとも重要となる課題
のひとつであり、このグリーンITはリサイクルできる資源の利用、ハードウェアの製造により環境に及ぼす影
響、システム設計やシステム導入における環境意識などといった点についても配慮しています。本ガイドでは
Fedora 17 が稼働するシステムでの電力管理について説明しています。
1.1. 電力管理の重要性
電力管理の中核には、各システムコンポーネントの電力消費をいかに効果的に最適化すべきかの理解があり
ます。これにはシステムが実行する異なるタスクの研究を必要とします。そして各コンポーネントを設定してその
仕事に対してパフォーマンスが適切であることを確実にしなければなりません。
電力管理の主な理由には次のようなものがあります。
• コスト節約のための全体的な消費電力の削減
電力管理の正しい活用は以下の結果を生みます:
• サーバーとデータセンターの熱削減
• 冷却、空間、ケーブル、発電機、および UPS (無無無無無無無) を含む二次コストの削減
• ノート PC のバッテリー寿命の延長
• CO2排出量の低減
• グリーン IT に関して政府の規則、または法的要請に適合すること。例えば、Energy Starなど
• 新システムにおける企業のガイドラインに適合すること
原則としては、特定コンポーネント（またはシステム全体）の消費電力を低減することは、発生熱の低下になり、
そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低下を、
特にミッションクリティカルなシステムに於いて研究してテストするべきです。
システムが実行する諸々のタスクを研究して、ジョブに対してパフォーマンスがちょうど十分であるように各コ
ンポーネントを設定することで、エネルギーを節約し、発熱を減らし、そしてラップトップのバッテリ寿命を最適
化することができます。電力消費に関するシステムの分析とチューニングの為の原則の多くはパフォーマンス
チューニングの原則と良く似ています。システムは通常、パフォーマンスか電力に向けて最適化してあるため、あ
る程度は電力管理とパフォーマンスチューニングはシステム設定に於いて対立するアプローチを取ります。本ド
キュメントでは、 Fedora Project が提供するツールとこのプロセスでユーザーを支援するために弊社が開発し
てきた技術を説明しています。
Fedora 17 は多くの新しい電力管理機能を搭載しており、デフォルトで有効になっています。これらはすべて、
標準的なサーバーまたはデスクトップ使用のパフォーマンスに影響を与えないように配慮されています。しか
し、特殊な利用ケースで最大のスループット、最小の遅延、また最高の CPU パフォーマンスが絶対的に要求さ
れる状態では、これらのデフォルト設定の見直しが必要でしょう。
本ドキュメントで説明してある技術を使用してマシンを最適化すべきかどうかの判断には、以下のような自問を
して見てください:
問：
電力を最適化すべきですか？
答：
電力最適化の重要性は、企業が追従すべきガイドラインを持っているかどうか、または達成すべき基準が
あるかどうかによって変化します。
1
第1章概説
問：
どれくらい最適化する必要がありますか ?
答：
ここで紹介してある技術のいくつかは、マシンの詳細に渡る監査と分析の全プロセスを実践することを要
求しません。しかし、その代わりに標準的な電力使用を普通に最適化できる方法のセットを提供します。こ
れらの方法はもちろん手動のシステム監査と最適化ほど良くはありませんが、十分な妥当性を提供しま
す。
問：
最適化はシステムパフォーマンスを容認できないレベルまで下げますか ?
答：
このドキュメント内に説明してあるほとんどの技術は使用システムに認識できるほどの影響を与えま
す。Fedora 17 内にすでに設定されてあるデフォルト値を超過するような電力管理の実装を選択した場
合、電力最適化を実行した後のシステムパフォーマンスを監視して、パフォーマンス損失が容認できるか
どうかを判断する必要があります。
問：
最適化に時間やリソースを費した場合、そこから得られる結果より負担の方が大きくなってしまいます
か？
答：
1台のシステムを全プロセスにしたがい手作業で最適化を行っても、その時間やリソースはマシンの寿命
が尽きるまでに得られるであろう利便性をはるかに上回ってしまうため意味がありません。一方、 1 万台
のデスクトップシステムが複数のオフィスに分散しているが構成および設定は同じものを使用している場
合なら、最適化した設定をひとつ構成してそれを 1 万台すべてのマシンに適用していけば十分に役立つ
可能性が高くなります。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシ
ステムに効果を与えるかを説明しています。
1.2. 電力管理の基礎
効率的な電力管理は以下のような原則の上に確立されています:
アイドル状態の CPU は必要な時にだけ活動すべきである
Fedora のカーネルは各 CPU に対して定期的なタイマーを使用していました。このタイマーは、プロセスが実
行中であるかどうかに関係なく、毎回のタイマーイベント（セッティングにより数ミリ秒毎に発生）で CPU がプロ
セスすることを要求するため、CPU が本当にアイドル状態に入ることを妨げていました。効率的な電力管理の
大部分は CPU が目覚める頻度を低減することに関連します。
この理由で、Fedora 17 内の Linux カーネルは定期的なタイマーを取り除いています。その結果、CPU のア
イドル状態は無無無無無無無tickless無です。これが、CPU のアイドル時には CPU が不要な電力消費を防止します。
しかし、システムが不要なタイマーイベントを作り出すアプリケーションを持っている場合にはこの機能からの利
便性は、オフセットされてしまいます。ポーリングイベント（音量の変更、マウス動作、その他をチェックするもの）
はそのようなイベントの例になります。
Fedora 17 には、CPU 使用率を基にしたアプリケーションの識別と監査をできるツールが含まれています。そ
の詳細には、2無無無無無無無無無無無を参照して下さい。
使用していないハードウェアとデバイスは完全に無効にすべきである
稼働部品を持つデバイス（例えば、ハードディスク）には特に分かりやすい例でしょう。これに加えて、一部のア
プリケーションは使用中でなくても有効なデバイスを「オープン」状態で維持するものがあります。これが発生す
ると、カーネルはデバイスは「使用中」だと想定してデバイスが節電状態に入ることを妨げてしまいます。
2
電力管理の基礎
低活動は低ワット数と解釈すべきである
しかし多くのケースでは、この事は最新のハードウェアと正しい BIOS 設定に依存します。旧式のシステムコン
ポーネントは多くの場合、現在 Fedora 17 がサポートする新しい省電力機能の一部をサポートしません。お使
いのシステムに最新の公式なファームウェアを使用していることと、BIOS 内の電力管理設定、またデバイス設
定のセクションが電力管理を有効にしていることを確認して下さい。ここで確認すべき機能には以下が含まれ
ます。
• SpeedStep
• PowerNow!
• Cool'n'Quiet
• ACPI (C-状態)
• Smart
使用中のハードウェアがこれらの機能をサポートしていて、BIOS 内で有効になっている場合は、Fedora 17
は、それらをデフォルトで使用します。
異なる形式の CPU の状態とその効果
ACPI (Advanced Configuration and Power Interface) を持つ最近の CPU は、次の3つの異なる電力状態
を持ちます。
• Sleep (Cステート)
• Frequency (P-状態)
• 発熱 (T-状態もしくは温度状態)
最低スリープ状態で動作しているCPU (最も高いCステート) consumes the least amount of watts, but it
also takes considerably more time to wake it up from that state when needed. In very rare cases
this can lead to the CPU having to wake up immediately every time it just went to sleep. This
situation results in an effectively permanently busy CPU and loses some of the potential power
saving if another state had been used.
オフになっているマシンは最低限の電力を使用する
当たり前のように聞こえますが、確実に節電をする最良の方法の1つはシステムの電源をオフにすることです。
例えば、所属する企業が「グリーン IT」の意識に焦点を置く企業文化を定め、昼食時や帰宅時にマシンの電源
オフにするガイドラインを策定することができます。また、数台の物理サーバーを1つの大きなサーバーに統合し
て、Fedora 17 で提供されている仮想化技術を使用してサーバーを仮想化をすることもできます。
3
4
電力管理の監査と分析
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. PowerTOP
The tickless kernel in Fedora allows the CPU to enter the idle state more frequently, reducing
power consumption and improving power management. The new PowerTOP tool identifies
specific components of kernel and user-space applications that frequently wake up the CPU.
PowerTOP was used in development to perform the audits described in 無無無無無無無無無無無無無無 that led
to many applications being tuned in this release, reducing unnecessary CPU wake up by a factor
of ten.
Fedora 17 comes with version 2.x of PowerTOP. This version is a complete rewrite of the 1.x
code base. It features a clearer tab-based user interface and extensively uses the kernel "perf"
infrastructure to give more accurate data. The power behavior of system devices is tracked and
prominently displayed, so problems can be pinpointed quickly. More experimentally, the 2.x
codebase includes a power estimation engine that can indicate how much power individual
devices and processes are consuming. Refer to 無2.1無PowerTOP 無無無無.
以下のコマンドを使用して PowerTOP をインストールします:
yum install powertop
PowerTOP can provide an estimate of the total power usage of the system and show individual
power usage for each process, device, kernel work, timer, and interrupt handler. Laptops
5
第2章電力管理の監査と分析
should run on battery power during this task. To calibrate the power estimation engine, run the
command:
powertop --calibrate
Calibration takes time and requires root privileges. The process performs various tests, and will
cycle through brightness levels and switch devices on and off. Do not touch the machine during
the calibration. When the calibration process finishes, PowerTOP starts as normal. Let it run for
approximately an hour to collect data. When enough data is collected, power estimation figures
will begin appearing in the first column.
次に、次のコマンドを使用してPowerTOPを起動してください:
powertop
You will need to run PowerTOP with root privileges. Your laptop should still be running on
battery power so that all available data will be presented.
While it runs, PowerTOP gathers statistics from the system. In the Overview tab, you can view
a list of the components that are either sending wake-ups to the CPU most frequently or are
consuming the most power (refer to 無2.1無PowerTOP 無無無無). The adjacent columns display
power estimation, how the resource is being used, wakeups per second, the classification of the
component (such as process, device, or timer), and a description of the component. Wakeups
per second indicates how efficiently the services or the devices and drivers of the kernel are
performing. Less wakeups means less power is consumed. Components are ordered by how
much further their power usage can be optimized.
Tuning driver components typically requires kernel changes, which is beyond the scope of this
document. However, userland processes that send wakeups are more easily managed. First,
identify if this service or application needs to run at all on this system. If not, simply deactivate it.
To turn off an old SYSV service permanently, run:
chkconfig servicename off
新しいsystemdを恒久的に無効にするには、次を実行するには:
systemctl 等等等等等.等等等等 disable
コンポーネントが実際に実行する動作の詳細が必要な場合は、以下を実行します:
ps -awux | grep componentname
strace -p processid
If the trace looks like it is repeating itself, then you probably have found a busy loop. Fixing such
bugs typically requires a code change in that component, which again goes beyond the scope of
this document.
As seen in 無2.1無PowerTOP 無無無無, total power consumption and the remaining battery life are
displayed, if applicable. Below these is a short summary, featuring total wakeups per second,
GPU operations per second, and virtual filesystem operations per second.
Use the left and right keys to cycle through tabs. In the Idle stats tab, use of C-states is shown
for all processors and cores. In the Frequency stats tab, use of P-states including the Turbo mode
(if applicable) is shown for all processors and cores. The longer the CPU stays in the higher C- or
P-states, the better (C4 being higher than C3). This is a good indication of how well CPU usage has
6
Diskdevstat と netdevstat
been optimized. Residency should ideally be 90% or more in the highest C- or P-state while the
system is idle.
The Device Stats tab provides similar information to Overview but only for devices.
The Tunables tab contains suggestions for optimizing the system for lower power consumption.
The up and down keys can be used to move through suggestions. The enter key toggles the
suggestion on and off. These tunings are not persistent across reboots. This problem has been
referred to developers.
図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 運用を繰り替えして電
力を無駄にしているアプリケーションを識別できるようになります。転送スピードのみを測定する他の監視ツー
ルはこのタイプの識別には助けにはなりません。
7
第2章電力管理の監査と分析
First, install kernel-debuginfo with the following command:
debuginfo-install kernel
Then install the tools with SystemTap:
yum install systemtap tuned-utils
次のコマンドでツールを実行します:
diskdevstat
あるいは、コマンド:
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 実行からのサンプル出力を示します:
8
PID
UID DEV
WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG
READ_CNT
READ_MIN
READ_MAX
2789
2903 sda1
854
0.000
120.000
15494
0 sda1
0
0.000
15520
0 sda1
0
15549
0 sda1
15585
READ_AVG COMMAND
39.836
0
0.000
0.000
0.000 plasma
0.000
0.000
758
0.000
0.012
0.000 0logwatch
0.000
0.000
0.000
140
0.000
0.009
0.000 perl
0
0.000
0.000
0.000
140
0.000
0.009
0.000 perl
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
Diskdevstat と netdevstat
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
laptop_mode
2153
0 sda1
0
0.000
0.000
0.000
37
0.000
0.014
0.001
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
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
DEV
I/O が発生するデバイス
WRITE_CNT
書き込み操作の全回数
WRITE_MIN
連続した２回の書き込みに要した最短の時間 (秒)
9
第2章電力管理の監査と分析
WRITE_MAX
連続した２回の書き込みに要した最長の時間 (秒)
WRITE_AVG
連続した２回の書き込みに要した平均時間 (秒)
READ_CNT
読み込み操作の全回数
READ_MIN
連続した２回の読み込みに要した最短時間 (秒)
READ_MAX
連続した２回の読み込みに要した最長時間 (秒)
READ_AVG
連続した２回の読み込みに要した平均時間 (秒)
COMMAND
プロセスの名前
この例では、３つの非常に目立つアプリケーションが突出しています:
PID
2789
2573
2153
UID
2903
0
0
DEV
sda1
sda1
sda1
WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG
854
0.000
120.000
39.836
63
0.033 3600.015
515.226
26
0.003 3600.029 1290.730
READ_CNT
0
0
0
READ_MIN
0.000
0.000
0.000
READ_MAX
0.000
0.000
0.000
READ_AVG
0.000
0.000
0.000
COMMAND
plasma
auditd
rsyslogd
これらの３つのアプリケーションは、0 以上の WRITE_CNT を持っており、これは測定中になんらかの書き込みを
実行したことを意味します。その中で、plasma が大差をもって最大の悪事をしています。最多の書き込み操作
を実行しているため、当然書き込みまでの間隔は最短の平均時間を示します。そのため、電力効率の悪いアプ
リケーションに懸念がある場合には、Plasma が調査の最大のターゲットとなります。
strace コマンドと ltrace コマンドを使用して、任意のプロセス ID の全てのシステムコールを追跡することに
よりアプリケーションをもっと詳しく検査できます:
strace -p 2789
この例では、strace の出力は、書き込み用にユーザーの KDE アイコンキャッシュファイルを開いて、その直後に
ファイルを閉じる動作を 45秒毎に繰り返す同じパターンを含んでいました。この繰り返しが、ファイルメタ情報
（特に、修正時間）の変更時に、ハードディスクへの必要な物理的書き込みになったのです。最終的な修復は、
アイコンへの更新が発生していない時にこれらの不要なコールを阻止することでした。
2.4. Battery Life Tool Kit
BLTK（Battery Life Tool Kit）はこれはバッテリの寿命とパフォーマンスをシミュレーションにて解析するテスト
スイートです。BLTK は特定のユーザーグループに対してシミュレーションをするタスクのセットを実行してその
結果を報告することで、その目的を達成します。特にノートブックのパフォーマンスをテストするために開発され
たのですが、BLTK は -a を付けて開始すると、デスクトップコンピュータのパフォーマンスも報告できます。
BLTK の使用により、実際のマシン使用と比較できる再現可能なワークロードを生成できるようになります。例
えば、office のワークロードはテキストを書き込み、その中の間違いを修正します。そしてスプレッドシートも同
じ事をします。BLTK を PowerTOP 、または他の監査用や、解析用ツールと一緒に実行すると、ユーザーが実
行する最適化はマシンがアイドル時ではなく、活発に使用されている時に効果を持つかどうかをテストできるよ
うになります。異なる設定を評価したい場合、全く同一のワークロードを複数回にわたり実行できるため、その
結果を異なる設定を比較することができます。
10
Battery Life Tool Kit
以下のコマンドを使用して BLTK をインストールします:
yum install bltk
以下のコマンドで BLTK を実行します:
bltk workload options
例えば、idle のワークロードを 120 秒間実行するには:
bltk -I -T 120
デフォルトで使用できるワークロードは次の通りです:
-I, --idle
システムはアイドル状態です。他のワークロードとの比較でベースとして使用します。
-R, --reader
ドキュメントを読み込むシミュレーション（デフォルトで、Firefox を使用）
-P, --player
CD 又は DVD のマルチメディアファイルを見ているシミュレーションをします（デフォルトで、mplayer を使
用）
-O, --office
OpenOffice.org スイートを使用してドキュメントの編集をシミュレーションします
その他、指定できるオプション:
-a, --ac-ignore
AC 電源が使用可能であるかどうかを無視（デスクトップ上で実行時に必要）
-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 オプションを使用します:
11
第2章電力管理の監査と分析
bltk_report -o path_to_results_directory
2.5. Tunedとktune
Tuned is a daemon that monitors the use of system components and dynamically tunes system
settings based on that monitoring information. Dynamic tuning accounts for the way that
various system components are used differently throughout the uptime for any given system. For
example, the hard drive is used heavily during startup and login, but is barely used later when
a user might mainly work with applications like OpenOffice or email clients. Similarly, the CPU
and network devices are used differently at different times. Tuned monitors the activity of these
components and reacts to changes in their use.
As a practical example, consider a typical office workstation. Most of the time, the Ethernet
network interface will be very inactive. Only a few emails will go in and out every once in a while
or some web pages might be loaded. For those kinds of loads, the network interface doesn't have
to run at full speed all the time, as it does by default. Tuned has a monitoring and tuning plugin
for network devices that can detect that low activity and then automatically lower the speed
of that interface, typically resulting in lower power usage. If activity on the interface increases
drastically for a longer period of time, for example because a DVD image is being downloaded
or an email with a large attachment is opened, tuned detects this and sets the interface speed to
maximum to offer the best performance while the activity level is so high. This principle is used
for the other plugins for CPU and hard disks as well.
Network devices are not configured to behave this way by default because speed changes can
take several seconds to take effect and therefore directly and visibly impact the user experience.
Similar considerations apply for the CPU and hard drive tuning plugins. When a hard drive has
been spun down, it can take several seconds for it to spin up again which results in an observed
lack of responsiveness of the system during that period. The latency side effect is smallest for the
CPU plugin, but it is still at least measurable, though hardly noticeable by a user.
Alongside of tuned we now also offer ktune. Ktune was originally a framework and service to
optimize the performance of a machine for a specific use cases. Since then, ktune has improved
to such a degree that we now use it as the static part of our general tuning framework. It is mainly
used in the different predefined profiles described in 無Tuned-adm無.
Install the tuned package and its associated systemtap scripts with the command:
yum install tuned
Installing the tuned package also sets up a sample configuration file at /etc/tuned.conf and
activates the default profile.
次を実行してtunedを起動します:
service tuned start
tunedをシステム起動時に起動するには、次を実行します:
chkconfig tuned on
Tuned itself has additional options that you can use when you run it manually. The available
options are:
12
tuned.conf ファイル
-d, --daemon
tuned をフォアグラウンドではなくデーモンとして起動します。
-c, --conffile
use a configuration file with the specified name and path, for example, --conffile=/etc/
tuned2.conf. The default is /etc/tuned.conf.
-D, --debug
最高レベルのログを使用します。
2.5.1. tuned.conf ファイル
The tuned.conf file contains configuration settings for tuned. By default, it is located at /etc/
tuned.conf, but you can specify a different name and location by starting tuned with the -conffile option.
The config file must always contain a [main] section that defines the general parameters for
tuned. The file then contains a section for each plugin.
The [main] section contains the following options:
interval
the interval at which tuned should monitor and tune the system, in seconds. The default
value is 10.
verbose
specifies whether output should be verbose. The default value is False.
logging
specifies the minimum priority of messages to be logged. In descending order, allowable
values are: critical, error, warning, info, and debug. The default value is info.
logging_disable
specifies the maximum priority of messages to be logged; any messages with this priority or
lower will not be logged. In descending order, allowable values are: critical, error, warning,
info, and debug. The value notset disables this option.
Each plugin has its own section, specified with the name of the plugin in square brackets; for
example: [CPUTuning]. Each plugin can have its own options, but the following apply to all
plugins:
enabled
specifies whether the plugin is enabled or not. The default value is True.
verbose
specifies whether output should be verbose. If not set for this plugin, the value is inherited
from [main].
logging
specifies the minimum priority of messages to be logged. If not set for this plugin, the value is
inherited from [main].
A sample config file follows:
[main]
interval=10
pidfile=/var/run/tuned.pid
13
第2章電力管理の監査と分析
logging=info
logging_disable=notset
# Disk monitoring section
[DiskMonitor]
enabled=True
logging=debug
# Disk tuning section
[DiskTuning]
enabled=True
hdparm=False
alpm=False
logging=debug
# Net monitoring section
[NetMonitor]
enabled=True
logging=debug
# Net tuning section
[NetTuning]
enabled=True
logging=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
The CPU tuning plugin recently added support for the Super Hybrid Engine (SHE), as found
on some Asus EEEPCs. If you are using this engine, you can enable SHE support by adding
eeefsb=True into the [CPUTuning] section of tuned.conf. It will automatically downclock your FSB
and save power while on idle, returning to normal speed when the load increases significantly.
This functionality is enabled by default in the laptop-battery-powersave profile.
2.5.2. Tuned-adm
Often, a detailed audit and analysis of a system can be very time consuming and might not be
worth the few extra watts you might be able to save by doing so. Previously, the only alternative
was simply to use the defaults. Therefore, Fedora 17 includes separate profiles for specific use
cases as an alternative between those two extremes, together with the tuned-adm tool that
allows you to switch between these profiles easily at the command line. Fedora 17 includes a
number of predefined profiles for typical use cases that you can simply select and activate with
the tuned-adm command, but you can also create, modify or delete profiles yourself.
To list all available profiles and identify the current active profile, run:
tuned-adm list
14
Tuned-adm
To only display the currently active profile, run:
tuned-adm active
To switch to one of the available profiles, run:
tuned-adm 等等等等等等等
例:
tuned-adm profile server-powersave
To disable all tuning:
tuned-adm off
When you first install tuned, the balanced profile will be active. The following predefined profiles
are available after installing tuned:
balanced
the default power-saving profile. It enables CPU and disk plugins of tuned and activates the
ondemand governor.
電力節約（powersave）
a profile for maximum power saving performance. It enables USB autosuspend, WiFi power
saving, and ALPM power saving for SATA host adapters (refer to 無Aggressive Link Power
Management無). It also schedules multi-core power savings for systems with a low wakeup rate
and activates the ondemand governor.
throughput-performance
a server profile for typical throughput performance tuning. It disables tuned and ktune power
saving mechanisms, enables sysctl settings that improve the throughput performance of your
disk and network I/O, and switches to the deadline scheduler.
latency-performance
a server profile for typical latency performance tuning. it disables tuned and ktune power
saving mechanisms and enables sysctl settings that improve the latency performance of your
network I/O.
virtual-guest
a profile designed for virtual guests based on the enterprise-storage profile that, among other
tasks, decreases virtual memory swappiness.
virtual-host
a profile designed for virtual hosts based on the enterprise-storage profile that, among other
tasks, decreases virtual memory swappiness and is more aggressive in its writeback of dirty
pages.
Additional predefined profiles are available by installing the tuned-profiles-compat package:
デフォルト
this has the lowest impact on power saving of the available profiles and only enables CPU
and disk plugins of tuned.
15
第2章電力管理の監査と分析
desktop-powersave
a power-saving profile directed at desktop systems. Enables ALPM power saving for SATA
host adapters (refer to 無Aggressive Link Power Management無) as well as the CPU, Ethernet,
and disk plugins of tuned.
server-powersave
a power-saving profile directed at server systems. Enables ALPM powersaving for SATA host
adapters and activates the CPU and disk plugins of tuned.
laptop-ac-powersave
a medium-impact power-saving profile directed at laptops running on AC. Enables ALPM
powersaving for SATA host adapters, Wi-Fi power saving, as well as the CPU, Ethernet, and
disk plugins of tuned.
laptop-battery-powersave
a high-impact power-saving profile directed at laptops running on battery. It activates all
power saving mechanisms from the previous profiles, plus it enables the multi-core powersavings scheduler for low wakeup systems and makes sure that the ondemand governor is
active and that AC97 audio power-saving is enabled. On compatible Asus EEEPCs, it enables
SHE support in the CPU tuning plugin. You can use this profile to save the maximum amount
of power on any kind of system, not only laptops on battery power. The trade-off for this
profile is a noticeable impact on performance, specifically latency of disk and network I/O.
spindown-disk
a power-saving profile for machines with classic HDDs to maximize spindown time. It disables
the tuned power savings mechanism, disables USB autosuspend, disables Bluetooth, enables
Wi-Fi power saving, disables logs syncing, increases disk write-back time, and lowers disk
swappiness. All partitions are remounted with noatime.
enterprise-storage
a server profile directed at enterprise-class storage, maximizing I/O throughput. It activates
the same settings as the throughput-performance profile, multiplies readahead settings, and
disables barriers on non-root and non-boot partitions.
All the profiles are stored in separate subdirectories under /etc/tune-profiles. So /etc/tuneprofiles/desktop-powersave contains all the necessary files and settings for that profile. Each of
these directories contains up to four files:
tuned.conf
the configuration for the tuned service to be active for this profile.
sysctl.ktune
the sysctl settings used by ktune. The format is identical to the /etc/sysconfig/sysctl file
(refer to the sysctl and sysctl.conf man pages).
ktune.sysconfig
the configuration file of ktune itself, typically /etc/sysconfig/ktune.
ktune.sh
an init-style shell script used by the ktune service which can run specific commands during
system startup to tune the system.
The easiest way to start a new profile is to copy an existing one. The laptop-battery-powersave
profile contains a very rich set of tunings already and is therefore a useful starting point. Simply
copy the whole directory to the new profile name like this:
16
UPower
cp -a /etc/tune-profiles/laptop-battery-powersave/ /etc/tune-profiles/myprofile
Modify any of the files in the new profile to match your personal requirements.
2.6. UPower
In Fedora 11 DeviceKit-power assumed the power management functions that were part of HAL
and some of the functions that were part of GNOME Power Manager in previous releases of
Fedora (refer also to 無GNOME Power Manager無. In Fedora 13, DeviceKit-power was renamed
to UPower. UPower provides a daemon, an API, and a set of command-line tools. Each power
source on the system is represented as a device, whether it is a physical device or not. For
example, a laptop battery and an AC power source are both represented as devices.
コマンドラインツールを使用するには upower コマンドを使います。また、次のオプションがサポートされていま
す:
--enumerate, -e
displays an object path for each power devices on the system, for example:
/org/freedesktop/UPower/devices/line_power_AC
/org/freedesktop/UPower/devices/battery_BAT0
--dump, -d
システム上のすべての電源デバイスのパラメーターを表示します。
--wakeups, -w
displays the CPU wakeups on the system.
--monitor, -m
monitors the system for changes to power devices, for example, the connection or
disconnection of a source of AC power, or the depletion of a battery. Press Ctrl+C to stop
monitoring the system.
--monitor-detail
monitors the system for changes to power devices, for example, the connection or
disconnection of a source of AC power, or the depletion of a battery. The --monitor-detail
option presents more detail than the --monitor option. Press Ctrl+C to stop monitoring the
system.
--show-info object_path, -i 等等等等等等等
displays all information available for a particular object path. For example, to obtain
information about a battery on your system represented by the object path /org/
freedesktop/UPower/devices/battery_BAT0, run:
upower -i /org/freedesktop/UPower/devices/battery_BAT0
2.7. GNOME Power Manager
GNOME Power Manager は、GNOME デスクトップの一部としてインストールされているデーモンです。
Fedora の以前のバージョンで提供されていた GNOME Power Manager の電力管理機能の大部分は
Fedora 13 の DeviceKit-power の構成要素となりました (無UPower無参照) 。しかし、GNOME Power
Manager はその機能のフロントエンドとして残ります。システムトレイ上のアプレットを介して GNOME Power
17
第2章電力管理の監査と分析
Manager は、バッテリから AC 電源への切り替えなどのシステムの電源状態の変化を通知します。また、バッ
テリの状態を報告するとともに、バッテリー電力が低下した時点に警告を出します。
また、GNOME Power Manager により基本的な電力管理のセッティングが設定できるようになります。これら
のセッティングにアクセスするには、システムトレイ内の GNOME Power Manager アイコンをクリックして、そ
こで Preferences（個人設定）をクリックします。
Use the On AC power and On battery power ComboBoxes to specify how much time must pass
before an inactive system goes to sleep. You can also choose a standard behavior for a system
with a critically low battery. For example, by default, GNOME Power Manager makes a system
hibernate when its battery level reaches a critically low level. On the bottom of this dialog, you
can set behaviors for the physical power button and suspend button on your system.
2.8. acpid
acpidとは Advanced Configuration and Power Interface (ACPI) イベントと、それらに対する応答としてスク
リプトを実行するデーモンです。イベントは、ノートパソコンの蓋を閉じたり、電源ボタンを押すことによって発生
します。
acpid executes actions based on rules you establish. Certain rules are predefined on installation
but can be altered. These rules are set in configuration files created in /etc/acpi/events.
Each file must define an event and an action on separate lines for each rule. The event= line
identifies the hardware interaction to be configured. The action= line specifies a shell script
containing the configuration, which you must create (typically in /etc/acpi/actions). Multiple
rules can be set for each event, or one rule for multiple events.
acpid ships with one shell script at /etc/acpi/actions/power.sh and two configuration files in /
etc/acpi/events: powerconf and videoconf. powerconf is structured as follows:
# ACPID config to power down machine if powerbutton is pressed, but only if
# no gnome-power-manager is running
event=button/power.*
action=/etc/acpi/actions/power.sh
acpidはデフォルトでインストールされている場合もありますが、すべてのFedoraインストールでインストールさ
れているとは限りません。
2.9. 監査用の他の手段
Fedora 17 はシステムの監査と分析を実行するためのツールを他にもいくつか提供します。それらのほとんど
は既に発見している事項に対して立証したり、特定の部分に於いてより詳しい情報が必要な場合に補助ソース
として使用できるものです。これらのツールの多くはパフォーマンスチューンにも使用されます。それは以下のよ
うになります:
vmstat
vmstat はプロセス、メモリー、ページング、ブロック I/O、トラップ、及び CPU の活動について詳細情報を
提供します。システム全体で実行している動作や多忙な部分を詳しく見るために使用します。
iostat
iostat は vmstat と似ていますが、ブロックデバイスの I/O 専用です。また、詳細な出力と統計を提供しま
す。
18
監査用の他の手段
blktrace
blktrace は非常に詳細に渡るブロック I/O のトレースプログラムです。情報をアプリケーションに関連した
単独のブロックに分割します。diskdevstat と一緒に使用すると大変役に立つものです。
19
20
コアインフラストラクチャとメカニクス
Package required for cpupower
To use the cpupower command featured in this chapter, ensure you have the kernel-tools
package installed.
3.1. CPUアイドル状態
CPUs with the x86 architecture support various states in which parts of the CPU are deactivated
or run at lower performance settings. These states, known as C-states, allow systems to save
power by partially deactivating CPUs that are not in use. C-states are numbered from C0
upwards, with higher numbers representing decreased CPU functionality and greater power
saving. C-States of a given number are broadly similar across processors, although the exact
details of the specific feature sets of the state may vary between processor families. C-States 0–3
are defined as follows:
C0
実行状態。この状態では、CPUは動作中であり、アイドル状態ではありません。
C1, 休止
a state where the processor is not executing any instructions but is typically not in a lower
power state. The CPU can continue processing with practically no delay. All processors
offering C-States need to support this state. Pentium 4 processors support an enhanced C1
state called C1E that actually is a state for lower power consumption.
C2, Stop-Clock
a state where the the clock is frozen for this processor but it keeps the complete state for
its registers and caches, so after starting the clock again it can immediately start processing
again. This is an optional state.
C3, Sleep
a state where the processor really goes to sleep and doesn't need to keep it's cache up to
date. Waking up from this state takes considerably longer than from C2 due to this. Again this
is an optional state.
To view available idle states and other statistics for the CPUidle driver, run the following
command:
cpupower idle-info
IntelのCPU"Nehalem"マイクロアーキテクチャは、新しいC-StateとしてC6を導入しました。C6はCPUへの供
給電圧を0Vまで下げることができますが、通常は80%から90%電力消費を低減します。Fedora 17に含まれ
るカーネルは新しいC-Stateにも最適化されています。
3.2. CPUfreq Governors の使用
使用システムで電力消費と発熱を低減する効果的な方法の１つは、CPUfreq を使用することです。CPU 速度
スケーリングとも呼ばれる CPUfreq はプロセッサのクロック速度を即座に調節できるようにします。これによ
り、システムは低下したクロック速度で稼働して電力を節約します。周波数の変換についての規則として、ク
21
第3章コアインフラストラクチャとメカニクス
ロック速度を上げるか下げるかどうか、そして周波数を変換する時期は CPUfreq governor によって決定され
ます。
governor はシステム CPU の電力特性を定義付けして、それが結果的に CPU のパフォーマンスに影響しま
す。各 governor は作業負荷に関してそれ自身の独特の動作、目的、及び適合性を持っています。このセクショ
ンでは、CPUfreq governor の選択と設定の方法、各 governor の特性、及び各 governor に適している作
業負荷の種類について説明しています。
電力管理に関する主な懸念は以下のようになります:
• サーバーの熱削減
• ラップトップ用のバッテリー寿命の延長
原則としては、特定コンポーネント（又はシステム全体として）の消費電力を低減することは、発生熱の低下に
なり、そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低
下を、特にミッションクリティカルなシステムに於いて研究してテストするべきです。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシ
ステムに効果を与えるかを説明しています。
3.2.1. CPUfreq Governor のタイプ
このセクションでは、Fedora 17 で利用できる CPUfreq governors の異なるタイプを一覧表示して説明して
います。
cpufreq_performance
performance governor は CPU が可能な限り最高のクロック周波数を使用するように強制します。この周波
数は静的にセットしてあるため、変化しません。そのためこの特定の governor は無無無無無無無無無無無無無無これは作
業負荷が大きい時に適していますが、その期間中でも特に CPU が稀にしかアイドルに（又は決して）ならない
時のみとなります。
cpufreq_powersave
それに比較して、powersave governor は CPU が可能な限り最低のクロック周波数を使用するように強制し
ます。この周波数は静的にセットしてあるため、変化しません。そのため、この特定の governor は最大の節電
を提供しますが、無無無 CPU 無無無無無無無の犠牲を持ちます。
「powersave」という言葉は時には勘違いを招きます。全面的負荷を受けている遅い CPU は（原則として）
負荷のない高速の CPU よりも多くの電力を消費します。そのため、低活動が予期できる時には powersave
governor を使用するように CPU を設定することが推奨されますが、この間に予期しない高負荷が発生すると
システムが実際には通常より多くの電力を消費する原因になります。
powersave governor は簡単な表現をすると、CPU にとっては節電よりも速度制限の意味を持ちます。これ
は、発熱が問題となるようなシステムや設置環境で最も役に立つ選択肢です。
cpufreq_ondemand
ondemand governor は動的に変化する governor です。これは負荷が高い時には最高のクロック周波数を
達成して、システムがアイドルの時には最低のクロック周波数を達成するように CPU を変化させます。これに
22
CPUfreq のセットアップ
よりシステムはシステム負荷に応じて電力消費を調節可能にしますが、その犠牲として無無無無無無無無無無を招きま
す。そのため遅延は、システムがアイドルと高負荷の間で頻繁に転換を繰り返すとオンデマンドで提供される
パフォーマンスと節電効果を相殺してしまいます。
ほとんどのシステム上では、ondemand governor は発生熱、消費電力、パフォーマンス、及び管理法の間で
最良の妥協を提供します。システムが１日の内で特定の時間帯にのみ多忙になる状態では、オンデマンドはそ
れ以上の介入を必要とせずに負荷に応じて最高と最低の周波数の間で自動的に転換します。
cpufreq_userspace
The Userspace governor allows userspace programs (or any process running as root) to set the
frequency. Of all the governors, Userspace is the most customizable; and depending on how it is
configured, it can offer the best balance between performance and consumption for your system.
cpufreq_conservative
ondemand governor のように、conservative governor も使用状態に応じてクロック周波数を調節します
（ondemand governor と同様）。しかし、ondemand governor がより攻撃的な手法で最高と最低との周波
数転換を達成するのに対して、conservative governor はもっとゆっくりと周波数間の転換をします。
これが意味することは、conservative governor は単に最高と最低の周波数を選択することではなく、負荷に
対して適切と判断するクロック周波数に調整すると言うことです。これは電力消費に関して価値のある節約を提
供する可能性を持ちますが、ondemand governor よりも無無無無無がその代償となります。
注記
cron ジョブを使用して governor を有効にすることができます。これにより、１日の特定の時間帯に特定の
governor を自動的にセットすることが可能になります。そのため、アイドル時（例えば、終業後）には低周
波数の governor を指定して、高負荷となる時間帯には高周波数に戻ることが出来ます。
For instructions on how to enable a specific governor, refer to 無CPUfreq 無無無無無無無無.
3.2.2. CPUfreq のセットアップ
All CPUfreq drivers are built in and selected automatically, so to set up CPUfreq you just need to
select a governor.
You can view which governors are available for use for a specific CPU using:
cpupower frequency-info --governors
You can then enable one of these governors on all CPUs using:
cpupower frequency-set --governor [governor]
To only enable a governor on specific cores, use -c with a range or comma-separated list of CPU
numbers. For example, to enable the Userspace governor for CPUs 1-3 and 5, the command
would be:
23
第3章コアインフラストラクチャとメカニクス
cpupower -c 1-3,5 frequency-set --governor cpufreq_userspace
3.2.3. CPUfreq のポリシーと速度のチューニング
Once you have chosen an appropriate CPUfreq governor, you can view CPU speed and policy
information with the cpupower frequency-info command and further tune the speed of each CPU
with options for cpupower frequency-set.
For cpupower frequency-info, the following options are available:
• --freq — Shows the current speed of the CPU according to the CPUfreq core, in KHz.
• --hwfreq — Shows the current speed of the CPU according to the hardware, in KHz (only
available as root).
• --driver — Shows what CPUfreq driver is used to set the frequency on this CPU.
• --governors — Shows the CPUfreq governors available in this kernel. If you wish to use a
CPUfreq governor that is not listed in this file, refer to 無CPUfreq 無無無無無無無無 for instructions on
how to do so.
• --affected-cpus — Lists CPUs that require frequency coordination software.
• --policy — Shows the range of the current CPUfreq policy, in KHz, and the currently active
governor.
• --hwlimits — Lists available frequencies for the CPU, in KHz.
For cpupower frequency-set, the following options are available:
• --min <freq> and --max <freq> — Set the policy limits of the CPU, in KHz.
重要
When setting policy limits, you should set --max before --min.
24
CPUモニター
• --freq <freq> — Set a specific clock speed for the CPU, in KHz. You can only set a speed
within the policy limits of the CPU (as per --min and --max).
• --governor <gov> — Set a new CPUfreq governor.
cpupowerの代替
If you do not have the kernel-tools package installed, CPUfreq settings can be viewed in the
tunables found in /sys/devices/system/cpu/[cpuid]/cpufreq/. Settings and values can be
changed by writing to these tunables. 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. CPUモニター
cpupower features a selection of monitors that provide idle and sleep state statistics and
frequency information and report on processor topology. Some monitors are processor-specific,
while others are compatible with any processor. Refer to the cpupower-monitor man page for
details on what each monitor measures and which systems they are compatible with.
cpupower monitorコマンドでは以下のオプションを使用します:
• -l — システムで利用可能なモニターの一覧を表示します。
• -m <monitor1>, <monitor2> — 指定したモニターを表示します。識別子は -l を使用して取得できま
す。
• command — 指定したコマンドのアイドル統計とCPU要求を表示します。
3.4. CPU 節電ポリシー
cpupower ではあなたのプロセッサーの節電ポリシーを設定できます。
cpupower setコマンドでは以下のオプションが使用可能です:
--perf-bias <0-15>
Allows software on supported Intel processors to more actively contribute to determining
the balance between optimum performance and saving power. This does not override other
power saving policies. Assigned values range from 0 to 15, where 0 is optimum performance
and 15 is optimum power efficiency.
デフォルトでは、このオプションはすべてのコアに対し適用されます。個々のコアに対し適用するには、--cpu
<cpulist>オプションを追加します。
--sched-mc <0|1|2>
Restricts the use of power by system processes to the cores in one CPU package before other
CPU packages are drawn from. 0 sets no restrictions, 1 initially employs only a single CPU
25
第3章コアインフラストラクチャとメカニクス
package, and 2 does this in addition to favouring semi-idle CPU packages for handling task
wakeups.
--sched-smt <0|1|2>
Restricts the use of power by system processes to the thread siblings of one CPU core before
drawing on other cores. 0 sets no restrictions, 1 initially employs only a single CPU package,
and 2 does this in addition to favouring semi-idle CPU packages for handling task wakeups.
3.5. 一時停止と再開
When a system is suspended, the kernel calls on drivers to store their states and then unloads
them. When the system is resumed, it reloads these drivers, which attempt to reprogram their
devices. The drivers' ability to accomplish this task determines whether the system can be
resumed successfully.
Video drivers are particularly problematic in this regard, because the Advanced Configuration and
Power Interface (ACPI) specification does not require system firmware to be able to reprogram
video hardware. Therefore, unless video drivers are able to program hardware from a completely
uninitialized state, they may prevent the system from resuming.
Fedora 17 includes greater support for new graphics chipsets, which ensures that suspend and
resume will work on a greater number of platforms.
3.6. ティックレス・カーネル
Previously, the Linux kernel periodically interrupted each CPU on a system at a predetermined
frequency — 100 Hz, 250 Hz, or 1000 Hz, depending on the platform. The kernel queried the
CPU about the processes that it was executing, and used the results for process accounting
and load balancing. Known as the timer tick, the kernel performed this interrupt regardless of
the power state of the CPU. Therefore, even an idle CPU was responding to up to 1000 of these
requests every second. On systems that implemented power saving measures for idle CPUs, the
timer tick prevented the CPU from remaining idle long enough for the system to benefit from
these power savings.
The kernel in Fedora 17 runs tickless: that is, it replaces the old periodic timer interrupts with ondemand interrupts. Therefore, idle CPUs are allowed to remain idle until a new task is queued for
processing, and CPUs that have entered lower power states can remain in these states longer.
3.7. Active-State Power Management
Active-State Power Management (ASPM) は接続相手のデバイスが使用中でない時には PCIe リンク用に
低い電力状態に設定することで Peripheral Component Interconnect Express (PCI Express 又は PCIe)
サブシステム内で電力を節約します。ASPM はリンクの両側で電力状態を制御して、リンク末端のデバイスが
最大電力状態にある場合でもリンク内で電力を節約します。
ASPM が有効になっていると、異なる電力状態間でのリンクを移転するのに必要な時間の為にデバイスレイテ
ンシ(遅延）は増加します。 ASPM は電力状態を決定するために以下のような３つのポリシーを持ちます:
デフォルト
システム上のファームウェア（例えば、BIOS）で指定されたデフォルトに従って、PCIe リンクの電力状態を
セットします。これが ASPM のデフォルト状態です。
電力節約（powersave）
パフォーマンスへの犠牲に関係無く、できる限り電力を節約するように ASPM をセットします。
26
Aggressive Link Power Management
パフォーマンス（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.8. Aggressive Link Power Management
Aggressive Link Power Management (ALPM)は、ディスクがアイドル状態の時(入出力がない時)にSATAリ
ンクを省電力に設定し、電力消費を抑える技術です。一度入出力要求があった場合には自動的にアクティブ
電力状態に戻します。
Power savings introduced by ALPM come at the expense of disk latency. As such, you should only
use ALPM if you expect the system to experience long periods of idle I/O time.
ALPMは Advanced Host Controller Interface (AHCI) を使用するSATAコントローラーのみで使用できま
す。AHCIについての詳細はhttp://www.intel.com/technology/serialata/ahci.htmを参照してください。
使用可能な場合、ALPMはデフォルトで有効です。ALPMには次の3つのモードがあります:
min_power
This mode sets the link to its lowest power state (SLUMBER) when there is no I/O on the disk.
This mode is useful for times when an extended period of idle time is expected.
medium_power
This mode sets the link to the second lowest power state (PARTIAL) when there is no I/O on the
disk. This mode is designed to allow transitions in link power states (for example during times of
intermittent heavy I/O and idle I/O) with as small impact on performance as possible.
medium_power mode allows the link to transition between PARTIAL and fully-powered (that is
"ACTIVE") states, depending on the load. Note that it is not possible to transition a link directly
from PARTIAL to SLUMBER and back; in this case, either power state cannot transition to the
other without transitioning through the ACTIVE state first.
max_performance
27
第3章コアインフラストラクチャとメカニクス
ALPMが無効であるとき、入出力がなくてもリンクはどの省電力状態にも変更されません。
SATAホストアダプターがALPMをサポートしているか確認するには、ファイル /sys/class/scsi_host/host*/
link_power_management_policyが存在するか確認します。設定を変更するには、このセクションで説明されて
いる値をファイルに書き込みます。現在の設定を確認するには、ファイルを表示します。
重要 — ホットプラグを無効にしてしまう設定
ALPMをmin_powerまたはmedium_powerに設定すると"ホットプラグ"機能は自動的に無効になります。
3.9. リアルタイム・ドライブ・アクセス最適化
The POSIX standard requires that operating systems maintain file system metadata that records
when each file was last accessed. This timestamp is called atime, and maintaining it requires a
constant series of write operations to storage. These writes keep storage devices and their links
busy and powered up. Since few applications make use of the atime data, this storage device
activity wastes power. Significantly, the write to storage would occur even if the file was not read
from storage, but from cache. For some time, the Linux kernel has supported a noatime option for
mount and would not write atime data to file systems mounted with this option. However, simply
turning off this feature is problematic because some applications rely on atime data and will fail if
it is not available.
The kernel used in Fedora 17 supports another alternative — relatime. Relatime maintains atime
data, but not for each time that a file is accessed. With this option enabled, atime data is written
to the disk only if the file has been modified since the atime data was last updated (mtime), or if
the file was last accessed more than a certain length of time ago (by default, one day).
既定ですべてのファイルシステムはrelatimeオプションが有効でマウントされています。特殊なファイルシステ
ムをマウントする場合は、norelatimeオプションを使用することでrelatimeを無効にできます。
3.10. パワーキャッピング（Power Capping）
Fedora 17 は、HP Dynamic Power Capping (DPC) や Intel Node Manager (NM) テクノロジーなど、最近
のハードウェアに内蔵されているパワーキャッピング（電力制限）機能をサポートします。このパワーキャッピング
により、管理者はサーバーによる電力消費を制限できるだけでなく、データセンターを設備増設などを効率的
に計画できるようになります。その理由は既存の電力供給における過剰負荷のリスクが随分と減少するためで
す。管理者は同じサーバー設置スペースの内により多くのサーバー群を配置でき、サーバーの電力消費が制
限された場合に、高負荷時の電力要求が利用可能電力上限を超過しないことを確信できます。
HP Dynamic Power Capping
Dynamic Power Capping は HP ProLiant と BladeSystem のサーバーで利用できる機能であり、システム
管理者がサーバーの、あるいはサーバーグループに対して消費電力のキャップ（上限）を設定できるようにする
ものです。キャップとは、現在の作業負荷に関係無く、サーバーが超過しない明確な消費電力の限度のことで
す。キャップはサーバーがその消費電力の限度に到達するまでは何も機能しません。上限に到達した時点で、
管理プロセッサーは CPU P-states とクロックスロットリング（clock throttling）を調節して電力消費を制限し
ます。
Dynamic Power Capping はオペレーティングシステムから独立して CPU の動作を個別に修正します
が、HP の integrated Lights-Out 2 (iLO2) ファームウェアは、オペレーティングシステムが管理プロセッサー
にアクセスできるようにするため、ユーザースペース内のアプリケーションは管理プロセッサーに対して動作状
28
Enhanced Graphics Power Management
態の問い合わせをすることができます。Fedora 17 で使用されているカーネルは HP iLO と iLO2 のファーム
ウェア用のドライバーを含んでおり、プログラムから /dev/hpilo/dXccbN を経由し、管理プロセッサーに問い
合わせができます。このカーネルには、パワーキャッピング機能をサポートするための hwmon sysfs インターフェ
イスの拡張と、sysfs インターフェイスを使用する ACPI 4.0 パワーメータ−用の hwmon ドライバーも含んでいま
す。これらの機能が一緒になってオペレーティングシステムとユーザースペースツールが、パワーキャップ用に
設定された値とシステムの現在の電力消費を読み取りを可能にしています。
HP Dynamic Power Capping についての詳細情報を知りたければ、 http://h20000.www2.hp.com/bc/
docs/support/SupportManual/c01549455/c01549455.pdf の中の HP Power Capping and HP Dynamic
Power Capping for ProLiant Servers をご参照ください。
Intel Node Manager
Intel Node Manager は、プロセッサーの状態の P-states と T-states を使用してシステムにパワーキャップ
を課して、CPU パフォーマンスを制限することで電力消費を抑えます。管理者が電力管理ポリシーを設定する
ことにより、例えば夜間や週末などのシステム負荷が低い時にシステムを少ない消費電力で動作できるように
設定ができます。
Intel Node Manager は、標準の ACPI 無Advanced Configuration and Power Interface無を通じて、OSPM
Operating System-directed configuration and Power Management を使用することで CPU のパフォー
マンスを調節します。Intel Node Manager が OSPM ドライバーに対して T-states への変更を要求を行う
と、OSPM ドライバーはその要求に相当する変更を P-states に行います。同様に Intel Node Manager が
OSPM ドライバーに対して P-states への変更を通知すると、ドライバーはそれに応じて T-states を変更しま
す。これらの変更は自動的に発生し、オペレーティングシステムの介入を必要としません。管理者は Intel DCM
Intel Data Center Manager ソフトウェアを使用して Intel Node Manager の設定と監視を行います。
Intel Node Manager についての詳細情報には、http://communities.intel.com/docs/DOC-4766 で見ること
ができる Node Manager — A Dynamic Approach To Managing Power In The Data Center を参照して下
さい。
3.11. Enhanced Graphics Power Management
Fedora 17 はいくつかの不要な消費を取り除くことによってグラフィックスとディスプレイデバイスの電力を節
減します。
LVDS 再クロッキング
Low-voltage differential signaling (LVDS) is a system for carrying electronic signals over copper
wire. One significant application of the system is to transmit pixel information to liquid crystal
display (LCD) screens in notebook computers. All displays have a refresh rate — the rate at
which they receive fresh data from a graphics controller and redraw the image on the screen.
Typically, the screen receives fresh data sixty times per second (a frequency of 60 Hz). When
a screen and a graphics controller are linked by LVDS, the LVDS system uses power on every
refresh cycle. When idle, the refresh rate of many LCD screens can be dropped to 30 Hz without
any noticeable effect (unlike cathode ray tube (CRT) monitors, where a decrease in refresh rate
produces a characteristic flicker). The driver for Intel graphics adapters built into the kernel used
in Fedora 17 performs this down-clocking automatically, and saves around 0.5 W when the screen
is idle.
メモリーの自己リフレッシュを有効にする
Synchronous dynamic random access memory (SDRAM) — グラフィックアダプタ内のビデオメモリー用に
使用されているこのメモリーは毎秒千回ものリチャージを受けて、個々のメモリーセルがその中のデータを維持
できるようにします。メモリーの内外へと移動するデータを管理するその主要機能の他に、メモリーコントローラ
29
第3章コアインフラストラクチャとメカニクス
は通常これらのリフレッシュサイクルを開始する役目を持っています。しかし、SDRAM はまた、低電圧無無無無無無
無無モードも持っています。このモードでは、メモリーは内部タイマーを使用してそれ自身のリフレッシュサイクル
を生成します。これにより、現在メモリーに保存されているデータを危険に晒すこと無くシステムがメモリーコン
トローラをシャットダウンできるようにします。Fedora 17 で使用されているカーネルはアイドル時に Intel グラ
フィックスアダプタ内でメモリーの自己リフレッシュを引き起こします。それが約 0.8 W だけ節電します。
GPU クロックの低減
標準的なグラフィカルプロセッシングユニット (GPU) には、その内部回路の各種パーツを制御する内部クロッ
クが含まれています。Fedora 17 で使用されているカーネルは、Intel 及び ATI の GPU 内の内部クロックの
一部の周波数を低減することができます。GPU コンポーネントが任意の時間内に実行するサイクル数を低減
すると、それらが実行する必要のなかったサイクルで消費されていたはずの電力を節減します。GPU のアイド
ル時にカーネルは自動的にそれらのクロックの速度を低減して、GPU の活動が増加するとそれを加速します。
GPU のクロックサイクルを低減することで最大約 5 W の節電ができます。
GPU power-down
Fedora 17 内の Intel と ATI グラフィックスドライバーは、アダプタにモニターが接続されていない状態を検
出できますので、GPU を完全にシャットダウンすることができます。この機能は、常時モニターを接続していない
サーバーに特に重要なポイントとなります。
3.12. RFKill
多くのコンピューターにはWi-Fi、Bluetooth、3Gデバイスを含む無線デバイスがついています。それらのデバイ
スは未使用時に無駄な電力を消費してしまいます。
RFKill is a subsystem in the Linux kernel that provides an interface through which radio
transmitters in a computer system can be queried, activated, and deactivated. When transmitters
are deactivated, they can be placed in a state where software can reactive them (a soft block) or
where software cannot reactive them (a hard block).
The RFKill core provides the application programming interface (API) for the subsystem. Kernel
drivers that have been designed to support RFkill use this API to register with the kernel, and
include methods for enabling and disabling the device. Additionally, the RFKill core provides
notifications that user applications can interpret and ways for user applications to query
transmitter states.
The RFKill interface is located at /dev/rfkill, which contains the current state of all radio
transmitters on the system. Each device has its current RFKill state registered in sysfs.
Additionally, RFKill issues uevents for each change of state in an RFKill-enabled device.
Rfkill is a command-line tool with which you can query and change RFKill-enabled devices on the
system. To obtain the tool, install the rfkill package.
Use the command rfkill list to obtain a list of devices, each of which has an index number
associated with it, starting at 0. You can use this index number to tell rfkill to block or unblock a
device, for example:
rfkill block 0
blocks the first RFKill-enabled device on the system.
You can also use rfkill to block certain categories of devices, or all RFKill-enabled devices. For
example:
30
ユーザースペースの最適化
rfkill block wifi
システムのすべてのWi-Fiデバイスをブロックします。RFKillが有効なデバイスすべてをブロックするには、次を
実行します:
rfkill block all
デバイスのブロックを解除するには、 rfkill block の代わりにrfkill unblockを実行します。rfkillがブロック
することができるすべてのデバイスのカテゴリを取得するには、rfkill helpを実行します。
3.13. ユーザースペースの最適化
システムハードウェアで実行される処理を低減させることが節電における基本と言えます。そのため、3無無無無無無
無無無無無無無無無無無無無に説明してある変更はシステムが色々な低電力消費の状態で運用されるようにしますが、シ
ステムハードウェアから不要な処理を要求するユーザースペース内のアプリケーションは、ハードウェアがこれ
らの節電状態に入ることを妨げます。Fedora 17 は開発段階で、ハードウェア上の不要な処理を削減すべく以
下の分野で監査を行いました。
ウェイクアップ（wakeups）の削減
Fedora 17 uses a tickless kernel (refer to 無無無無無無無無無無無無無), which allows the CPUs to remain
in deeper idle states longer. However, the timer tick is not the only source of excessive CPU
wakeups, and function calls from applications can also prevent the CPU from entering or
remaining in idle states.
ストレージとネットワークの I/O の削減
ストレージデバイスとネットワークインターフェイスへの入出力（I/O）はデバイスの電力消費を強要します。アイ
ドル時に節電状態になる機能（例えば、ALPM や ASPM）を持つストレージデバイスとネットワークインタフェー
スで、この無駄なトラフィックはデバイスがアイドル状態に入ったり、アイドル状態を維持することを阻止する可
能性があります。ハードディスクを使用していない時にプラッタ（円盤）の回転減少することを阻止してしまう可
能性があります。ストレージデバイスに対する不要な処理は、数種のアプリケーションで最低限に抑制されまし
た。ハードディスクの回転数減少を邪魔する処理は特に抑制されています。
Initscript の監査
要求に関係無く、自動的に開始するサービスは、いくつかのリソースを無駄にする可能性が多分にありま
す。それに対して可能な限りサービスがデフォルトで「オフ」や「オンデマンド」になるようにすべきです。例え
ば、Bluetooth 機能を提供する BlueZ サービスは以前はシステム上に Bluetooth 機能がなくても、システム
を開始する時に自動的に開始されていました。 BlueZ initscript は今では、サービスを開始する前にシステム
上に Bluetooth ハードウェアが存在することをチェックします。
31
32
使用ケース
この章では、２つの使用ケースを例に出してこのガイド内で説明してある分析と設定の方法を描写しています。
最初の例では、標準的なサーバーを考慮し、２つ目の例では標準的なラップトップを考慮しています。
4.1. 例 — サーバー
最近の一般的な標準のサーバーは、Fedora 17 でサポートされている必要なハードウェアが全て組み込まれ
ています。最初に考慮すべき事は、サーバーの主要な使用目的となるワークロードの種類です。この情報に基
づいて省電力のために最適化されるべきコンポーネントを決定できます。
サーバーのタイプに関係無く、グラフィックスのパフォーマンスは一般に必要ありません。そのため、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 を使用できるはずで
す。
33
第4章使用ケース
ディレクトリサーバー
ディレクトリサーバーは一般的に、低いディスク I/O 要求を持ちます。特に十分な RAM がある場合はそうで
す。ネットワーク遅延は重要ですが、ネットワーク I/O はそれほどでもありません。ユーザーはより低いリンクス
ピードで遅延ネットワークチューンを考慮するかも知れませんが、特定の使用中ネットワーク用に注意深くこれ
をテストする必要があります。
4.2. 例 — ラップトップ
電力管理と節電が本当の効果を生むもう１つの非常に一般的な対象はラップトップです。設計的に元々、ラップ
トップはワークステーションやサーバーよりも劇的に低レベルのエネルギーを使用するタイプであるため、絶対
的な節電の可能性は他のマシンよりも小さいものです。しかしバッテリモードの状態では、少しの節電でもラッ
プトップのバッテリ寿命を数分でも延長する助けになります。このセクションでは、ラップトップのバッテリモード
使用に焦点を置いていますが、AC 電源の使用状態でもこれらのチューニングの一部、又は全てを活かすこと
ができます。
単独のコンポーネントに対する節電は通常、ワークステーションで見られるよりも比較的に大きな相違をラップ
トップで認識できます。例えば、100 Mbits/s で実行している 1 Gbit/s ネットワークインターフェイスはおよそ
3–4 ワット節約します。約 400 ワットの合計電力消費を持つ標準的なサーバーにはこの節約はおよそ 1 %
です。約 40 ワットの合計電力消費を持つラップトップ上では、この１つのコンポーネント上の節電が合計およ
そ 10 % になります。
標準的なラップトップ上での特定の節電最適化には以下が含まれます:
• Configure the system BIOS to disable all hardware that you do not use. For example, parallel
or serial ports, card readers, webcams, Wi-Fi, and Bluetooth just to name a few possible
candidates.
• Dim the display in darker environments where you do not need full illumination to read the
screen comfortably. On the GNOME desktop, use Applications+System Tools → System
Settings, then select Hardware → Power. On the KDE desktop, use Kickoff Application
Launcher+Computer+System Settings+Advanced → Power Management. Alternatively, enter
gnome-power-manager or xbacklight at the command line or use the function keys on your
laptop.
• tuned-adm のラップトップバッテリ節電（laptop-battery-powersave）プロフィールを使用して節
電メカニズムのセットを有効化。ハードドライブとネットワークインターフェイスのパフォーマンスと遅延が影響
を受けることに注意して下さい。
追加として（代替として）各種システム設定に小調節を実行することもできます:
• ondemand governor を使用（Fedora 17 ではデフォルトで有効）
• ラップトップモードを有効化（laptop-battery-powersave プロフィールの一部）:
echo 5 > /proc/sys/vm/laptop_mode
• ディスクへのフラッシュ時間を増加（laptop-battery-powersave プロフィールの一部）:
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
• nmi watchdog を無効化（laptop-battery-powersave プロフィールの一部）:
echo 0 > /proc/sys/kernel/nmi_watchdog
34
例 — ラップトップ
• AC97 オーディオ節電機能を有効化（Fedora 17 ではデフォルトで有効）:
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
USB 自動サスペンドは全ての USB デバイスで正常に機能するわけではない事に注意して下さい。
• ALPM 用の最低電力設定を有効化（laptop-battery-powersave プロフィールの一部）:
echo min_power > /sys/class/scsi_host/host*/link_power_management_policy
• relatime を使用してファイルシステムをマウント（Fedora 17 ではデフォルト）:
mount -o remount,relatime mountpoint
• ハードドライブ用に最善の節電モードをアクティベート（laptop-battery-powersave プロフィールの一部）:
hdparm -B 1 -S 200 /dev/sd*
• 画面の輝度を 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
• 有線ネットワークを 100 Mbit/s に限定（laptop-battery-powersave プロフィールの一部）:
ethtool -s eth0 advertise 0x0F
35
36
付録A 開発者へのヒント
全ての良いプログラミング教本はメモリー割り当ての問題と特定機能のパフォーマンスを言及しています。自分
自身のソフトウェアを開発する時、そのソフトウェアが稼働するシステムで電力消費が増加する可能性の問題
に注意して下さい。これらの配慮はコードの全ての行に影響するものではありませんが、頻繁にパフォーマンス
のボトルネックになるエリアではコードを最適化する必要があるでしょう。
頻繁に問題を起こす技術には以下が含まれます:
• スレッドの使用
• 不必要な CPU の目覚めと目覚めを効率良く使用しない状態。目を覚ます必要がある場合は、全てを一度
に（race to idle と呼ぶ）、出来るだけ迅速に実行します。
• [f]sync() を不必要に使用
• 不必要なアクティブポーリング、又は短い通常のタイムアウトの使用。（代わりにイベントに反応）
• 目覚めを効率的に使用していない。
• 低効率のディスクアクセス。頻繁なディスクアクセスを回避するために大きめのバッファを使用して下さい。一
度に大きなブロックを書き込むことです。
• 低効率のタイマーの使用。可能な限りアプリケーション群（又はシステム群）に渡ってタイマーをグループ化
する方がいいでしょう。
• 過度の I/O、電力消費、又はメモリー使用（メモリーリークを含む）
• 不必要な演算の実行。
以下のセクションでは、これらの分野をもっと詳しく検証していきます。
A.1. スレッドを使用
スレッドの使用はアプリケーションのパフォーマンスをより良くより速くすると広く信じられていますが、これは全
てのケースではありません。
Python
1
Python は Global Lock Interpreter を使用しますので、スレッディングは大規模な I/O 運用でのみ効果的
2
になります。 Unladen-swallow は Python のより迅速な実装ですからこれによってコードを最適化できる
可能性があります。
Perl
Perl のスレッドは、本来フォーキングの無いシステム（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-lock
http://code.google.com/p/unladen-swallow/
3
http://www.perlmonks.org/?node_id=288022
2
37
付録A 開発者へのヒント
C
C のスレッドは同じメモリーを共有します。各スレッドはそれ自身のスタックを持ち、カーネルは新規のファイル
記述子を作成したり、新しいメモリースペースの割り当てをする必要がありません。C はより多くのスレッドの
ためにより多くの CPU のサポートを本当に活用できます。そのため、スレッドのパフォーマンスを最大にするに
は、C か C++ などの低レベルの言語を使用すべきです。スクリプティング言語を使用している場合は、C バイ
ンディングを考慮して下さい。プロファイラを使用すると、コード内の貧弱なパフォーマンス部分を識別できます。
4
A.2. Wake-ups（目覚め）
多くのアプリケーションが変更を確認するのに設定ファイルをスキャンします。多くのケースでは、このスキャンは
例えば、毎分などと決まった間隔で実行されます。スキャンはスローダウンしているディスクを強制的に目覚さ
せるため、これが問題になります。最善の策は適切なチェック間隔や、適切なチェックメカニズムを見つけるか、
又は inotify で変更をチェックして、イベントに対応することです。 inotify はファイルやディレクトリ上で多様な
変更をチェックできます。
例えば:
#include
#include
#include
#include
#include
#include
<stdio.h>
<stdlib.h>
<sys/time.h>
<sys/types.h>
<sys/inotify.h>
<unistd.h>
int main(int argc, char *argv[]) {
int fd;
int wd;
int retval;
struct timeval tv;
fd = inotify_init();
/* checking modification of a file - writing into */
wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY);
if (wd < 0) {
printf("inotify cannot be used\n");
/* switch back to previous checking */
}
fd_set rfds;
FD_ZERO(&rfds);
FD_SET(fd, &rfds);
tv.tv_sec = 5;
tv.tv_usec = 0;
retval = select(fd + 1, &rfds, NULL, NULL, &tv);
if (retval == -1)
perror("select()");
else if (retval) {
printf("file was modified\n");
}
else
printf("timeout\n");
return EXIT_SUCCESS;
}
4
http://people.redhat.com/drepper/lt2009.pdf
38
Fsync
このアプローチの優越性は実行できるチェックの多様性にあります。
主となる制限は、１つのシステムでは利用できる監視の数が限定されていることです。この数は /proc/sys/fs/
inotify/max_user_watches から取得できます。変更は可能ですがそれは推薦できません。更には、 inotify
に障害がある場合、コードは異なるチェック手段に戻る必要がありますが、これは通常ソースコード内の #if
#define の多発を意味します。
inotify についての詳細情報には、inotify man ページを参照して下さい。
A.3. Fsync
Fsync is known as an I/O expensive operation, but this is is not completely true.
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. ./myconfig */
fd = open("./myconfig", O_RDONLY);
read(fd, myconfig_buf, sizeof(myconfig_buf));
close(fd);
...
fd = open("./myconfig", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR);
write(fd, myconfig_buf, sizeof(myconfig_buf));
close(fd);
より良いアプローチは多分:
/* open and read configuration file e.g. ./myconfig */
fd = open("./myconfig", O_RDONLY);
read(fd, myconfig_buf, sizeof(myconfig_buf));
close(fd);
...
fd = open("./myconfig.suffix", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR
write(fd, myconfig_buf, sizeof(myconfig_buf));
fsync(fd); /* paranoia - optional */
...
close(fd);
rename("./myconfig", "./myconfig~"); /* paranoia - optional */
rename("./myconfig.suffix", "./myconfig");
39
40
付録B 改訂履歴
改訂 1.0-1
Wed May 02 2012
Reed Jack [FAMILY Given]
[email protected]
Updates for Fedora 17
41
42

Download Report