スワップ性を10〜20に減らすことをほとんどの人が推奨するのはなぜですか？
私はいくつかのサイトで、パフォーマンスを向上させるために交換可能性を10〜20に減らすことを推奨しています。
- http://community.linuxmint.com/tutorial/view/998
- https://sites.google.com/site/easylinuxtipsproject/bugs
- http://www.howtogeek.com/115797/6-ways-to-speed-up-ubuntu/
- http://www.upubuntu.com/2012/06/11-tips-to-speed-up-computers-running.html
それは神話かどうか？これは一般的なルールですか？ 4GB RAMと128GB SSDを搭載したラップトップを持っていますが、私の交換にはどのような価値がありますか？
ありがとう。
ほとんどの人は、スワッピング=悪いと信じており、swappinessを減らさないと、システムは本当に必要のないときにスワップすると信じています。どちらも本当ではありません。人々は、スワッピングをシステムが行き詰まっている時間に関連付けます-しかし、それはほとんどスワッピングですbecauseシステムは行き詰まり、その逆ではありません。システムがスワップするときは、スワップの決定にパフォーマンスコストをすでに考慮しており、そうしないとシステムのパフォーマンスまたは安定性に大きなペナルティが生じると判断しました。
全体的にデフォルト設定により、全体的なパフォーマンスと安定性が向上します。デフォルトのままにしておくことをお勧めします。 Linuxがメモリ管理を改善していくつかのEdgeのケースを解決する手段はさらにありますが、概して、swapinessコントロールは回避策としては適切ではありません。可能な限り、単に物理的なRAMをインストールするだけで（そしてスワップ性をそのままにして）、他のすべての救済策を覆します。
LinuxがRAMを使用する方法
アプリケーションで使用されていないRAMは、「キャッシュ」として使用できます。キャッシュは、高速でスムーズに実行されるシステムにとって重要であり、ディスクへの読み取りと書き込みの両方を高速化します。
アプリケーションのメモリ使用量がほぼすべてのRAMを使用する程度まで増加すると、キャッシュが縮小し、結果としてディスク操作が平均的に遅くなります。最近のキャッシュでは、数十メガバイト以下で十分ではありません。
スワップスペースがないと仮定して、アプリケーションのメモリ使用量がさらに増加すると、キャッシュ用のスペースがなくなるだけでなく、最終的にメモリが不足し、システムは実行中のプロセスを強制終了する必要があります。プロセスを強制終了すると、システムが不安定で予測不能になるため、速度低下よりも悪化します。
Linuxがスワップを使用する方法
これらの問題の両方に対処するために、システムは、めったに使用されないアプリケーションメモリをディスク上のスワップ領域に再割り当てして、RAMを解放できます。追加のRAMは、メモリ不足によるプロセスの停止を防ぎ、ディスク操作がよりスムーズに動作できるように、少量のキャッシュを回収できます。
ただし、この再割り当ては、明確なカットオフに従って行われません。 Linuxがスワッピングを開始するまでの割り当ての特定の割合に達していない。 「ファジー」アルゴリズムがあります。それは多くのことを考慮に入れていますが、これは「メモリ割り当てにどれほどのプレッシャーがあるか」で最もよく説明できます。新しいメモリを割り当てるために多くの「プレッシャー」がある場合、より多くのスペースを確保するためにスワップされる可能性が高くなります。 「プレッシャー」が少ない場合、これらの可能性は減少します。
システムには、この「圧力」の計算方法を微調整するのに役立つ「swappiness」設定があります。多くの場合、「RAMの割合」として誤って表されますが、そうではなく、単に式の一部として使用される値です。 40から60前後の値が推奨される適切な値であり、最近では60がデフォルトです。
RAMがたくさんある場合でも、システムを必要なときにスワップさせることは、全体として非常に良いことです。必要に応じてシステムを交換すると、一時的にでも（多くのメモリを使用する短いプロセスを実行中に）低メモリ状態に陥った場合に、システムがすべてを実行し続けるチャンスを得ることができます。スワップを完全に無効にする場合、メモリを割り当てることができないためにプロセスが強制終了される危険があります。
システムが動かなくなり、頻繁にスワッピングされるとどうなりますか？
スワップは低速でコストのかかる操作であるため、キャッシュパフォーマンスのトレードオフで全体を補うと計算しない限り、またはプロセスの強制終了を回避する必要がある場合、システムはそれを回避します。
多くの場合、人々はディスクをひどくスラッシングしているシステムを見て、多くのスワップスペースを使用し、それをスワッピングのせいにします。それは取るべき間違ったアプローチです。スワップがこの極端に達する場合、スワップは問題の原因ではなく、メモリ不足の問題に対処するためのシステムの試みであり、実行中のプロセスをスワップせずにランダムに停止することを意味します。
デスクトップシステムについてはどうですか？別のアプローチが必要ではないですか？
実際、デスクトップシステムのユーザーは、アプリケーションを開くなど、ユーザーが開始したアクションに応答してシステムが「応答性を感じる」ことを期待しています。
一部の人々がこれを微調整しようとする1つの方法は、swappinessパラメータを減らすことです。これにより、メモリを使用し、キャッシュスペースが不足しているアプリケーションに対するシステムの許容範囲が増加します。
しかし、これはゴールポストを変えるだけです。最初のアプリケーションは、スワップ操作なしでロードできるようになりましたが、ロードする次のアプリケーションのスラックが少なくなります。代わりにアプリケーションを次に開いたときに、同じスワッピングが後で発生する場合があります。その間、キャッシュサイズが縮小されるため、システムのパフォーマンスは全体的に低下します。したがって、swappiness設定の削減によるメリットは測定が難しく、場合によってはスワッピングの遅延は減少しますが、他の場合はパフォーマンスが低下します。何をしているのかわかっている場合は、swappinessを少し減らすことは正当化されますが、10％にまで減らすと、システムが非常に低いキャッシュサイズに耐えられるようになり、システムがすぐにスワップしなければならなくなる可能性が高くなります。
プロセスがクラッシュしたり強制終了したりする可能性があるメモリ不足状態に対する追加の保護が失われるため、スワップを完全に無効にすることは避けてください。
最も効果的な解決策は、余裕がある場合は_RAMを追加インストールすることです。
とにかくRAMがたくさんあるシステムでスワップを無効にできますか？
アプリケーションに必要と思われるよりもはるかに多くのRAMがある場合、スワップはほとんど必要ありません。スワップを無効にしても、ほとんどの場合、おそらく違いはありません。ただし、RAMが十分にある場合は、システムは必要のないときにスワップしないので、スワップを有効にしてもペナルティはありません。
would違いが生じる唯一の状況は、システムがメモリを使い果たしている可能性があり、その結果、キャッシュシステムが妨げられているという状況にあります。 want最もスワップします。したがって、十分なメモリがある場合に悪影響を与えることなく、追加の安心のために通常の設定でスワップを安全に残すことができます。
しかし、どうすればシステムの速度を上げることができますか？遅いものを入れ替えないのですか？
RAMからスワップにデータを転送する動作は遅い動作ですが、適切なキャッシュサイズを維持することの結果としての全体的な利点がこれを上回るとカーネルがかなり確信している場合にのみ行われます。
一度データがスワップされると、いつ再びデータが出ますか？
メモリの特定の部分は、使用されるとすぐにスワップから復帰します-読み取りまたは書き込み。ただし、通常、スワップされるメモリは、長時間アクセスされておらず、すぐに必要になるとは予想されないメモリです。
スワップからデータを転送するには、そこにデータを入れるのと同じくらい時間がかかります。必要のないカーネルは、カーネルからデータを削除しません。データはスワップ状態で使用されていませんが、使用されている他のもののためにより多くのメモリを残しますare使用され、システムキャッシュが増加します。
swapinessを減らすことが適切な場合はありますか？
はい。システムキャッシュの恩恵を受けない特定のサーバーアプリケーション専用のサーバーを実行している場合。 Oracleサーバーなどの一部のデータベースサーバー、MySQL/MariaDBでは、これらのデータベースエンジンが独自のキャッシュを使用するため、swappinessを1〜10に減らすことを推奨する場合があります。
これは、システムがその1つのタスク専用である場合にのみ当てはまることに注意してください。MySQL/ MariaDBの場合は、MyISAMやAriaなどではなく、純粋にInnoDBまたはXtraDBを使用している場合のみです。
通常のデスクトップでは、メモリの50〜60％を消費する4〜5個のアクティブなタスクがあります。 swappinessを60に設定すると、アクティブなタスクページの約1/4〜1/3がスワップアウトされます。つまり、タスクの変更ごと、開いた新しいタブごと、JSの実行ごとに、スワッププロセスが発生します。
解決策は、swappinessを10に設定することです。実際の観察では、これによりシステムはディスクioキャッシュを放棄します（読み取り/書き込みキャッシュは事実上まったく使用されないため、デスクトップではほとんど役割を果たしません。ファイル）をスワップにプッシュする代わりに。実際には、システムがページのスワップを拒否し、使用済みメモリの90％に達しない限り、代わりにioキャッシュをカットします。そしてそれは、スムーズでスワップレスで高速なデスクトップエクスペリエンスを意味します。
ただし、ファイルサーバーでは、swappinessを60以上に設定します。サーバーには、メモリ全体に保持する必要がある巨大なアクティブフォアグラウンドタスクがなく、むしろ動作中またはスリープ中の小さなプロセスが多数あるためです。実際にすぐに状態を変更するわけではありません。代わりに、サーバーは多くの場合、まったく同じデータをクライアントに提供（恩赦）し、ディスクioキャッシュの価値を高めます。そのため、サーバーでは、スリーププロセスをスワップアウトして、ディスクキャッシュリクエスト用のメモリスペースを解放する方がはるかに優れています。
ただし、デスクトップでは、この正確な設定により、このデータをほぼ絶えず変更またはアクセスするREALアプリケーションのメモリブロックがスワップアウトされます。
奇妙なことに、ブラウザは頻繁に大きなメモリチャンクを予約し、常に変更します。そのようなチャンクがスワップアウトされると、それらが戻されるように要求された場合、しばらく時間がかかります。同時に、ブラウザーはキャッシュを更新し始めます。これは非常に大きな遅延を引き起こします。実際には、新しいタブの単一のWebページがロードされるまで2分間待機します。
デスクトップは、データの大きな部分を繰り返しキャッシュ可能に読み書きすることはめったにないので、実際にはdisk ioを気にしません。スワップを可能な限り防ぐためにディスクioをカットすることは、デスクトップのメモリの30％をRAM（アクティブな使用済みアプリケーション）スワップアウト。
Htopを起動し、ブラウザ、GIMP、LibreOfficeを開いて、そこにいくつかのドキュメントをロードしてから、数時間ブラウズします。本当に簡単です。
LinuxシステムでJavaサーバーを実行する場合は、swappinessをデフォルト値の60から大幅に減らすことを実際に検討する必要があります。したがって、20は実際に良いスタートです。スワップは、毎回コレクションがプロセスメモリの大部分に触れる必要があるため、ガベージコレクションプロセスにとって致命的です。 OSには、そのようなプロセスを検出し、それらに適したものを取得する手段がありません。生産的なアプリケーションサーバーで可能な限りスワッピングを避けることをお勧めします。
システムモニターを開いてマシンの負荷を正確に確認しながらいくつかの実験を行うことをお勧めします。また、4GBのメモリと128GB SSDで実行しているため、swapiness値を10に変更しました。ボーナスとして、書き込みが少なくなるため、SSDドライブの寿命も長くなります。
これを行う方法に関する簡単なビデオチュートリアルについては、以下のYouTubeビデオを参照してください。
ビッグデータパフォーマンスエンジニアの視点を追加して、2017年のテクノロジーに関する他の人の背景を説明したいと思います。
私の個人的な経験では、特定の問題のためにワークステーションでシステムが最大速度で実行されることを保証するために通常スワップを無効にしていますが、1と10のスワップはフリーズ（永久）と長い一時停止につながることがわかりました。この特定のアプリケーションの80のSwappinessは、デフォルト（60）よりもはるかに優れたパフォーマンスと短い休止時間をもたらします。 8GB RAMと1個のHDDでバックアップされた4x 256GBのスワップがあることに注意してください。私は通常、ベンチマークと完全なハードウェア仕様に見られる正確な統計情報を述べますが、私はまだ何もしておらず、ここでは重要ではない最近のローエンドのデスクトップです。
前の会社に戻って、[500GB〜4TB] x [10-100]ノードのSparkサーバーでスワップ可能性を有効にしなかったのは、データパイプラインを再設計するための兆候としてパフォーマンスの低下が見られたためですより効率的な方法でデータ構造。また、HDD/SSDのベンチマークも行いたくありませんでした。また、その程度のRAMをスワップするには、ディスクへのアクセス時間を最小限に抑えるために、ノードごとに並列書き込みで10〜30個のディスクが必要になります。
今日、20年前と20年先の未来において、いくつかの問題はRAMにとって大きすぎるという問題が残っています。無限の時間とお金で、より多くのハードウェアを購入/リースしたり、任意のプロセスを再設計してパフォーマンスを望ましいレベルにすることができます。スワッピングは、実際の問題を無視できるようにするための単なるハックです（十分なRAMがないため、これ以上お金を使いたくありません）。
高い交換性が悪いアドバイスだと思う人のために、ここに少しの視点があります。過去には、HDにはわずか数KBのキャッシュしかありませんでした。インターフェースはIDE/Parallel ATAでした。 CPUバスもRAMおよびその他多くのものとともに非常に低速でした。要するに、システムはあらゆる点で（今日に比べて）非常に低速でした。数年前、HDDはSATA3を使用していました。今日、彼らはNVMeプロトコルを使用していますが、これは大幅にレイテンシーが改善されています。 HDには多くのMBのキャッシュがあります。そして、最も興味深い部分は、スワップストレージとしてNVMeまたはPCIeを備えた最新のSSD（はるかに安定した読み取り/書き込み耐久性とパフォーマンス）を使用する場合です。コストとパフォーマンスの最適な妥協点です。安価または古いSSDでこれを試さないでください。
Swap + SSD！高性能の揮発性ストレージでは、高いスワップ可能性の値を試すことを強くお勧めします。これは主に、メモリアクセスパターン（すべてのメモリへのランダムアクセスとほとんどアクセスしないこと）、メモリ使用量、ディスク帯域幅が既に飽和している場合、およびスラッシングの実際のコストに依存します。
起動時またはプログラムを開いたときに認識されるスワッピング動作の多くは、Linuxがディスクから設定ファイルなどを読み取ることです。そのため、ハードドライブへのアクセスがスワッピングによるものであると想定する前に、システムモニタープログラムを使用して確認するのが最善かもしれません。