電力管理ガイド - Fedora Documentation

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 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 14 システムで効果的に電力消費を管理する方法を説明しています。以下のセク
ションでは電力消費を低減する異なる技術（サーバーとラップトップの両方）と、各技術がシステムの全体的な
パフォーマンスにいかに影響するかを説明します。なお、このドキュメントはまだ開発中であり、大幅に変更され
る可能性があります。そのため現時点でプレビューとして提供されています。本文中にある内容と指導事項はま
だ完全でなく、注意して取り扱う必要があります。
ドラフト
序文
ドラフト
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 ......................................................................................................... 11
2.5.1. tuned.conf ファイル ......................................................................................... 12
2.5.2. Tuned-adm .................................................................................................... 14
2.6. UPower .................................................................................................................... 16
2.7. GNOME Power Manager .......................................................................................... 17
2.8. 監査用の他の手段 ...................................................................................................... 17
3. コアインフラストラクチャとメカニクス
3.1. CPU のアイドル状態 ....................................................................................................
3.2. CPUfreq Governors の使用 .........................................................................................
3.2.1. CPUfreq Governor のタイプ ............................................................................
3.2.2. CPUfreq のセットアップ ....................................................................................
3.2.3. CPUfreq のポリシーと速度のチューニング ...........................................................
3.3. サスペンドとレジューム .................................................................................................
3.4. Tickless カーネル .......................................................................................................
3.5. Active-State Power Management ..............................................................................
3.6. Aggressive Link Power Management .........................................................................
3.7. Relatime ディスクアクセスの最適化 ..............................................................................
3.8. パワーキャッピング（Power Capping） ............................................................................
3.9. Enhanced Graphics Power Management ..................................................................
3.10. RFKill ......................................................................................................................
3.11. ユーザースペースの最適化 .........................................................................................
19
19
19
20
21
22
23
23
24
24
25
26
27
28
28
4. 使用ケース
31
4.1. 例 — サーバー ........................................................................................................... 31
4.2. 例 — ラップトップ ........................................................................................................ 32
A. 開発者へのヒント
A.1. スレッドを使用 .............................................................................................................
A.2. Wake-ups（目覚め） ....................................................................................................
A.3. Fsync ........................................................................................................................
35
35
36
37
B. 改訂履歴
39
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 14 が稼働するシステムでの電力管理について説明しています。
1.1. 電力管理の重要性
電力管理の中核には、各システムコンポーネントの電力消費をいかに効果的に最適化すべきかの理解があり
ます。これにはシステムが実行する異なるタスクの研究を必要とします。そして各コンポーネントを設定してその
仕事に対してパフォーマンスが適切であることを確実にしなければなりません。
電力管理の主な理由には次のようなものがあります。
• コスト節約のための全体的な消費電力の削減
電力管理の正しい活用は以下の結果を生みます:
• サーバーとデータセンターの熱削減
• 冷却、空間、ケーブル、発電機、および UPS (無無無無無無無) を含む二次コストの削減
• ノート PC のバッテリー寿命の延長
• CO2排出量の低減
• グリーン IT に関して政府の規則、または法的要請に適合すること。例えば、Energy Starなど
• 新システムにおける企業のガイドラインに適合すること
原則としては、特定コンポーネント（またはシステム全体）の消費電力を低減することは、発生熱の低下になり、
そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低下を、
特にミッションクリティカルなシステムに於いて研究してテストするべきです。
システムが実行する諸々のタスクを研究して、ジョブに対してパフォーマンスがちょうど十分であるように各コ
ンポーネントを設定することで、エネルギーを節約し、発熱を減らし、そしてラップトップのバッテリ寿命を最適
化することができます。電力消費に関するシステムの分析とチューニングの為の原則の多くはパフォーマンス
チューニングの原則と良く似ています。システムは通常、パフォーマンスか電力に向けて最適化してあるため、あ
る程度は電力管理とパフォーマンスチューニングはシステム設定に於いて対立するアプローチを取ります。本ド
キュメントでは、 Fedora Project が提供するツールとこのプロセスでユーザーを支援するために弊社が開発し
てきた技術を説明しています。
Fedora 14 は多くの新しい電力管理機能を搭載しており、デフォルトで有効になっています。これらはすべて、
標準的なサーバーまたはデスクトップ使用のパフォーマンスに影響を与えないように配慮されています。しか
し、特殊な利用ケースで最大のスループット、最小の遅延、また最高の CPU パフォーマンスが絶対的に要求さ
れる状態では、これらのデフォルト設定の見直しが必要でしょう。
本ドキュメントで説明してある技術を使用してマシンを最適化すべきかどうかの判断には、以下のような自問を
して見てください:
問：
電力を最適化すべきですか？
答：
電力最適化の重要性は、企業が追従すべきガイドラインを持っているかどうか、または達成すべき基準が
あるかどうかによって変化します。
1
第1章概説
ドラフト
問：
どれくらい最適化する必要がありますか ?
答：
ここで紹介してある技術のいくつかは、マシンの詳細に渡る監査と分析の全プロセスを実践することを要
求しません。しかし、その代わりに標準的な電力使用を普通に最適化できる方法のセットを提供します。こ
れらの方法はもちろん手動のシステム監査と最適化ほど良くはありませんが、十分な妥当性を提供しま
す。
問：
最適化はシステムパフォーマンスを容認できないレベルまで下げますか ?
答：
このドキュメント内に説明してあるほとんどの技術は使用システムに認識できるほどの影響を与えま
す。Fedora 14 内にすでに設定されてあるデフォルト値を超過するような電力管理の実装を選択した場
合、電力最適化を実行した後のシステムパフォーマンスを監視して、パフォーマンス損失が容認できるか
どうかを判断する必要があります。
問：
最適化に時間やリソースを費した場合、そこから得られる結果より負担の方が大きくなってしまいます
か？
答：
1台のシステムを全プロセスにしたがい手作業で最適化を行っても、その時間やリソースはマシンの寿命
が尽きるまでに得られるであろう利便性をはるかに上回ってしまうため意味がありません。一方、 1 万台
のデスクトップシステムが複数のオフィスに分散しているが構成および設定は同じものを使用している場
合なら、最適化した設定をひとつ構成してそれを 1 万台すべてのマシンに適用していけば十分に役立つ
可能性が高くなります。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシ
ステムに効果を与えるかを説明しています。
1.2. 電力管理の基礎
効率的な電力管理は以下のような原則の上に確立されています:
アイドル状態の CPU は必要な時にだけ活動すべきである
Fedora のカーネルは各 CPU に対して定期的なタイマーを使用していました。このタイマーは、プロセスが実
行中であるかどうかに関係なく、毎回のタイマーイベント（セッティングにより数ミリ秒毎に発生）で CPU がプロ
セスすることを要求するため、CPU が本当にアイドル状態に入ることを妨げていました。効率的な電力管理の
大部分は CPU が目覚める頻度を低減することに関連します。
この理由で、Fedora 14 内の Linux カーネルは定期的なタイマーを取り除いています。その結果、CPU のア
イドル状態は無無無無無無無tickless無です。これが、CPU のアイドル時には CPU が不要な電力消費を防止します。
しかし、システムが不要なタイマーイベントを作り出すアプリケーションを持っている場合にはこの機能からの利
便性は、オフセットされてしまいます。ポーリングイベント（音量の変更、マウス動作、その他をチェックするもの）
はそのようなイベントの例になります。
Fedora 14 には、CPU 使用率を基にしたアプリケーションの識別と監査をできるツールが含まれています。そ
の詳細には、2無無無無無無無無無無無を参照して下さい。
使用していないハードウェアとデバイスは完全に無効にすべきである
稼働部品を持つデバイス（例えば、ハードディスク）には特に分かりやすい例でしょう。これに加えて、一部のア
プリケーションは使用中でなくても有効なデバイスを「オープン」状態で維持するものがあります。これが発生す
ると、カーネルはデバイスは「使用中」だと想定してデバイスが節電状態に入ることを妨げてしまいます。
2
ドラフト
電力管理の基礎
低活動は低ワット数と解釈すべきである
しかし多くのケースでは、この事は最新のハードウェアと正しい 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 で提供されている仮想化技術を使用してサーバーを仮想化をすることもできます。
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
Fedora でのティックレスカーネル (無Tickless 無無無無無を参照) の導入により、CPU がもっと高い頻度でア
イドル状態に入るようになりました。これにより消費電力を低減し電力管理を向上しています。この新しい
PowerTOP ツールはカーネルと、CPU を頻繁に目ざますユーザーアプリケーションの特定コンポーネントを識
別します。PowerTOP は、無無無無無無無無無無無無無無に説明してある監査を実行するために開発部門で使用されて
いました。それがこのリリースに於いて多くのアプリケーションがチューンされる結果となり、不要な CPU の目
覚めを約 10分の１に低減したのです。
以下のコマンドを使用して PowerTOP をインストールします:
yum install powertop
以下のコマンドを使用して PowerTOP を実行します:
powertop
PowerTOP を実行するには、root 権限を使用してアプリケーションが役立つ作業をするようにしなければなり
ません。
実行すると、PowerTOP はシステムから統計を収集して CPU に最も頻繁に起こす（ウェイクアップ）を送
信しているコンポーネントの一覧をユーザーに提示します。PowerTOP はまた、省電力のためにシステムの
5
第2章電力管理の監査と分析
ドラフト
チューニング方法も提案します。これらの提案は画面の底辺に表示され、そして 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 that
send wakeups to the CPU most frequently. At the top of the list are those components that you
should investigate more closely to optimize your system to reduce power usage. If they are kernel
components, (indicated by the name of the component being listed in <>) then the wakeups are
often associated with a specific driver that causes them. Tuning drivers most usually requires
kernel changes which go beyond the scope of this document. However, userland processes that
send wakeups are more easily managed. First, identify if this service or application should run at
all 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 VM
dirty writeback time とその提案を適用するために押すキー (W) に注目して下さい。これらの変更は恒久的
ではなく次の再起動までしか有効でありません。この変更の恒久的に維持する手助けのために PowerTOP は
その最適化を実践するために実行する精確なコマンドを表示します。このコマンドを好みのテキストエディタで
/etc/rc.local ファイルなどに追記して、現在ご利用のコンピュータが起動する度にこの変更が反映されるよ
うにします。
6
ドラフト
Diskdevstat と netdevstat
図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
あるいは、コマンド:
7
第2章電力管理の監査と分析
ドラフト
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
READ_CNT
READ_MIN
READ_MAX
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
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
0
0.000
0.000
0.000
16
0.000
0.000
0.000 cat
15575
8
0 sda1
WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG
READ_AVG COMMAND
ドラフト
Diskdevstat と netdevstat
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
連続した２回の書き込みに要した最短の時間 (秒)
WRITE_MAX
連続した２回の書き込みに要した最長の時間 (秒)
WRITE_AVG
連続した２回の書き込みに要した平均時間 (秒)
READ_CNT
読み込み操作の全回数
READ_MIN
連続した２回の読み込みに要した最短時間 (秒)
READ_MAX
連続した２回の読み込みに要した最長時間 (秒)
9
第2章電力管理の監査と分析
ドラフト
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 、または他の監査用や、解析用ツールと一緒に実行すると、ユーザーが実
行する最適化はマシンがアイドル時ではなく、活発に使用されている時に効果を持つかどうかをテストできるよ
うになります。異なる設定を評価したい場合、全く同一のワークロードを複数回にわたり実行できるため、その
結果を異なる設定を比較することができます。
以下のコマンドを使用して BLTK をインストールします:
yum install bltk
以下のコマンドで BLTK を実行します:
bltk workload options
例えば、idle のワークロードを 120 秒間実行するには:
bltk -I -T 120
10
ドラフト
Tuned と ktune
デフォルトで使用できるワークロードは次の通りです:
-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 オプションを使用します:
bltk_report -o path_to_results_directory
2.5. Tuned と ktune
Tuned はシステムコンポーネントの使用を監視して、その監視情報を基にして動的にシステムセッティングを
チューンするデーモンです。動的なチューニングは、任意のシステム用のアップタイム期間を通じて各種システ
ムコンポーネントが異なる方法で使用される決定要素となります。例えば、ハードドライブは起動時とログイン
時に重労働となります。しかし、その後、ユーザーが主に OpenOffice や電子メールクライアントのようなアプ
リケーションで作業をする時には稀にしか使用されません。同様に CPU とネットワークデバイスは異なる時期
に異なる使い方を受けます。Tuned はこれらのコンポーネントの活動を監視して、それらの使用への変化に対
応します。
11
第2章電力管理の監査と分析
ドラフト
実際的な例として、オフィスにある標準的なワークステーションを考慮してみましょう。ほとんどの時間帯でイー
サネットカードのインターフェイスは頻繁に通信は行っていないでしょう。数件の電子メールが時々届くか、また
はウェブページをいくつか開くぐらいでしょう。このようなの負荷にはイーサーネットカードはデフォルト設定のよ
うにいつも最高速度で動作する必要はありません。 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 オプションを付けて開始することにより異なる名前と
場所を指定することができます。
12
ドラフト
tuned.conf ファイル
設定ファイルは常に、tuned の一般的なパラメータを定義する [main] セクションを含んでいなければなりま
せん。そうするとファイルは各プラグイン用にセクションを含みます。
[main] セクションは以下のオプションを含みます:
interval
tuned がシステムを監視してチューンすべき間隔を秒で表示します。デフォルト値は 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=10
pidfile=/var/run/tuned.pid
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]
13
第2章電力管理の監査と分析
ドラフト
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
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 は以下のような
事前定義のプロファイルも収納しています:
14
ドラフト
Tuned-adm
default
デフォルトの節電プロファイルです。利用可能なプロファイルの中で電力節減に最も少ないインパクトを与
え、 tuned の CPU とディスクのプラグインのみを有効にします。
desktop-powersave
デスクトップシステム対応の節電プロファイルです。SATA ホストアダプタ用の ALPM 節電 (無Aggressive
Link Power Management無参照) と更には、 tuned の CPU、イーサネット、及びディスクのプラグインを
有効にします。
server-powersave
サーバーシステム対応の節電プロファイルです。SATA ホストアダプタ用の ALPM 節電を有効にして、HAL
を介して CD-ROM ポーリングを無効にします (hal-disable-polling man ページ参照)。そして、tuned
の CPU とディスクのプラグインをアクティベートします。
laptop-ac-powersave
AC 電源で稼働中のラップトップ対応の中レベルインパクトの節電プロファイルです。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.conf
tuned サービスがこのプロファイル用にアクティブになる設定
sysctl.ktune
ktune で使用される sysctl セッティングです。この形式は /etc/sysconfig/sysctl ファイルの形式と同じ
です (sysctl 及び sysctl.conf man ページを参照)。
ktune.sysconfig
ktune 自身の設定ファイルは、標準的に /etc/sysconfig/ktune です。
ktune.sh
ktune サービスで使用される init スタイルのシェルスクリプトです。これはシステムのチューンのために特
定のコマンドをシステム起動時に実行できます。
15
第2章電力管理の監査と分析
ドラフト
新しいプロファイルを開始する最も簡単な方法は既存のものをコピーすることです。laptop-batterypowersave プロファイルには、既にとても豊富なチューニングが含まれているため、便利な開始点となります。
単に全ディレクトリを以下のように新しいプロファイル名にコピーします:
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. UPower
Fedora 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
16
ドラフト
GNOME Power Manager
2.7. GNOME Power Manager
GNOME Power Manager は、GNOME デスクトップの一部としてインストールされているデーモンです。
Fedora の以前のバージョンで提供されていた GNOME Power Manager の電力管理機能の大部分は
Fedora 13 の DeviceKit-power の構成要素となりました (無UPower無参照) 。しかし、GNOME Power
Manager はその機能のフロントエンドとして残ります。システムトレイ上のアプレットを介して GNOME Power
Manager は、バッテリから AC 電源への切り替えなどのシステムの電源状態の変化を通知します。また、バッ
テリの状態を報告するとともに、バッテリー電力が低下した時点に警告を出します。
また、GNOME Power Manager により基本的な電力管理のセッティングが設定できるようになります。これら
のセッティングにアクセスするには、システムトレイ内の GNOME Power Manager アイコンをクリックして、そ
こで Preferences（個人設定）をクリックします。
Power Management Preferences（電力管理の個人設定）画面には３つのタブがあります:
• AC 電源使用時
• バッテリー使用時
• 全般
AC 電源使用時タブとバッテリー使用時タブを使用して、それぞれ活動停止時にディスプレイがオフになるま
での経過時間、活動停止時にスリープになるまでの経過時間、及び活動停止時にハードディスクの回転を落
とすかどうかを指定します。バッテリー使用時タブでは、ディスプレイの輝度の設定、及び危険なほどのバッテ
リー低下時での動作の選択が可能になります。例えば、GNOME Power Manager は、バッテリーが危険な低
レベルに到達するとシステムにハイバネートさせます。全般タブを使用して、システム上の（物理的）電源ボタ
ンとサスペンドボタンの動作をセットできると共に、 GNOME Power Manager アイコンがシステムトレイに出
現すべき状態を指定できます。
2.8. 監査用の他の手段
Fedora 14 はシステムの監査と分析を実行するためのツールを他にもいくつか提供します。それらのほとんど
は既に発見している事項に対して立証したり、特定の部分に於いてより詳しい情報が必要な場合に補助ソース
として使用できるものです。これらのツールの多くはパフォーマンスチューンにも使用されます。それは以下のよ
うになります:
vmstat
vmstat はプロセス、メモリー、ページング、ブロック I/O、トラップ、及び CPU の活動について詳細情報を
提供します。システム全体で実行している動作や多忙な部分を詳しく見るために使用します。
iostat
iostat は vmstat と似ていますが、ブロックデバイスの I/O 専用です。また、詳細な出力と統計を提供しま
す。
blktrace
blktrace は非常に詳細に渡るブロック I/O のトレースプログラムです。情報をアプリケーションに関連した
単独のブロックに分割します。diskdevstat と一緒に使用すると大変役に立つものです。
17
18
ドラフト
ドラフト
コアインフラストラクチャとメカニクス
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 に適している作
業負荷の種類について説明しています。
電力管理に関する主な懸念は以下のようになります:
• サーバーの熱削減
• ラップトップ用のバッテリー寿命の延長
19
第3章コアインフラストラクチャとメカニクス
ドラフト
原則としては、特定コンポーネント（又はシステム全体として）の消費電力を低減することは、発生熱の低下に
なり、そして必然的にパフォーマンスも低下します。そのため、実践する設定により出現するパフォーマンスの低
下を、特にミッションクリティカルなシステムに於いて研究してテストするべきです。
以下のセクションでは、エネルギー消費に関していかに最適化したハードウェアパフォーマンスがご使用中のシ
ステムに効果を与えるかを説明しています。
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 よりも多くの電力を消費します。そのため、低活動が予期できる時には powersave
governor を使用するように CPU を設定することが推奨されますが、この間に予期しない高負荷が発生すると
システムが実際には通常より多くの電力を消費する原因になります。
powersave governor は簡単な表現をすると、CPU にとっては節電よりも速度制限の意味を持ちます。これ
は、発熱が問題となるようなシステムや設置環境で最も役に立つ選択肢です。
cpufreq_ondemand
ondemand governor は動的に変化する governor です。これは負荷が高い時には最高のクロック周波数を
達成して、システムがアイドルの時には最低のクロック周波数を達成するように CPU を変化させます。これに
よりシステムはシステム負荷に応じて電力消費を調節可能にしますが、その犠牲として無無無無無無無無無無を招きま
す。そのため遅延は、システムがアイドルと高負荷の間で頻繁に転換を繰り返すとオンデマンドで提供される
パフォーマンスと節電効果を相殺してしまいます。
ほとんどのシステム上では、ondemand governor は発生熱、消費電力、パフォーマンス、及び管理法の間で
最良の妥協を提供します。システムが１日の内で特定の時間帯にのみ多忙になる状態では、オンデマンドはそ
れ以上の介入を必要とせずに負荷に応じて最高と最低の周波数の間で自動的に転換します。
cpufreq_userspace
userspace governor はユーザースペースプログラム（または root で実行している他のプロセス）が周波
数をセットできるようにします。この governor は通常、cpuspeed デーモンと共同で使用されます。全ての
governor の内、 userspace governor は最もカスタマイズ可能なタイプであり、その設定によってはシステム
にパフォーマンスと電力消費の最良のバランスを提供できます。
20
ドラフト
CPUfreq のセットアップ
cpufreq_conservative
ondemand governor のように、conservative governor も使用状態に応じてクロック周波数を調節します
（ondemand governor と同様）。しかし、ondemand governor がより攻撃的な手法で最高と最低との周波
数転換を達成するのに対して、conservative governor はもっとゆっくりと周波数間の転換をします。
これが意味することは、conservative governor は単に最高と最低の周波数を選択することではなく、負荷に
対して適切と判断するクロック周波数に調整すると言うことです。これは電力消費に関して価値のある節約を提
供する可能性を持ちますが、ondemand governor よりも無無無無無がその代償となります。
注記
cron ジョブを使用して governor を有効にすることができます。これにより、１日の特定の時間帯に特定の
governor を自動的にセットすることが可能になります。そのため、アイドル時（例えば、終業後）には低周
波数の governor を指定して、高負荷となる時間帯には高周波数に戻ることが出来ます。
特定の governor を有効にする方法についての案内には、無CPUfreq 無無無無無無無無内の無無3.2無CPUfreq
Governor 無無無無無無無を参照して下さい。
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 のクロック周波数と共に電圧も低減しますので、パ
フォーマンスの低減レベル毎に少ない電力消費と低発熱を可能にします。
21
第3章コアインフラストラクチャとメカニクス
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 different
governor, simply use echo [governor] > /sys/devices/system/cpu/[cpu ID]/cpufreq/
scaling_governor (refer to 無無3.2無CPUfreq Governor 無無無無無無無 in 無CPUfreq 無無無無無無無無 for more
information).
22
ドラフト
サスペンドとレジューム
•
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 Power
Interface) 仕様がシステムファームウェアのビデオハードウェアに対する再プログラム化能力を要求していない
からです。そのため、ビデオドライバーがハードウェアを完全な未初期化状態からプログラム化できない限りは、
それがシステムの復帰を阻止してしまいます。
Fedora 14 には、新しいグラフィックチップセット用のより強力なサポートが含まれています。これにより、サス
ペンドとレジュームは以前より多くのプラットフォームで機能します。特に、NVIDIA チップセット用のサポートは
格別に向上しており、 NVIDIA GeForce 8800 シリーズには特に良くなりました。
3.4. Tickless カーネル
以前は、Linux カーネルはプラットフォームに応じて事前設定した周波数 — 100 Hz、250 Hz、あるいは
1000 Hz でシステム上の各 CPU に定期的に割り込んでいました。カーネルは CPU が実行しているプロセス
23
第3章コアインフラストラクチャとメカニクス
ドラフト
についてクエリを出し、その結果をプロセスの計算とロードバランシングに使用していました。CPU の電力状態
に関係なく、カーネルは無無無無無無無無無timer tick無として知られるこの割り込みを実行していました。そのため、ア
イドル状態の CPU でも最大で毎秒 1000 回もこれらの要求に応答していたのです。アイドル状態 CPU 用に
省電力機能を実装してあるシステムでは、これらの省電力機能の利点を得るのに十分な CPU のアイドル状態
の維持をタイマーティックが阻止していました。
Fedora 14 内のカーネルは無無無無無無無tickless無で稼働します。これは旧式のオンデマンド型の定期タイマー割
り込みに入れ替わるものです。そのため、アイドル状態の CPU は新しいタスクがプロセス用にキューされるま
では、アイドル状態を持続できるようになります。そして低い電力消費状態にある CPU はその状態をより長く
維持できます。
3.5. 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 をセットします。
パフォーマンス（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 を使用すべきです。
24
ドラフト
Relatime ディスクアクセスの最適化
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 データに依存しているため、それが利用できない場合には問題になっていました。
25
第3章コアインフラストラクチャとメカニクス
ドラフト
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 Capping
Dynamic 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 ドライバーも含んでいま
す。これらの機能が一緒になってオペレーティングシステムとユーザースペースツールが、パワーキャップ用に
設定された値とシステムの現在の電力消費を読み取りを可能にしています。
1
For further details, refer to the official site: HP Dynamic Power Capping .
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 への変更を要求を行う
1
http://h18013.www1.hp.com/products/servers/management/dynamic-power-capping/index.html
26
ドラフト
Enhanced Graphics Power Management
と、OSPM ドライバーはその要求に相当する変更を P-states に行います。同様に Intel Node Manager が
OSPM ドライバーに対して P-states への変更を通知すると、ドライバーはそれに応じて T-states を変更しま
す。これらの変更は自動的に発生し、オペレーティングシステムの介入を必要としません。管理者は Intel DCM
Intel Data Center Manager ソフトウェアを使用して Intel Node Manager の設定と監視を行います。
For further details, refer to Node Manager — A Dynamic Approach To Managing Power In The Data
2
Center
3.9. Enhanced Graphics Power Management
Fedora 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
27
第3章コアインフラストラクチャとメカニクス
ドラフト
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 を頻繁にアイドル状態か
28
ドラフト
ユーザースペースの最適化
ら起こしてしまう処理の唯一の原因ではなく、アプリケーションからの関数呼び出しも CPU がアイドル状態に
入るか、または、アイドル状態を維持することを妨げる可能性があります。なお、不要な関数呼び出しは 50 個
以上のアプリケーションで削減されました。
ストレージとネットワークの I/O の削減
ストレージデバイスとネットワークインターフェイスへの入出力（I/O）はデバイスの電力消費を強要します。アイ
ドル時に節電状態になる機能（例えば、ALPM や ASPM）を持つストレージデバイスとネットワークインタフェー
スで、この無駄なトラフィックはデバイスがアイドル状態に入ったり、アイドル状態を維持することを阻止する可
能性があります。ハードディスクを使用していない時にプラッタ（円盤）の回転減少することを阻止してしまう可
能性があります。ストレージデバイスに対する不要な処理は、数種のアプリケーションで最低限に抑制されまし
た。ハードディスクの回転数減少を邪魔する処理は特に抑制されています。
Initscript の監査
要求に関係無く、自動的に開始するサービスは、いくつかのリソースを無駄にする可能性が多分にありま
す。それに対して可能な限りサービスがデフォルトで「オフ」や「オンデマンド」になるようにすべきです。例え
ば、Bluetooth 機能を提供する BlueZ サービスは以前はシステム上に Bluetooth 機能がなくても、システム
を開始する時に自動的に開始されていました。 BlueZ initscript は今では、サービスを開始する前にシステム
上に Bluetooth ハードウェアが存在することをチェックします。
29
30
ドラフト
ドラフト
使用ケース
この章では、２つの使用ケースを例に出してこのガイド内で説明してある分析と設定の方法を描写しています。
最初の例では、標準的なサーバーを考慮し、２つ目の例では標準的なラップトップを考慮しています。
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 を使用できるはずで
す。
31
第4章使用ケース
ドラフト
ディレクトリサーバー
ディレクトリサーバーは一般的に、低いディスク 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-saving
mechanisms. Note that performance and latency for the hard drive and network interface are
impacted.
追加として（代替として）各種システム設定に小調節を実行することもできます:
• 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
1
• disable nmi (non-maskable interrupt) watchdog (part of the laptop-battery-powersave profile):
1
http://en.wikipedia.org/wiki/Non-maskable_interrupt
32
ドラフト
例 — ラップトップ
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
33
第4章使用ケース
• 有線ネットワークを 100 Mbit/s に限定（laptop-battery-powersave プロフィールの一部）:
ethtool -s eth0 advertise 0x0F
34
ドラフト
ドラフト
ドラフト
付録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
35
付録A 開発者へのヒント
ドラフト
C
C のスレッドは同じメモリーを共有します。各スレッドはそれ自身のスタックを持ち、カーネルは新規のファイル
記述子を作成したり、新しいメモリースペースの割り当てをする必要がありません。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
36
ドラフト
Fsync
A.3. Fsync
fsync は I/O の高度なオペレーションとして知られます。しかしこれは完全に真実ではありません。例え
5
ば、Theodore Ts'o's の記事 Don't fear the fsync! と、そのページの議論を参照してみて下さい。
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/
37
38
ドラフト
ドラフト
付録B 改訂履歴
改訂 0.1
Thu Jul 29 2010
Landmann Rüdiger [FAMILY Given]
[email protected]
Bring upstream
39
40

Download Report