Difference between revisions of "Maximizing Performance (日本語)"

From ArchWiki
Jump to: navigation, search
m
m
Line 6: Line 6:
 
[[ru:Maximizing Performance]]
 
[[ru:Maximizing Performance]]
 
[[zh-CN:Maximizing Performance]]
 
[[zh-CN:Maximizing Performance]]
この記事では Arch Linux のパフォーマンスを向上させるための分析と基本的な概要を記述します。
+
{{Article summary start|概要}}
 +
{{Article summary text|この記事ではシステムのパフォーマンスを向上させる様々なトピックについて触れています。基本的な測定基準が必要であり、その後システムのパフォーマンスを改善するステップに進むことができます。}}
 +
{{Article summary heading|関連項目}}
 +
{{Article summary wiki|Benchmarking}}
 +
{{Article summary end}}
 +
この記事ではパフォーマンスに関する基本的なシステムの診断法と、リソースの消費を減らしたりシステムを最適化することができる、また、システムのパフォーマンスを向上させると言われている手順の情報を提供しています。
 +
 
  
 
==基本==
 
==基本==
Line 21: Line 27:
 
* ダイレクトレンダリングを使うアプリケーション、つまりビデオプレーヤーやゲームなどグラフィックカードを使うアプリケーションにラグが生じる場合、グラフィックパフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。glxinfo コマンドを使います:
 
* ダイレクトレンダリングを使うアプリケーション、つまりビデオプレーヤーやゲームなどグラフィックカードを使うアプリケーションにラグが生じる場合、グラフィックパフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。glxinfo コマンドを使います:
 
  $ glxinfo | grep direct
 
  $ glxinfo | grep direct
glxinfo は mesa-demos パッケージに含まれています。
+
{{ic|glxinfo}} {{Pkg|mesa-demos}} パッケージに含まれています。
  
 
===初めにすること===
 
===初めにすること===
 
パフォーマンスを向上させるのに、一番簡単で最も効果的な方法は軽量な環境・アプリケーションを動かすことです。
 
パフォーマンスを向上させるのに、一番簡単で最も効果的な方法は軽量な環境・アプリケーションを動かすことです。
* [[Desktop Environment (日本語)|デスクトップ環境]]の代わりに[[Window Manager (日本語)|ウィンドウマネージャ]]を使いましょう。[[dwm]], [[wmii]], [[i3]], [[Awesome (日本語)]], [[Openbox (日本語)]], [[Fluxbox]], [[JWM]] などがあります。
+
* [[Desktop Environment (日本語)|デスクトップ環境]]の代わりに[[Window Manager (日本語)|ウィンドウマネージャ]]を使いましょう。[[dwm]], [[wmii]], [[i3]], [[Awesome (日本語)|Awesome]], [[Openbox (日本語)|Openbox]], [[Fluxbox]], [[JWM]] などがあります。
* [[GNOME]] や [[KDE (日本語)]] などではなく最小主義のデスクトップ環境を選びましょう。[[LXDE (日本語)]] や [[Xfce]] などがあります。
+
* [[GNOME (日本語)|GNOME]] や [[KDE (日本語)|KDE]] などではなく最小主義のデスクトップ環境を選びましょう。[[LXDE (日本語)|LXDE]] や [[Xfce (日本語)|Xfce]] などがあります。
* 軽量なアプリケーションを使いましょう。[[List of Applications (日本語)|Common Applications]] でコンソールアプリケーションを探したり、フォーラム内のライトアンドファースト・アプリケーション・アワードのスレッドを見て下さい: [https://bbs.archlinux.org/viewtopic.php?id=41168 2007], [https://bbs.archlinux.org/viewtopic.php?id=67951 2008], [https://bbs.archlinux.org/viewtopic.php?id=78490 2009], [https://bbs.archlinux.org/viewtopic.php?id=88515 2010], [https://bbs.archlinux.org/viewtopic.php?id=111878 2011], [https://bbs.archlinux.org/viewtopic.php?id=138281 2012]。
+
* 軽量なアプリケーションを使いましょう。[[List of Applications (日本語)]] でコンソールアプリケーションを探したり、フォーラム内のライトアンドファースト・アプリケーション・アワードのスレッドを見て下さい: [https://bbs.archlinux.org/viewtopic.php?id=41168 2007], [https://bbs.archlinux.org/viewtopic.php?id=67951 2008], [https://bbs.archlinux.org/viewtopic.php?id=78490 2009], [https://bbs.archlinux.org/viewtopic.php?id=88515 2010], [https://bbs.archlinux.org/viewtopic.php?id=111878 2011], [https://bbs.archlinux.org/viewtopic.php?id=138281 2012]。
 
* 不必要な[[Daemons (日本語)|デーモン]]を停止させたり {{ic|[[systemd (日本語)#systemctl の基本的な使い方|systemctl]]}} を使ってバックグラウンドで動かしているデーモンを削除しましょう。
 
* 不必要な[[Daemons (日本語)|デーモン]]を停止させたり {{ic|[[systemd (日本語)#systemctl の基本的な使い方|systemctl]]}} を使ってバックグラウンドで動かしているデーモンを削除しましょう。
  
Line 61: Line 67:
  
 
===パーティション===
 
===パーティション===
パーティションレイアウトもシステムのパフォーマンスに影響を与えることがあります。ドライブの最初のセクター(ディスクの中心部)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さくして、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は分割パーティションに置くべきです。通常、システム (/) から home ディレクトリ (/home/user) を分割することでこれを行います。
+
パーティションレイアウトもシステムのパフォーマンスに影響を与えることがあります。ドライブの最初のセクター(ディスクの中心部)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さくして、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は分割パーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home/''user''}}) を分割することでこれを達成できます。
  
 
===ファイルシステムの選択とチューニング===
 
===ファイルシステムの選択とチューニング===
 
ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[File Systems (日本語)#ファイルシステムのタイプ|ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:Category:File systems (日本語)|ここ]]から関連記事も見ることができます。
 
ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[File Systems (日本語)#ファイルシステムのタイプ|ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:Category:File systems (日本語)|ここ]]から関連記事も見ることができます。
 
====概要====
 
*XFS: 大きなファイルで素晴らしいパフォーマンスを発揮します。/home で使うと良いかもしれません
 
*Ext3: 平均的なパフォーマンスと、信頼性があります。
 
*Ext4: 全体的に良いパフォーマンスを持ち、信頼性もありますが、sqlite などのデータベースでパフォーマンスが落ちる問題があります。
 
*JFS: 全体的に良いパフォーマンスを持ち、CPU 使用量が非常に少なく、電源が落ちた後の修復が極めて高速です。
 
*Btrfs: おそらく(圧縮を使うことで)全体で最高パフォーマンスを持ち多くの機能を備えています。開発途中ですがサポートはされています、ただしまだ不安定です。何をするのかを理解して潜在的なデータロスの対策をしないかぎりこのファイルシステムを使わないで下さい。
 
  
 
====マウントオプション====
 
====マウントオプション====
Line 84: Line 83:
  
 
====Ext4====
 
====Ext4====
[[Ext4#Tips_and_tricks | Ext4]] を見て下さい。
+
[[Ext4#Tips_and_tricks|Ext4]] を見て下さい。
  
 
====JFS====
 
====JFS====
Line 103: Line 102:
 
====Btrfs====
 
====Btrfs====
 
[[Btrfs (日本語)#デフラグメンテーション|デフラグメンテーション]]や[[Btrfs (日本語)#圧縮|圧縮]]を見て下さい。
 
[[Btrfs (日本語)#デフラグメンテーション|デフラグメンテーション]]や[[Btrfs (日本語)#圧縮|圧縮]]を見て下さい。
 +
 +
===カーネルパラメータの調整===
 +
 +
There are several key tunables governing filesystems that users should consider adding to [[sysctl|/etc/sysctl.conf]] which is auto-loaded at boot by [[systemd (日本語)|systemd]]:
 +
 +
# Contains, as a percentage of total system memory, the number of pages at which
 +
# a process which is generating disk writes will start writing out dirty data.
 +
vm.dirty_ratio = 3
 +
 +
# Contains, as a percentage of total system memory, the number of pages at which
 +
# the background kernel flusher threads will start writing out dirty data.
 +
vm.dirty_background_ratio = 2
 +
 +
As noted in the comments, one needs to consider the total amount of RAM when setting these values. 
 +
 +
*'''vm.dirty_ratio''' defaults to 10 (percent of RAM).  Consensus is that 10% of RAM when RAM is say half a GB (so 10% is ~50 MB) is a sane value on spinning disks, but it can be MUCH worse when RAM is larger, say 16 GB (10% is ~1.6 GB), as that's several seconds of writeback on spinning disks.  A more sane value in this cause is 3 (16*0.03 ~ 491 MB).
 +
 +
*'''vm.dirty_background_ratio''' similarly, 5 (% of RAM) by default may be just fine for small memory values, but again, consider and adjust accordingly for the amount of RAM on a particular system.
  
 
===/usr の圧縮===
 
===/usr の圧縮===
Line 131: Line 148:
 
直接 CPU の速度をあげる唯一の方法がオーバークロックです。煩雑でリスクが伴う作業が必要なので、上級者以外には推奨されません。オーバークロックするのに最適な方法は BIOS を使うことです。パソコンを買うときに、Intel マザーボードがオーバークロックを出来ないようにしていないか確認しておきましょう。
 
直接 CPU の速度をあげる唯一の方法がオーバークロックです。煩雑でリスクが伴う作業が必要なので、上級者以外には推奨されません。オーバークロックするのに最適な方法は BIOS を使うことです。パソコンを買うときに、Intel マザーボードがオーバークロックを出来ないようにしていないか確認しておきましょう。
  
多くの Intel i5・i7 チップは、BIOS や UEFI インターフェースを通して正しくオーバークロックされた場合でも、acpi_cpufreq などのユーティリティに正しいクロック周波数を伝えません。この結果、acpi_cpufreq をアンロードしてブラックリスト化しない限り dmesg は極端なメッセージを表示します。オーバークロックしたチップのクロック速度を Linux で正しく読むことができる唯一のツールが i7z です。i7z パッケージは community リポジトリから利用可能で、i7z-svn は AUR から利用可能です。
+
多くの Intel i5・i7 チップは、BIOS や UEFI インターフェースを通して正しくオーバークロックされた場合でも、acpi_cpufreq などのユーティリティに正しいクロック周波数を伝えません。この結果、acpi_cpufreq をアンロードしてブラックリスト化しない限り dmesg は極端なメッセージを表示します。オーバークロックしたチップのクロック速度を Linux で正しく読むことができる唯一のツールが i7z です。{{Pkg|i7z}} パッケージは community リポジトリから利用可能で、{{AUR|i7z-git}} [[Arch User Repository (日本語)|AUR]] から利用可能です。
  
 
パフォーマンスを改善する方法には ([http://lkml.org/lkml/2009/9/6/136 ref])、Con Kolivas の、デスクトップ中心のカーネルパッチセットを使って、Completely Fair Scheduler (CFS) を Brain Fuck Scheduler (BFS) に置き換えるという方法もあります。
 
パフォーマンスを改善する方法には ([http://lkml.org/lkml/2009/9/6/136 ref])、Con Kolivas の、デスクトップ中心のカーネルパッチセットを使って、Completely Fair Scheduler (CFS) を Brain Fuck Scheduler (BFS) に置き換えるという方法もあります。
Line 148: Line 165:
  
 
==ネットワーク==
 
==ネットワーク==
[[General Recommendations (日本語)#ネットワーク|General Recommendations]] の関連セクションも見て下さい。
+
[[General Recommendations (日本語)#ネットワーク]] も見て下さい。
  
 
==グラフィック==
 
==グラフィック==
Line 175: Line 192:
 
=== Swappiness ===
 
=== Swappiness ===
  
swappiness はカーネルがどれくらいスワップより RAM を使うか示すものです。非常に低い値に設定、つまりカーネルにほとんど常時 RAM を使わせるようにすると、多くのシステムでレスポンスを改善できることが知られています。これをするには、{{ic|/etc/sysctl.conf}} に以下を加えて下さい:
+
[[Swap (日本語)#Swappiness]] を参照してください。
 
+
vm.swappiness=20
+
vm.vfs_cache_pressure=50
+
 
+
テストをしたり、動作について詳しく知るには、[http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that この記事]を見て下さい。
+
  
 
===Compcache / Zram ===
 
===Compcache / Zram ===
 
[https://code.google.com/p/compcache/ Compcache] はデバイスを RAM に作成して圧縮する機構です。最近 compcache は '''zram''' カーネルモジュールに置き換えられました。スワップに Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。Zram はまだメインラインには取り込まれていません(なので安定はしていません、気をつけて使って下さい)。
 
[https://code.google.com/p/compcache/ Compcache] はデバイスを RAM に作成して圧縮する機構です。最近 compcache は '''zram''' カーネルモジュールに置き換えられました。スワップに Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。Zram はまだメインラインには取り込まれていません(なので安定はしていません、気をつけて使って下さい)。
  
AUR パッケージ {{aur|zramswap}} はあなたのシステムに最適な設定で (RAM サイズや CPU コア数にあわせて) スワップデバイスをセットする自動スクリプトを提供します。スクリプトは1つの CPU コアに1つの zram デバイスを作成し、全体のスペースが RAM の量と同じになるようにします。起動時に自動でこれを行わせるには:
+
AUR パッケージ {{aur|zramswap}} はあなたのシステムに最適な設定で (RAM サイズや CPU コア数にあわせて) スワップデバイスをセットする自動スクリプトを提供します。スクリプトは1つの CPU コアに1つの zram デバイスを作成し、全体のスペースが RAM の量と同じになるようにします。起動時に自動でこれを行わせるには、[[systemd (日本語)#systemctl の基本的な使い方|systemctl]] を使って {{ic|zramswap.service}} を有効にしてください。
 
+
* [[rc.conf|initscripts]] を使っている場合、{{ic|/etc/rc.conf}} の DAEMONS 行に {{ic|zramswap}} を追加してください。
+
* [[systemd (日本語)|systemd]] を使っている場合、systemctl を使って {{ic|zramswap.service}} を有効にしてください。
+
  
 
標準スワップよりも圧縮スワップに高い優先度を持たせることでデータの圧縮に複数の CPU コアを利用します。
 
標準スワップよりも圧縮スワップに高い優先度を持たせることでデータの圧縮に複数の CPU コアを利用します。
Line 209: Line 218:
 
  # systemctl enable preload
 
  # systemctl enable preload
 
システムで一番よく使われるファイルを監視して、起動時にプリロードするファイル一覧に組み込みます。
 
システムで一番よく使われるファイルを監視して、起動時にプリロードするファイル一覧に組み込みます。
 
====Readahead====
 
[[Systemd (日本語)#Readahead|Readahead]] は後に必要になるファイルをキャッシュすることでプログラムの起動を早くするツールです。
 
  
 
==起動時間==
 
==起動時間==
[[Improve Boot Performance]] にチュートリアルとヒントがあります。
+
[[Improve Boot Performance (日本語)]] にチュートリアルとヒントがあります。
  
 
===Suspend to RAM===
 
===Suspend to RAM===
起動時間を短縮する最適解は全く起動しないことです。[[Suspend to RAM]] を使えないか考えてみて下さい。
+
起動時間を短縮する最適解は全く起動しないことです。[[Suspend and Hibernate#Suspend to RAM|Suspend to RAM]] を使えないか考えてみて下さい。
  
 
===カスタムカーネル===
 
===カスタムカーネル===
Line 233: Line 239:
  
 
===LibreOffice===
 
===LibreOffice===
[[LibreOffice (日本語)#LibreOffice の高速化|Speed up LibreOffice]] を見て下さい。
+
[[LibreOffice (日本語)#LibreOffice の高速化]] を見て下さい。
  
 
===Pacman===
 
===Pacman===

Revision as of 15:37, 30 August 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary end この記事ではパフォーマンスに関する基本的なシステムの診断法と、リソースの消費を減らしたりシステムを最適化することができる、また、システムのパフォーマンスを向上させると言われている手順の情報を提供しています。


基本

システムを知る

システムをチューンするには、まず全体のスピードを下げているボトルネックのサブシステムを見つける必要があります。普通システムの仕様を知ることで特定することができますが、目に見える兆候もあります:

  • OpenOffice.org や Firefox などの大きなアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の量が十分でないのかもしれません。利用できる RAM の量を知るには、次のコマンドを使い、-/+buffers で始まる行をチェックしてください:
$ free -m
  • 起動時間が非常に長い場合、または、アプリケーションを初めて起動するときにロードに長い時間がかかるが起動後は順調に動作する場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには hdparm コマンドを使います:
$ hdparm -t /dev/sdx

ハードドライブの純粋な読み込み速度なので、正しいベンチマークとは言えませんが、(アイドル状態のときにドライブをテストして)平均的なコンピュータでは 40MB/s より高い数値が出るのが普通だと思われます。hdparm は公式リポジトリに入っています。

  • RAM が利用できる時でも CPU 負担が一貫して高い場合、CPU 使用量を減らすことが優先事項でしょう。top コマンドを使うなど多くの方法で CPU 負担をモニタすることができます:
$ top
  • ダイレクトレンダリングを使うアプリケーション、つまりビデオプレーヤーやゲームなどグラフィックカードを使うアプリケーションにラグが生じる場合、グラフィックパフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。glxinfo コマンドを使います:
$ glxinfo | grep direct

glxinfomesa-demos パッケージに含まれています。

初めにすること

パフォーマンスを向上させるのに、一番簡単で最も効果的な方法は軽量な環境・アプリケーションを動かすことです。

妥協

ほとんど全てのチューニングには代償が伴います。軽量なアプリケーションは一般的に機能が少ないですし、調整がシステムを不安定にすることもあります。また、実行と管理に時間が必要になるでしょう。このページではそうした欠点もできるだけ触れますが、最終的に決定を下すのはユーザーです。

ベンチマーク

最適化の効果を判断できないことがたびたびあります。そういった場合はベンチマークツールで計測することができます。

ストレージデバイス

デバイスレイアウト

パフォーマンスを一番大きく向上させるもののひとつが、オペレーティングシステムが動くレイアウトを複数のデバイスで作ることです。/ /home /var /usr を異なるディスクに置くと、全てを同じハードドライブに置く、シングルディスクレイアウトに比べて劇的に速くなります。

スワップファイル

スワップファイルを分割したディスクに作成するのも、特にマシンがスワップを頻繁に使う場合、多くの利益があります。利用したい環境に十分な量の RAM がない場合によく使われます。多くの機能とアプリケーションを装備した KDE を使うには数 GiB のメモリが必要になりますが、小さなウィンドウマネージャとコンソールアプリケーションなら 512 MiB メモリ以下でも完全に適合します。

RAID

(2つ以上の)複数のディスクを使える場合、ソフトウェア RAID を設定することでスピードを向上させることが可能です。RAID 0 アレイではドライブ障害に対する冗長性はありませんが、アレイにディスクを追加すればそれだけディスクの速度を高速にできます。賢い選択は RAID 5 を使うことです、RAID 5 はスピードとデータ保護の両方を提供します。

ハードウェアの接続端子

内部ハードウェア端子によってストレージデバイスはマザーボードに接続されます。NIC を通る TCP/IP のように、マザーボードに接続する方法は複数あり、PCIe/PCI を使って直接つなぐ、Firewire、Raid カード、USB、などがあります。ストレージデバイスをこれらの複数の接続端子を使うようにすることで、マザーボードを最大限に使うことできます。例えば、6つのハードドライブを接続するのに全部 USB を使うのは、3つずつ USB と Firewire を使いわけるのよりも、ずっとずっと遅くなります。なぜならば、マザーボードに接続する各々の端子はパイプのようになっており、そのパイプを一度に通過できる量はセットで制限されているからです。吉報は、マザーボードには一般的に複数のパイプがあるということです。

その他の例

  1. pci/PCIe/ata を使って直接マザーボードに接続
  2. 外部容器を使ってディスクを USB/Firewire を通して収納する
  3. tcp/ip で接続してデバイスをネットワークストレージデバイスに変える

また、あなたがマシンのフロントに2つの USB 端子、バックに4つの USB 端子、そして4つのディスクを持っている場合、おそらく一番速くなる構成は、フロント2/バック2もしくはフロント1/バック3です。フロントの端子はバックとは異なり、分割されたルートハブのようになっているため、2倍のデータを送ることができるのです。以下のコマンドを使うことでマシンにある様々な接続経路を確認できます。

USB デバイスツリー
$ lsusb -tv
PCI デバイスツリー
$ lspci -tv

パーティション

パーティションレイアウトもシステムのパフォーマンスに影響を与えることがあります。ドライブの最初のセクター(ディスクの中心部)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さくして、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は分割パーティションに置くべきです。通常、システム (/) から home ディレクトリ (/home/user) を分割することでこれを達成できます。

ファイルシステムの選択とチューニング

ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。ファイルシステムの記事に人気のあるファイルシステムの簡単な説明がされています。ここから関連記事も見ることができます。

マウントオプション

マウントオプションを使えばフォーマットする必要なく簡単にスピードを改善できます。マウントコマンドを使うときにマウントオプションを設定できます:

$ mount -o option1,option2 /dev/partition /mnt/partition

永続的に設定するには、/etc/fstab を編集して対象の行を次のようにしてください:

/dev/partition /mnt/partition partitiontype option1,option2 0 0

noatime,nodiratime マウントオプションはほとんど全てのファイルシステムでパフォーマンスを向上させることができるとして知られています。前者は後者の上位版です (nodiratime はディレクトリにだけ適用されます -- noatime はファイルとディレクトリ両方に適用されます)。レアケースで、例えば、あなたが mutt を使っている場合など、小さな問題が起こることがあります。代わりに relatime オプションを使うこともできます (relatime はカーネル 2.6.30 以上ではデフォルトです)。

Ext3

Ext3 を見て下さい。

Ext4

Ext4 を見て下さい。

JFS

JFS Filesystem を見て下さい。

XFS

XFS ファイルシステムは作成するときにデフォルトで "boost knobs" が有効になっています:

$ mkfs.xfs /dev/thetargetpartition

Reiserfs

data=writeback マウントオプションはスピードを向上させますが、電源喪失でデータが破損します。notail マウントオプションはファイルシステムが使う容量を 5% ほど増やしますが、全体的なスピードが向上します。ジャーナルとデータを分割してドライブに置くことで読み込み時間を減らすこともできます。これをするにはファイルシステムを作成する際に次のようにしてください:

$ mkreiserfs –j /dev/hda1 /dev/hdb1

/dev/hda1 をジャーナルとして使うパーティションに、/dev/hdb1 をデータ用のパーティションに置き換えてください。reiserfs について詳しくはこの記事を見て下さい。

Btrfs

デフラグメンテーション圧縮を見て下さい。

カーネルパラメータの調整

There are several key tunables governing filesystems that users should consider adding to /etc/sysctl.conf which is auto-loaded at boot by systemd:

# Contains, as a percentage of total system memory, the number of pages at which
# a process which is generating disk writes will start writing out dirty data.
vm.dirty_ratio = 3

# Contains, as a percentage of total system memory, the number of pages at which
# the background kernel flusher threads will start writing out dirty data.
vm.dirty_background_ratio = 2

As noted in the comments, one needs to consider the total amount of RAM when setting these values.

  • vm.dirty_ratio defaults to 10 (percent of RAM). Consensus is that 10% of RAM when RAM is say half a GB (so 10% is ~50 MB) is a sane value on spinning disks, but it can be MUCH worse when RAM is larger, say 16 GB (10% is ~1.6 GB), as that's several seconds of writeback on spinning disks. A more sane value in this cause is 3 (16*0.03 ~ 491 MB).
  • vm.dirty_background_ratio similarly, 5 (% of RAM) by default may be just fine for small memory values, but again, consider and adjust accordingly for the amount of RAM on a particular system.

/usr の圧縮

Note: Linux カーネルのバージョン 3.0 現在、aufs2 は既にサポートされていません。

A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some file systems support transparent compression, most notably Btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this Gentoo forums thread. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the official repositories, so no kernel compilation is needed if using the stock kernel. Since the linked guide is for Gentoo, the next commands outline the steps specifically for Arch. To get it working, install the packages aufs2 and squashfs-tools. These packages provide the aufs-modules and some userspace-tools for the squash-filesystem.

Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:

# mkdir -p /squashed/usr/{ro,rw}

Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:

# mksquashfs /usr /squashed/usr/usr.sfs -b 65536

These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described here. Now to get the archive mounted together with the writeable folder it is necessary to edit /etc/fstab and add the following lines:

/squashed/usr/usr.sfs   /squashed/usr/ro   squashfs   loop,ro   0 0 
usr    /usr    aufs    udba=reval,br:/squashed/usr/rw:/squashed/usr/ro  0 0

Now you should be done and able to reboot. The original author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is safer to leave the old files in place.

A Bash script has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.

SSD 向けのチューニング

SSD#Tips_for_Maximizing_SSD_Performance

RAM ディスク / 本当に遅いディスクのためのチューニング

CPU

直接 CPU の速度をあげる唯一の方法がオーバークロックです。煩雑でリスクが伴う作業が必要なので、上級者以外には推奨されません。オーバークロックするのに最適な方法は BIOS を使うことです。パソコンを買うときに、Intel マザーボードがオーバークロックを出来ないようにしていないか確認しておきましょう。

多くの Intel i5・i7 チップは、BIOS や UEFI インターフェースを通して正しくオーバークロックされた場合でも、acpi_cpufreq などのユーティリティに正しいクロック周波数を伝えません。この結果、acpi_cpufreq をアンロードしてブラックリスト化しない限り dmesg は極端なメッセージを表示します。オーバークロックしたチップのクロック速度を Linux で正しく読むことができる唯一のツールが i7z です。i7z パッケージは community リポジトリから利用可能で、i7z-gitAURAUR から利用可能です。

パフォーマンスを改善する方法には (ref)、Con Kolivas の、デスクトップ中心のカーネルパッチセットを使って、Completely Fair Scheduler (CFS) を Brain Fuck Scheduler (BFS) に置き換えるという方法もあります。

BFS パッチを含んだカーネル PKGBUILD は AURUnofficial User Repositories からインストールできます。追加パッチについての詳しい情報は、linux-ckAURLinux-ck ページを、linux-bfsAURlinux-pfAUR はそれぞれのページを見て下さい。

Note: BFS/CK はデスクトップ・ラップトップでの利用を考えてデザインされています、サーバーとしての利用は考慮されていません。低レイテンシを提供し 16 CPU 以下で動作します。また、Con Kolivas は HZ を 1000 に設定することを提案しています。詳しくは、BFS FAQKernel patch homepage of Con Kolivas を見て下さい。

Verynice

Verynice は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、AUR では veryniceAUR として利用可能です。nice レベルとは、CPU 資源を配分するときに実行可能ファイルの優先度を表すものです。X やマルチメディアアプリケーションなどレスポンスが重要なアプリケーションを /etc/verynice.confgoodexe と定義しましょう。同じように、make などの、バックグラウンドで CPU を使う実行可能ファイルを badexe として定義することができます。こうやって優先順位をつけることで重い処理を行なっている時のシステムのレスポンスを向上させることができます。

Ulatencyd

Ulatencyd は Linux カーネルが動作中のプロセスにリソースをどう費やすのかコントロールするデーモンです。カーネルヒントとプロセスの制限をするのに動的な cgroups を使います。CPU の使用だけでなく、ディスク I/O でのプロセスの優先順位付けもサポートしており、また、Verynice よりも賢いヒューリスティックを持っています。さらに、すぐに使える設定セットもあります。

1つ警告として、デフォルトでは全てのブロックデバイスのデフォルトスケジューラを cfq に変更するので注意してください。この挙動を無効にする方法は Ulatencyd を見て下さい。

ネットワーク

General Recommendations (日本語)#ネットワーク も見て下さい。

グラフィック

Xorg.conf 設定

グラフィックパフォーマンスは主に /etc/X11/xorg.conf の設定に依存しています。Nvidia, ATI, Intel のカードを使うためのチュートリアルを見ましょう。不適当な設定は Xorg の動作を止めます、警告が参考になるでしょう。

Driconf

Driconf はオープンソースドライバのダイレクトレンダリング設定を変えるための小さなユーティリティです。公式リポジトリからインストールできます。HyperZ を有効にすることで劇的にパフォーマンスを向上させることができるかもしれません。

GPU オーバークロック

グラフィックカードをオーバークロックすることは CPU のそれよりも一般的に好都合です、なぜなら、オンザフライで GPU のクロックを調節できる分かりやすいソフトウェアパッケージがあるからです。ATI ユーザーは、rovclockAURamdoverdrivectrlAUR を使って下さい。Nvidia ユーザーは nvclockAUR が必要です。Intel チップセットのユーザーは gmaboosterAUR AUR パッケージで GMABooster をインストールできます。

変更を永続的にするには、X 起動後に適当なコマンドを実行させてください、例えば、~/.xinitrc にコマンドを追加するなど。ただし、必要な時だけにオーバークロック設定を適用させるほうがより安全ではあります。

RAM とスワップ

ファイルを tmpfs に再配置する

ブラウザプロファイルなどのファイルを /tmp/dev/shm などの tmpfs ファイルシステムに再配置すれと、ファイルが RAM に保存され、アプリケーションのレスポンスを向上させることができます。

信頼性を上げ使いやすくするために活発な管理スクリプトを使いましょう。

ブラウザプロファイルの同期についての情報は Profile-sync-daemon を参照してください。

特定のフォルダの同期についての情報は Anything-sync-daemon を参照してください。

Swappiness

Swap (日本語)#Swappiness を参照してください。

Compcache / Zram

Compcache はデバイスを RAM に作成して圧縮する機構です。最近 compcache は zram カーネルモジュールに置き換えられました。スワップに Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。Zram はまだメインラインには取り込まれていません(なので安定はしていません、気をつけて使って下さい)。

AUR パッケージ zramswapAUR はあなたのシステムに最適な設定で (RAM サイズや CPU コア数にあわせて) スワップデバイスをセットする自動スクリプトを提供します。スクリプトは1つの CPU コアに1つの zram デバイスを作成し、全体のスペースが RAM の量と同じになるようにします。起動時に自動でこれを行わせるには、systemctl を使って zramswap.service を有効にしてください。

標準スワップよりも圧縮スワップに高い優先度を持たせることでデータの圧縮に複数の CPU コアを利用します。

Tip: zram の使用は、スワップが SSD にある場合、読み書き回数を減らすのにも役立ちます。

グラフィックカードの RAM を使う

搭載している RAM が僅かでビデオ RAM の余りがないような場合でなければ、ビデオ RAM をスワップとして使うことができます。Swap on video ram を見て下さい。

プリロード

プリロードとは、ターゲットファイルを RAM に置くことです。ハードドライブよりも RAM のほうが速く読み込まれるので、プリロードされたアプリケーションはより早く起動するという利益があります。しかしながら、RAM の一部を(アプリケーションを起動していないときでも)そのために取っておくことになります。したがって、プリロードは Firefox や OpenOffice など巨大でよく使うアプリケーションと一緒に使うのがベストです。

Go-preload

Go-preloadGentoo forum で作成された小さなデーモンです。使うには、まず、起動時にプリロードしたいプログラムごとに、次のコマンドを端末で実行してください:

# gopreload-prepare program

それから、指示通りに、プログラムが完全にロードされたら Enter を押します。これでそのプログラムが必要とするファイルの一覧が /usr/share/gopreload/enabled に追加されます。起動時に全てのリストをロードするには、/etc/rc.conf の DAEMONS 行に gopreload を追加してください。プログラムのロードを無効化するには、/usr/share/gopreload/enabled の適切なリストを削除するか、/usr/share/gopreload/disabled に移動してください。

Preload

Preload はもっと自動化されたアプローチを取ります。あなたがするべきことは systemd で Preload を有効にすることだけです。

# systemctl enable preload

システムで一番よく使われるファイルを監視して、起動時にプリロードするファイル一覧に組み込みます。

起動時間

Improve Boot Performance (日本語) にチュートリアルとヒントがあります。

Suspend to RAM

起動時間を短縮する最適解は全く起動しないことです。Suspend to RAM を使えないか考えてみて下さい。

カスタムカーネル

カスタムカーネルをコンパイルすることで起動時間やメモリ使用量を減らすことができるかもしれません、ただし、逆に増えてしまったり、問題が生じることもありえます。基本的に試す価値はありませんが、面白みを感じたり良い勉強の経験になるかもしれません。どうすればいいのか知りたいのなら、ここから始めて下さい。

アプリケーションごとの最適化

Firefox

Firefox Tweaks にはパフォーマンスを向上させる方法が載っています; 特にアンチフィッシングの停止SQlite データベースのデフラグは効果的です。次も参照: Firefox in Ramdisk

公式リポジトリの Firefox は Profile Guided Optimization が有効になっているプロファイルでビルドされています。カスタムビルドでも PGO を有効にするには mozconfig に次を加えて下さい:

ac_add_options --enable-profile-guided-optimization

Gcc/Makepkg

Ccache を見て下さい。

LibreOffice

LibreOffice (日本語)#LibreOffice の高速化 を見て下さい。

Pacman

Improve Pacman Performance を見て下さい。

SSH

Speed up SSH を見て下さい。

Laptops

Laptop を見て下さい。