スワップなしでOracleサーバーを実行できますか？
オラクルの公式ドキュメントによると、RAM）が16GiBを超えるマシンでは、16GiBのスワップを割り当てる必要があります。
私たちのサーバーはRHEL 7で、256GiBのRAMを搭載しています。
DBAはシステムスワップを見たくないので、16GiBのスワップを非常に積極的に監視する必要があります。
RAM to 512GiB（費用は承認されています））を2倍にしてスワップを無効にすることを提案しました。ただし、RAMを2倍にしても、16GiBのスワップを使用するというOracleの推奨に反します。
正直なところ、スワップの3％がどのように意味をなすか、またはRAMをスワップよりも多く追加する場合、スワップを維持する必要があるのはなぜかわかりません。
それで、スワップなしでOracleを実行することを正当化するために使用できる良い議論はありますか？
追伸RAMの2倍化について言及する唯一の理由は、私が論じるのに苦労している議論のばかげていることを示すためです。私が本当に探しているのは、スワップの無効化を正当化するための議論です。
スワップを無効にすることは良い考えです
- ソフトウェアがメモリ不足の状態を適切に処理したり、OOMの状況を回避するためにソフトウェア自体を制限したりできる
- 一貫したパフォーマンスを維持することは重要です（システムがスワッピングを行うとレイテンシが増加し、多くのアプリケーションで効果的に役に立たなくなるほど悪くなる可能性があります）
この種のことは、データベースでよく起こります。 noSQLデータベースを使用するとさらに多くのことがわかりますが、リレーショナルデータベースでも同じ問題が発生する可能性があります。
そこにスワップが必要なOSには何もありません。 Linuxは、メモリを要求した最後のプロセスを強制終了することにより、これをかなり優雅に扱います。その時点に到達したくないので、Oracleを調整してメモリの約90％のみを使用するようにしてください。そうすることで、システムデーモンのために残された部分とエラーのためのマージンがあります。 「空き」メモリは、ディスクI/Oのバッファリングにも使用されます。これは、パフォーマンスの大きなメリットです。データベース自体がより多くのメモリを消費しようとすると、最終的にシステム全体のパフォーマンスが低下し、逆効果になります。
アプリケーションがデータベースであるか、キャッシュであるか、または同様のシステムであるかという問題のメモリの一部を備えたシステムを使用している場合でも、この時点ではデフォルトでスワップしないようにします。
当局
my Wordだけに依存しないように：
Cassandra
Datastax はCassandraについて説明します：
スワップを完全に無効にする必要があります。そうしないと、パフォーマンスが大幅に低下する可能性があります。 Cassandraには複数のレプリカと透過的なフェイルオーバーがあるため、スワップが発生するのではなく、メモリが不足したときにレプリカをすぐに強制終了することをお勧めします。これにより、代わりに機能しているレプリカにトラフィックをすぐにリダイレクトできますスワッピングのためにレイテンシの高いレプリカにヒットし続けること。システムに大量のDRAMがある場合でも、OSが実行可能コードをスワップアウトするため、スワップによりパフォーマンスが大幅に低下し、ディスクのキャッシュにより多くのDRAMを使用できるようになります。
リアク
Basho はRiakについて次のことを説明しています：
理想的には、Riakのプロセスページがスワップされないように、スワップを無効にする必要があります。スワップを無効にすると、メモリ不足の場合にRiakがクラッシュします。これにより、
erl_crash.dumpという名前のクラッシュダンプファイルが/var/log/riakディレクトリに残り、これを使用してメモリ使用の原因を特定できます。
mysql
Percona はフェンスに座っており、質問の両側に役立つ警告を提供します。 MariaDB はスワップの無効化に同意しません：
スワップを完全に無効にし、データベースプロセスによる使用を避けたい場合もありますが、少なくともスパイクが発生した場合にカーネルが適切にフォールオーバーできるように、スワップスペースを残しておくのが賢明です。緊急時のスワップを利用できるようにすると、暴走したプロセスを強制終了するためのスコープが許可されます。
ServerFault
ここで評判の良い回答 には以下が含まれます：
私は個人的に、クラッシュしたシステムよりもスワッピーなシステムを見つけました。システムがクラッシュすると、スタンバイバックアップサーバーが引き継がれます。また、アクティブ-アクティブ（または負荷分散されたセットアップ）では、クラッシュしたシステムの回転がはるかに早く停止します。再びスワップなしシステムの勝利。
その回答は今日22の賛成票を持ち、4歳です。スワップの価値を称賛する他のいくつかの回答も見ることができますが、それらがデータベースを実行していることを示すものはありません。賛成票もそれほど多くありません。 :)
いか
彼らはイカの男をスワップすることを無効にすることを明らかにお勧めしませんが say ：
Squidは、記憶を独り占めする傾向があります。それは多くの異なるもののためにメモリを使用し、そのいくつかは他のものより制御するのが簡単です。 SquidプロセスのサイズがシステムのRAM容量を超える場合、プロセスの一部をディスクに一時的にスワップする必要があるため、メモリ使用量は重要です。他のメモリを大量に消費するアプリケーションを実行している場合も、スワップが発生する可能性があります。同じシステム上でスワップすると、Squidのパフォーマンスが急速に低下します。
それはあなたがあなたのデータベースに起こりたくないことです。
redis
Redis はswap を公式に推奨していますが、ユーザー はそれを購入しないでください ：
最初にスワップを無効にします-Redisとswapは簡単に混ざりません。これは確かに速度低下を引き起こす可能性があります。
ハドープ
に示されているように、hortonworksコミュニティで最も多く投票されているこの回答 ：
分散サービスしかないslave/worker/data hostsの場合、スワップを無効にすることができます。分散サービスでは、スワップではなくプロセス/ホストを強制終了することをお勧めします。そのプロセスまたはホストを強制終了しても、クラスターの可用性には影響しません。別の言い方をすれば、「ゆっくりと劣化するのではなく、「すぐに失敗する」のです。
[....]
mastersの場合、Hortonworksからのセットルールではありませんが、スワップも無効にされることがよくあります。マスターは、Hadoop以外の他の環境でマスターを扱うように、いくらか扱うことができます。
マスターでスワップを無効にすることへの懸念は、OOM（メモリ不足）イベントがクラスターの可用性に影響を与える可能性があることです。しかし、それはスワップが設定されていても起こります、それはわずかに長くかかります。管理者/オペレーターの適切なプラクティスは、RAM可用性を監視してから、メモリ不足になる前に問題を修正することです。したがって、パフォーマンスに影響を与えずに可用性を維持します。その場合、スワップは不要です。
Javaアプリについて話しているのでこれが好きですが、データベースについて前述した同じ結論の多くに達します。また、monitoringこれは、高性能アプリケーションの調整に非常に役立ちます。比較する数値がない場合、すべてを比較するのは難しい感情に基づいています。測定可能なすべてのメトリック（アプリケーションレベルのレイテンシとCPU、ディスク、メモリ、ネットワークグラフまでのスループットこれらは、決定を下さなければならない実際のデータの大部分を提供します。
Alex on Linuxは、このテーマに関して興味深い読み物があります：「スワップとスワップなし」 http://www.alexonlinux.com/swap-vs-no-swap
要するに、スワップなしの場合です。
- システムの安定性が低下します。
- システムのディスクアクセス速度は、スワップパーティションを持つシステムと比較して遅くなります。また、時間の経過とともにディスクアクセス速度が低下します。
このトピックは頻繁に表示されます。スワップはRAMの拡張にすぎないので、RAMを追加購入しましょう。違う。 16 GiB swap and 512 GiB RAM makeperfect経済的な意味です。
メインソフトウェアをよく理解していれば、かなり正確にどれだけの「愚かな」メモリが必要かがわかります。 「愚かな」記憶とは？ 最初はRAMに表示されるさまざまなコードとデータですが、再びクリティカルに必要になることは決してありません。つまり、このようなものはメモリですぐに利用できないため、ユーザーから見たパフォーマンスが低下することはありません。
ソフトウェアを修正する代わりに、その量のスワップを与えるだけでその量。はい、スワップを100％使用します。それがポイントです。スワップを増やしてはいけません。さもないと、いくつかの重要なものが誤ってそこに置かれる危険があります。それを文書化すれば、100％のスワップ使用量に気を取られない人もいます。 Oracleの場合、その量は16 GiBであり、私の経験から、それが使用されても、 700 GiBボックス、そしてパフォーマンスに影響を与えるswpinは発生しません。
実際には、16 GiB of RAM=実際の作業を行い、ユーザーに利益をもたらすことができます。2017年の時点で、組織のコストが約50ドル削減されます。サーバーに256 GiB RAMの場合、スワップを構成して$ 50を節約します。サーバーに10 TiB RAMがある場合、スワップを構成して保存します... $ 50。参照してください。それでも同じです。
現在、スワップをゼロにすることは常にsafeです。それは単にあなたにその小さな50ドルの費用がかかる、それがすべてです。
組織が100％使用済みのスワップを処理できない場合（たとえば、別の監視チームなど）は、それを行わないでください。この問題について誰かに考えさせると、彼らの時間の50ドルはすでに無駄になっています。
一部のベンダーは、メモリの無駄をゼロにしています。また、一部のベンダーは、「愚かな」割り当て量を見積もるのに十分な自信がないため、「ゼロスワップ」と言って、お金を節約するだけで未知の問題を回避しています。それも大丈夫です！私はこれに関してベンダーを信頼します、彼らはインストールをサポートします、彼らは彼らのものを知っています。
未使用のページに対して妥当な量のスワップを保持せず、vfsキャッシュプレッシャーを変更して、OOM状態の場合にのみスワップするようにスワップネスを変更します。また、Oracleプロセスをメインメモリに固定して、ディスクに触れないようにすることもできます。これは、低速のIOシステムにヒットしても影響を受けないデータベースを満たし、データベースとバッファーとキャッシュによって使用されるメインメモリからガベージを解放することを可能にします。これは両方の長所です。