「パフォーマンスの向上」の版間の差分
(→I/O スケジューラの変更: 情報を更新) |
(→カーネルの I/O スケジューラ: 情報を更新) |
||
| 145行目: | 145行目: | ||
**''Kyber'' |
**''Kyber'' |
||
**''BFQ'' |
**''BFQ'' |
||
| + | :{{Note|1=シングルキュースケジューラは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f382fb0bcef4c37dc049e9f6963e3baf204d815c Linux5.0 以降カーネルから削除されました]}} |
||
| − | :{{Warning|マルチキュースケジューラフレームワークとそのアルゴリズムは開発途上であり、問題がまだ残っている可能性があります [https://groups.google.com/forum/#!forum/bfq-iosched]。}} |
||
| + | |||
{{Note|どのスケジューラが一番良いのかはデバイスとワークロードの性質によります。また、スループットだけではパフォーマンスを計測できません。デッドラインや公平性という概念を導入するとスループットが悪くなりますがシステムの反応性は改善します。}} |
{{Note|どのスケジューラが一番良いのかはデバイスとワークロードの性質によります。また、スループットだけではパフォーマンスを計測できません。デッドラインや公平性という概念を導入するとスループットが悪くなりますがシステムの反応性は改善します。}} |
||
2020年12月9日 (水) 09:34時点における版
関連記事
この記事ではパフォーマンスに関する基本的なシステムの診断法と、リソースの消費を減らしたりシステムを最適化することができる、また、システムのパフォーマンスを向上させると言われている手順の情報を提供しています。
目次
基本
システムを知る
システムをチューンするには、まず全体のスピードを下げているボトルネックのサブシステムを見つける必要があります。普通システムの仕様を知ることで特定することができますが、目に見える兆候もあります:
- LibreOffice や Firefox などの巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の量が十分でないのかもしれません。利用できる RAM の量を知るには、以下のコマンドを使い、"available" カラムをチェックしてください:
$ free -h
- 起動時間が非常に長い場合、または、アプリケーションを初めて起動するときにロードに長い時間がかかるが起動後は順調に動作する場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには
hdparmコマンドを使います:
# hdparm -t /dev/sdX
- RAM が利用できる時でも CPU 負担が一貫して高い場合、不要なデーモンを無効化するなどして CPU 使用量を減らすことが優先事項でしょう。htop や
pstreeなどのシステム監視ツールで CPU 負担をモニタすることができます:
$ htop
- ダイレクトレンダリングを使うアプリケーション、つまりビデオプレーヤーやゲームなどグラフィックカードを使うアプリケーションにラグが生じる場合、グラフィックパフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。
glxinfoコマンドを使います (glxinfoは mesa-demos パッケージに含まれています):
$ glxinfo | grep direct
direct rendering: Yes
パフォーマンスを向上させるのに、一番簡単で最も効果的な方法は軽量な環境・アプリケーションを動かすことです:
- デスクトップ環境の代わりにウィンドウマネージャを使いましょう。dwm, wmii, i3, Awesome, Openbox, Fluxbox, JWM, xmonad などがあります。
- 重量級のデスクトップ環境、GNOME や KDE の代わりに、LXDE や Xfce などの軽量な環境を使いましょう。
- 軽量なアプリケーションを使いましょう。アプリケーション一覧でコンソールアプリケーションを探したり、依存ライブラリが少ないアプリケーションを探してみてください。
妥協
ほとんど全てのチューニングには代償が伴います。軽量なアプリケーションは一般的に機能が少ないですし、調整がシステムを不安定にすることもあります。また、実行と管理に時間が必要になるでしょう。このページではそうした欠点もできるだけ触れますが、最終的に決定を下すのはユーザーです。
ベンチマーク
最適化の効果を判断できないことがたびたびあります。そういった場合はベンチマークツールで計測することができます。
ストレージデバイス
デバイスレイアウト
パフォーマンスを一番大きく向上させるもののひとつが、オペレーティングシステムが動くレイアウトを複数のデバイスで作ることです。/ /home /var /usr を異なるディスクに置くと、全てを同じハードドライブに置く、シングルディスクレイアウトに比べて劇的に速くなります。
スワップファイル
スワップファイルを分割したディスクに作成するのも、特にマシンがスワップを頻繁に使う場合、多くの利益があります。利用したい環境に十分な量の RAM がない場合によく使われます。多くの機能とアプリケーションを装備した KDE を使うには数 GiB のメモリが必要になりますが、小さなウィンドウマネージャとコンソールアプリケーションなら 512 MiB メモリ以下でも完全に適合します。
RAID
（２つ以上の）複数のディスクを使える場合、ソフトウェア RAID を設定することでスピードを向上させることが可能です。RAID 0 アレイではドライブ障害に対する冗長性はありませんが、アレイにディスクを追加すればそれだけディスクの速度を高速にできます。賢い選択は RAID 5 を使うことです、RAID 5 はスピードとデータ保護の両方を提供します。
ハードウェアの接続端子
内部ハードウェア端子によってストレージデバイスはマザーボードに接続されます。NIC を通る TCP/IP のように、マザーボードに接続する方法は複数あり、PCIe/PCI を使って直接つなぐ、Firewire、Raid カード、USB、などがあります。ストレージデバイスをこれらの複数の接続端子を使うようにすることで、マザーボードを最大限に使うことできます。例えば、6つのハードドライブを接続するのに全部 USB を使うのは、3つずつ USB と Firewire を使いわけるのよりも、ずっとずっと遅くなります。なぜならば、マザーボードに接続する各々の端子はパイプのようになっており、そのパイプを一度に通過できる量はセットで制限されているからです。吉報は、マザーボードには一般的に複数のパイプがあるということです。
その他の例
- pci/PCIe/ata を使って直接マザーボードに接続
- 外部容器を使ってディスクを USB/Firewire を通して収納する
- 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 オプションを使うこともできます (カーネル 2.6.30 以上ではデフォルトです)。
特定のファイルシステムにしかないマウントオプションも存在します。それぞれのファイルシステムのページを見て下さい:
Reiserfs
data=writeback マウントオプションはスピードを向上させますが、電源喪失でデータが破損します。notail マウントオプションはファイルシステムが使う容量を 5% ほど増やしますが、全体的なスピードが向上します。ジャーナルとデータを分割してドライブに置くことで読み込み時間を減らすこともできます。これをするにはファイルシステムを作成する際に次のようにしてください:
# mkreiserfs –j /dev/sda1 /dev/sdb1
/dev/sda1 をジャーナルとして使うパーティションに、/dev/sdb1 をデータ用のパーティションに置き換えてください。reiserfs について詳しくは この記事 を見て下さい。
カーネルパラメータの調整
ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは sysctl#仮想メモリ を見て下さい。
I/O スケジューラの設定
背景情報
入出力 (I/O) スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:
- HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます (IOPS)。
- SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。
プロセスを大量に実行してストレージの様々な場所の I/O リクエストを発生させているとき (つまりランダムアクセスをしている状態)、数千の IOPS が生成されますが、普通の HDD では 200 IOPS までしか対応できません。ストレージにアクセスできるまで待機するリクエストの待ち行列が作られることになります。I/O スケジューラはこの待ち行列を最適化します。
スケジューリングアルゴリズム
スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えて出来るだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが elevator スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。
エレベーターアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータースケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。この問題を解決するために anticipatory IO スケジューラが追加されました。同期リクエストの場合、このアルゴリズムでは他のリクエストに移るまで数ミリ秒間待機します。
上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて deadline スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。
Completely Fair Queuing (CFQ) は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに cgroups のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという anticipatory スケジューラの機能を改良して取り入れています。より高度な CFQ スケジューラが導入されたことで anticipatory と elevator スケジューラは Linux カーネルから外されることになりました。
Budget Fair Queuing (BFQ) は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。
Kyber はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。
カーネルの I/O スケジューラ
初期のアルゴリズムには既にメインラインから外されているものもあります。公式 Linux カーネルがサポートしている I/O スケジューラは以下の2つのカテゴリに分けることができます:
- シングルキュースケジューラはデフォルトで使えるスケジューラです:
- NOOP は最も単純なスケジューラです。全ての I/O リクエストをシンプルな FIFO キューに入れてリクエストをまとめます。NOOP アルゴリズムでは、セクタ番号によってリクエストの順番を変えることがありません。したがって、デバイスレベルで順位付けを行っている場合や SSD など順位付けが意味をなさない場合は NOOP を使用します。
- Deadline
- CFQ
- マルチキュースケジューラは #I/O スケジューラの変更で説明しているように起動時にモードを有効にして使うことができます。Multi-Queue Block I/O Queuing Mechanism (blk-mq) は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。blk-mq では以下のスケジューラが使えます:
- None, キューイングアルゴリズムは適用されません。
- mq-deadline は deadline スケジューラをマルチスレッドに対応させたスケジューラです。
- Kyber
- BFQ
I/O スケジューラの変更
特定のデバイスで利用できるスケジューラと、現在使われているスケジューラを確認するには:
$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
あるいは全てのデバイスでスケジューラを確認するには:
$ cat /sys/block/sd*/queue/scheduler
mq-deadline kyber [bfq] none [mq-deadline] kyber bfq none mq-deadline kyber [bfq] none
sda デバイスで I/O スケジューラを bfq に変更するには、以下のコマンドを使用します:
# echo bfq > /sys/block/sda/queue/scheduler
SSD や NVMe の場合多数の IOPS を処理できるため、none や mq-deadline などのシンプルなアルゴリズムが最適です。逆に HDD には BFQ が適しています。以下のように udev ルールを使うことで、ディスクが HDD か SSD かどうかで I/O スケジューラを自動的に変更して永続的に設定することが可能です:
/etc/udev/rules.d/60-ioschedulers.rules
# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
ルールを保存したら、マシンを再起動するか、ルールをリロードしてください。
IO スケジューラの調整
カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。設定項目と説明は カーネルドキュメントファイル で確認できます。
特定のデバイスで設定可能なパラメータを確認するには (以下の例では sdb は deadline を使用しています):
$ ls /sys/block/sdb/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved
レイテンシを犠牲に deadline のスループットを高めるには以下のコマンドで fifo_batch を増やします:
# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch
電源管理の設定
伝統的な回転ディスク (HDD) を使用する場合は省電力機能を無効化することで性能の改善が見込めます。
ディスクの読み書きを減らす
遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。
ディスクの書き込みを表示する
iotop パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは iotop(8) を見てください。
ファイルを tmpfs に再配置する
ブラウザプロファイルなどのファイルを /tmp や /dev/shm などの tmpfs ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:
- ブラウザプロファイルの同期については Profile-sync-daemon を参照してください。Firefox を使っている場合は Firefox Ramdisk も参照。
- 特定のフォルダを同期する方法は Anything-sync-daemon を参照してください。
tmpfs でコンパイルする
パッケージのビルド時にコンパイル時間を短縮する方法は Makepkg#コンパイル時間を短縮するを参照。
ファイルシステムの最適化
ファイルシステムによってはパフォーマンスを改善する方法が存在することがあります。例: Ext4#ヒントとテクニック。
スワップ領域
スワップ#パフォーマンスチューニングを見てください。
ionice によるストレージ I/O スケジューリング
バックアップなどの作業ではストレージ I/O の遅延はさほど関係がなく I/O 帯域幅を最大限使う意味がありません。そのような作業はバックグラウンドタスクと分類することができます。一方でデスクトップでは UI のレスポンスを早くするために高速な I/O を必要とします。バックグラウンドタスクとしてのストレージ帯域幅を減らすことで、他のストレージ I/O を必要とするタスクが帯域幅を活用することが可能です。Linux の I/O スケジューラである CFQ では、プロセスによって優先度を別々に設定できます。
バックグラウンドプロセスの I/O 優先度を "Idle" レベルまで減らしてからプロセスを起動するには:
# ionice -c 3 command
CPU
オーバークロック
直接 CPU の速度をあげる唯一の方法がオーバークロックです。煩雑でリスクを伴う作業が必要なので、上級者以外には推奨されません。オーバークロックは大抵の場合 BIOS から設定します。パソコンを買うときに、Intel マザーボードがオーバークロックを出来ないようにしていないか確認しておきましょう。
Intel 製のチップの多くは、BIOS や UEFI インターフェースを通して正式にオーバークロックされた場合でも、acpi_cpufreq などのユーティリティに正しいクロック周波数を伝えません。この結果、acpi_cpufreq をアンロードしてブラックリスト化しない限り dmesg は極端なメッセージを表示します。i7z がオーバークロックしたチップのクロック速度を Linux で正しく読むことができる唯一のツールです。
周波数スケーリング
CPU 周波数スケーリングを見てください。
CPU スケジューラを変更
Linux のメインラインカーネルのデフォルト CPU スケジューラは CFS です。
デスクトップコンピュータ用に設計されたスケジューラとして Con Kolivas によって開発された MuQSS が存在します。MuQSS ではデスクトップの即応性・操作性に重点が置かれています。 MuQSS はスタンドアロンのパッチとして使用したり、-ck パッチセットから利用することが可能です。パッチセットについては Linux-ck や Linux-pf を参照してください。
プロセスの優先順位を設定
Ananicy
Ananicy は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、ananicy-gitAUR パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときに実行可能ファイルの優先度を表すものです。
cgroups
cgroups を見てください。
Cpulimit
Cpulimit は特定のプロセスの CPU 使用率を制限するプログラムです。cpulimit をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:
$ cpulimit -l 50 -p 5081
irqbalance
irqbalance はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。irqbalance.service で操作することが可能です。
CPU の脆弱性の緩和をオフにする
CPU の脆弱性の緩和策をオフにすることでパフォーマンスは向上します (最大で 50% ほど向上する場合もあります)。以下のカーネルパラメータで全ての緩和策が無効になります:
mitigations=off
カーネルドキュメント に切り替えるスイッチの説明があります。
グラフィック
Xorg.conf 設定
グラフィックパフォーマンスは主に /etc/X11/xorg.conf の設定に依存しています。NVIDIA, ATI, Intel のカードを使うためのチュートリアルを見ましょう。不適当な設定は Xorg の動作を止めます、警告が参考になるでしょう。
Driconf
driconfAUR はオープンソースドライバのダイレクトレンダリング設定を変えるための小さなユーティリティです。公式リポジトリからインストールできます。HyperZ を有効にすることで劇的にパフォーマンスを向上させることができるかもしれません。
GPU オーバークロック
グラフィックカードをオーバークロックすることは CPU のそれよりも一般的に好都合です、なぜなら、オンザフライで GPU のクロックを調節できる分かりやすいソフトウェアパッケージがあるからです。ATI ユーザーは、amdoverdrivectrlAUR を使って下さい。Nvidia ユーザーは nvclockAUR が必要です。Intel チップセットのユーザーは gmaboosterAUR パッケージで GMABooster をインストールできます。
変更を永続的にするには、X 起動後に適当なコマンドを実行させてください、例えば、~/.xinitrc にコマンドを追加するなど。ただし、必要な時だけにオーバークロック設定を適用させるほうがより安全ではあります。
RAM とスワップ
クロック周波数とタイミング
RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。#オーバークロックを参照。
Swappiness
スワップ#Swappiness を参照してください。
Root on RAM オーバーレイ
書き込みが遅いメディア (USB や HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。liverootAUR を見て下さい。
Zram または zswap
zram カーネルモジュール (旧名 compcache) は RAM に圧縮ブロックデバイスを作成します。スワップデバイスとして Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。zswap を使うことでも同じような利益を享受することができます。
例: lz4 で圧縮する zram デバイスを 32GiB で設定して優先度を通常より高く設定 (現在のセッションのみで有効):
# modprobe zram # echo lz4 > /sys/block/zram0/comp_algorithm # echo 32G > /sys/block/zram0/disksize # mkswap --label zram0 /dev/zram0 # swapon --priority 100 /dev/zram0
無効化するには、再起動するか以下を実行:
# swapoff /dev/zram0 # rmmod zram
起動時に自動的に zram を初期化したい場合、systemd サービスを記述してください。
上記の手順の詳しい説明やオプション、問題点などは こちら のモジュールの公式ドキュメントに載っています。
systemd-swap パッケージに含まれている systemd-swap.service ユニットは自動的に zram デバイスを初期化します。設定は /etc/systemd/swap.conf で行うことができます。
AUR パッケージ zramswapAUR はあなたのシステムに最適な設定で (RAM サイズや CPU コア数にあわせて) スワップデバイスをセットする自動スクリプトを提供します。スクリプトは１つの CPU コアに１つの zram デバイスを作成し、全体のスペースが RAM の量と同じになるようにします。また、標準スワップよりも圧縮スワップに高い優先度を持たせることでデータの圧縮に複数の CPU コアを利用してください。起動時に自動でこれを行わせるには、systemctl を使って zramswap.service を有効にしてください。
グラフィックカードの RAM を使う
搭載している RAM が僅かでビデオ RAM の余りがないような場合でなければ、ビデオ RAM をスワップとして使うことができます。ビデオメモリにスワップを見て下さい。
プリロード
プリロードとは、ターゲットファイルを RAM に置くことです。ハードドライブよりも RAM のほうが速く読み込まれるので、プリロードされたアプリケーションはより早く起動するという利益があります。しかしながら、RAM の一部を（アプリケーションを起動していないときでも）そのために取っておくことになります。したがって、プリロードは Firefox や OpenOffice など巨大でよく使うアプリケーションと一緒に使うのがベストです。
Go-preload
gopreload-gitAUR は Gentoo フォーラム で作成された小さなデーモンです。使うには、まず、起動時にプリロードしたいプログラムごとに、次のコマンドを端末で実行してください:
# gopreload-prepare program
それから、指示通りに、プログラムが完全にロードされたら Enter を押します。これでそのプログラムが必要とするファイルの一覧が /usr/share/gopreload/enabled に追加されます。起動時に全てのリストをロードするには、systemd のサービスファイルを有効にしてください。
# systemctl enable gopreload.service
プログラムのロードを無効化するには、/usr/share/gopreload/enabled の適切なリストを削除するか、/usr/share/gopreload/disabled に移動してください。
Preload
Preload はもっと自動化されたアプローチを取ります。あなたがするべきことは systemd で Preload を有効にすることだけです。
# systemctl enable preload
システムで一番よく使われるファイルを監視して、起動時にプリロードするファイル一覧に組み込みます。
起動時間
ブートパフォーマンスの向上にチュートリアルとヒントがあります。
Suspend to RAM
起動時間を短縮する最適解は全く起動しないことです。Suspend to RAM を使えないか考えてみて下さい。
カスタムカーネル
カスタムカーネルをコンパイルすることで起動時間やメモリ使用量を減らすことができるかもしれません、ただし、逆に増えてしまったり、問題が生じることもありえます。基本的に試す価値はありませんが、面白みを感じたり良い勉強の経験になるかもしれません。どうすればいいのか知りたいのなら、ここから始めて下さい。
ネットワーク
ネットワークプロトコル
Sysctl#パフォーマンスを向上させるを見てください。
NIC
ネットワーク設定#MTU とキューの長さの設定を見てください。
SMB
Samba#パフォーマンスを改善するを見てください。
DNS
接続が作成される度に、TCP/IP スタックは IP アドレスの完全修飾ドメイン名を解決する必要があります。DNS キャッシュサーバーを使って DNS クエリをローカルでキャッシュすることで、ネットワーク要求のレスポンスが改善します。よく使われるツールとして pdnsd, dnsmasq, unbound, rescached などが存在します。systemd サービスの systemd-resolved はローカルアプリケーションにネットワーク名前解決を提供し、デフォルトで DNS キャッシュを行います。詳しくは systemd-resolved(8) を見てください。
Watchdog
- ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。
システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。
ソフトウェアとハードウェアの両方のウォッチドッグタイマーを無効化するには、ブートパラメータに nowatchdog を追加してください。
新しい設定をチェックするには:
# cat /proc/sys/kernel/watchdog
または:
# wdctl
ウォッチドッグを無効化したら、任意でハードウェアウォッチドッグを使うためのモジュールをロードしないようにすることができます。関連するモジュール (例: iTCO_wdt) をブラックリストに追加してください。
ロードされるモジュールが減ることで起動やシャットダウンが高速化されます。さらに、ウォッチドッグを無効にするとパフォーマンスが向上し、消費電力も抑えられます。
詳しくは [4], [5], [6], [7] を参照してください。