「スワップの運用について考えてみる」の版間の差分
ページの作成: == システムにおけるスワップ運用の私見 == Linuxのスワップ ~正確にはページフォルトであるが~ は、どう運用すべきかを考える... |
|||
(同じ利用者による、間の5版が非表示) | |||
1行目: | 1行目: | ||
== システムにおけるスワップ運用の私見 == | == システムにおけるスワップ運用の私見 == | ||
Linuxのスワップ ~正確にはページフォルトですが~ は、どう運用すべきかを考えます。 | |||
まずスワップが必要か、必要でないかといえばスワップ領域は必要です。 | |||
実メモリ(物理的なメモリ)は、プログラムのメモリ空間だけではなく、I/Oのキャッシュバッファとしても使われます。 | |||
プログラムが使わなくなったメモリ空間を抱えていて、一方でパフォーマンスのために必要なI/Oのキャッシュバッファが十分に確保できないのでは本末転倒です。使わなくなったメモリ空間をスワップに追い出すことができれば実メモリを有効に活用できることになります。 | |||
古くから「メモリサイズの2倍か3倍のサイズを取る」というのが慣習的に行われています。 | |||
しかし、この数字はベストプラクティスであって、理論的背景があって決められている数字ではありません。 | |||
一律の値ではなく、稼働させるアプリケーションと搭載メモリ量、そしてハードディスク搭載容量に依存するのはいうまでもありません。 | |||
* Red Hat Enterprise Linux [http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s2-diskpartrecommend-ppc.html 推奨されるパーティション分割スキーム] | * Red Hat Enterprise Linux [http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s2-diskpartrecommend-ppc.html 推奨されるパーティション分割スキーム] | ||
10行目: | 19行目: | ||
* Solaris のシステム管理 (デバイスとファイルシステム) [http://docs.oracle.com/cd/E19253-01/819-0386/fsswap-31050/index.html スワップ空間の計画] | * Solaris のシステム管理 (デバイスとファイルシステム) [http://docs.oracle.com/cd/E19253-01/819-0386/fsswap-31050/index.html スワップ空間の計画] | ||
これらの例からわかるのは「4GBぐらいのメモリ量の場合は、同等なスワップ領域であるが十分なメモリ量がある場合、スワップ領域はメモリサイズよりもはるかに少ない。」 | |||
「もし256GBのメモリ量で3倍のサイズとなると750GBとなり、現状、大容量ハードディスクが安くなったからといっても大きな領域を必要となり、システムを圧迫する。」ということです。 | |||
つまり搭載しているメモリやハードディスクだけに着目して、スワップ領域のサイズを決定するのは、何か決定的な根拠があるわけではなく、ただこれくらいあれば良いだろうという目安程度の話になっていると考えられます。 | |||
あくまでも利用するマシンでどのようなアプリケーションがどのような形で動作し、また、どこまで耐えるのか、ということがポイントであり、汎用な最適なスワップ領域サイズの解はないともいえます。 | |||
== 自分はどうしているか == | |||
では私自身はどうしているかというと、搭載されているメモリ量ではなく、ハードディスクのパーティションを切る際に余った領域をスワップ領域に割り当てる方法を取っています。特定のスワップ領域のサイズをターゲットにして取っているわけではありません。 | |||
必要なパーティションを切っていって、最後余った領域をスワップパーティションとして残しています。1つのハードディスクでせいぜい数GB程度であり、現在数百GBから1TBを越えるハードディスクが利用される現在では、数GBはハードディスク領域としては無視出来るサイズです。尚、複数のハードディスクにスワップ領域を分散させるのは、高速化を狙っているためです。 | |||
20行目: | 38行目: | ||
; 補足 : 近年ではSSDのような高速な外部記憶装置があるので、そもそもスワップ領域を分散させる必要性は小さいかも知れませんし、また分散させるとなるとハードディスク時代には手に入らなかったような高速なスワップ領域になるでしょう。 | |||
== まとめ == | |||
簡単にまとめると以下のようになります。 | |||
* スワップの領域を確保することは必要です。 | |||
* アプリケーションや利用状況に関係なく汎用的に適切なスワップ領域サイズというものはありません。 | |||
* スワップ領域を決める時は慣用的なサイズで設定する場合が多いが、その根拠はきわめて曖昧です。 | |||
* 古典的なメモリ量の2倍のスワップ領域というのは、現在の大容量メモリ搭載時代では、あまり合理的な方法とはいえません。 | |||
* 複数のハードディスク上のパーティションを同時に利用する場合、個々のパーティションサイズは小さくとも総量としては大きい領域が確保できます。 | |||
---- | |||
[[目次]]へ | |||
2020年2月17日 (月) 03:27時点における最新版
システムにおけるスワップ運用の私見
Linuxのスワップ ~正確にはページフォルトですが~ は、どう運用すべきかを考えます。
まずスワップが必要か、必要でないかといえばスワップ領域は必要です。
実メモリ(物理的なメモリ)は、プログラムのメモリ空間だけではなく、I/Oのキャッシュバッファとしても使われます。
プログラムが使わなくなったメモリ空間を抱えていて、一方でパフォーマンスのために必要なI/Oのキャッシュバッファが十分に確保できないのでは本末転倒です。使わなくなったメモリ空間をスワップに追い出すことができれば実メモリを有効に活用できることになります。
古くから「メモリサイズの2倍か3倍のサイズを取る」というのが慣習的に行われています。
しかし、この数字はベストプラクティスであって、理論的背景があって決められている数字ではありません。
一律の値ではなく、稼働させるアプリケーションと搭載メモリ量、そしてハードディスク搭載容量に依存するのはいうまでもありません。
- Red Hat Enterprise Linux 推奨されるパーティション分割スキーム
- Solaris のシステム管理 (デバイスとファイルシステム) スワップ空間の計画
これらの例からわかるのは「4GBぐらいのメモリ量の場合は、同等なスワップ領域であるが十分なメモリ量がある場合、スワップ領域はメモリサイズよりもはるかに少ない。」
「もし256GBのメモリ量で3倍のサイズとなると750GBとなり、現状、大容量ハードディスクが安くなったからといっても大きな領域を必要となり、システムを圧迫する。」ということです。
つまり搭載しているメモリやハードディスクだけに着目して、スワップ領域のサイズを決定するのは、何か決定的な根拠があるわけではなく、ただこれくらいあれば良いだろうという目安程度の話になっていると考えられます。
あくまでも利用するマシンでどのようなアプリケーションがどのような形で動作し、また、どこまで耐えるのか、ということがポイントであり、汎用な最適なスワップ領域サイズの解はないともいえます。
自分はどうしているか
では私自身はどうしているかというと、搭載されているメモリ量ではなく、ハードディスクのパーティションを切る際に余った領域をスワップ領域に割り当てる方法を取っています。特定のスワップ領域のサイズをターゲットにして取っているわけではありません。 必要なパーティションを切っていって、最後余った領域をスワップパーティションとして残しています。1つのハードディスクでせいぜい数GB程度であり、現在数百GBから1TBを越えるハードディスクが利用される現在では、数GBはハードディスク領域としては無視出来るサイズです。尚、複数のハードディスクにスワップ領域を分散させるのは、高速化を狙っているためです。
- 補足
- 近年ではSSDのような高速な外部記憶装置があるので、そもそもスワップ領域を分散させる必要性は小さいかも知れませんし、また分散させるとなるとハードディスク時代には手に入らなかったような高速なスワップ領域になるでしょう。
まとめ
簡単にまとめると以下のようになります。
- スワップの領域を確保することは必要です。
- アプリケーションや利用状況に関係なく汎用的に適切なスワップ領域サイズというものはありません。
- スワップ領域を決める時は慣用的なサイズで設定する場合が多いが、その根拠はきわめて曖昧です。
- 古典的なメモリ量の2倍のスワップ領域というのは、現在の大容量メモリ搭載時代では、あまり合理的な方法とはいえません。
- 複数のハードディスク上のパーティションを同時に利用する場合、個々のパーティションサイズは小さくとも総量としては大きい領域が確保できます。
目次へ