スワップをしているのですか？
Linuxでは、Windowsシステムの下SWAP「仮想メモリ」の役割に似ています。アウトするとき、物理メモリ、ディスク空間部不足メモリ容量の場合に対処するために、場合パーティションスワップ（仮想メモリ）の使用。
SWAPは、メモリのうちOSに検出要求のプロセスは、OSが一時的に未使用のデータ・メモリスワップパーティション上で、このプロセスはSWAPのOUTと呼ばれ、スワップアウトされます定義によって、交換手段です。プロセスは、彼らがこれらのデータを必要とし、そこにOS際に空き物理メモリことが判明し、物理メモリへのデータのスワップパーティションのバックを交換するときは、このプロセスは、SWAPで呼び出されます。
スワップは使用を終了したら、もちろん、スワップのサイズの上限があり、オペレーティングシステムがメモリを解放するために殺すメモリプロセスのほとんどを消費するOOM-キラーメカニズムをトリガーします。
なぜ軽蔑データベースシステムスワップ？
どうやら、スワップ機構の本来の意図は、物理メモリがなくなると残酷ダイレクト選択プロセスをOOMの恥ずかし容易にするためです。しかし率直に言えば、スワップ上のほとんどすべてのデータベースは、MySQL、Oracal、MongoDBのかHBaseの、なぜかどうかを確認する方法はないでしょうか？これと、次の2つの側面：
スワップ・メモリ、必ずしも許容できないデータベース・サービスのパフォーマンスを使用して代わりの場合は1データベースシステムは、一般的に応答遅延に対してより敏感です。システムの非常に敏感な応答遅れが懸念されるために、遅延が大きすぎるとサービスが......あればもう一度考えてみて、どのシステムが使用不能にされたことを意味し、サービス利用できませんが、もっと真剣に、スワップシナリオの下でプロセスが死ぬことはないよりも、違いはありません使用できません。 OOMスワップが直接使用されていない、より良い選択は、マスターサーバーシステムからそう多くはない、実質的に、ユーザの認識なしに、直接オフになります。
例えばHBaseのような分散システムのこのタイプに加えて2は、実際には、離れたノードぐずぐずする心配はないが、むしろライブノードラムの恐れ。最高の状態で、リクエストに簡単に利用できない、再試行の小さな部分を復元することができ、ノードを撃墜します。しかし、ノードはラムラムは、すべての要求が配布されて生きて生きてます、サーバー側のリソースが占有されていると、クラスタ全体の要求ブロッキングを起こし、糸を保持し、さらにはクラスタの崩壊。
スワップはまだ非常に合理的であるように、ビューのこれらの二つの観点から、すべてのデータベースはしないでください！
スワップ作業メカニズム
データベースを確認するために、スワップ待たなければならないので、ディスクキャッシュの特殊性をオフにするswapoffコマンドを使用する必要はありませんか？いいえ、あなたは近いディスクが意味するキャッシュかについて考えることができますか？実際の生産環境はとても過激になり、あなたはこの世界は常に0か1のどちらかではありません知っている、私たちは途中で多かれ少なかれ行くことを選択しますが、一部は0に傾向があり、1およびいくつかの賛成それシステムではありません。もちろん、スワップでは、この問題は、できるだけデータベース必然的バイアスを選択します。いくつかの要求は、実際にこのポリシーを実装する公式文書をHBaseの：可能な限りスワップの影響を低減することができます。把握しなければならないスワップの影響を低減するために、自分自身が自分自身を知ることを知っていることはすべての可能な疑いをお見逃しなくするように、どのようにLinuxのメモリ復旧作業です。
スワップがトリガされた方法で見てみましょうか？
要するに、Linuxは1がメモリ割り当てで発見され、2つのシナリオでは、ガベージコレクションがトリガされますすぐにトリガするとき、メモリに十分な空きメモリの回復ではありません。一つは定期的なシステムのために（swapdプロセス）デーモンを開いていますメモリチェック、特定のしきい値の後に減少し、アクティブトリガメモリの回復に使用可能なメモリ。下記に示すように、第1のシーンは、2つ目のシナリオの焦点について話をし、何も言うことはありません。
vm.min_free_kbytes、代表的なシステムの透かしの最小空きメモリ[分]保持を透かし[低]、および[高]透かしに影響を与える：ここでは、最初のパラメータに注目をリードしなければなりません。シンプルに考えることができます。
透かし[分] = min_free_kbytes 透かし[低] =透かし[分]×5/4 = min_free_kbytes * 5月4日 透かし[高] =透かし[分]×3/2 = min_free_kbytes * 3月2日 透かし[高] -透かし[低] =透かし[低] -透かし[分] = min_free_kbytes / 4
目に見える、これらのパラメータmin_free_kbytes水ラインと不可分のLINUX。min_free_kbytesシステムの重要性は、どちらも大きすぎるたり小さすぎ、自明です。
小さすぎる、との間のレベル緩衝場合min_free_kbytes [分、低]はkswapdの過程で、小さくなりすぎて、高速（典型的な応用：データベース）後、上位層アプリケーション・メモリを回収し、それが容易に低減空きメモリにつながります透かし[分]以下、カーネルは、アプリケーションのプロセスのコンテキストに直接リサイクル、直接再利用（直接リサイクル）すること、およびそのアプリケーションを満たすために、メモリの空きページを回復しますので、実際のブロックアプリケーション、持参特定の応答遅れ。もちろん、min_free_kbytesは、他の一方で、あまりにも多くの片手には、システムメモリリソースの無駄を削減するために、アプリケーション・プロセスのメモリを引き起こし、リードkswapd大きすぎるすべきではないプロセスメモリのリコールに多くの時間を費やしています。このプロセスを見て、古い世代の回復に非常に類似したCMSのトリガ機構でJavaのガベージコレクションアルゴリズムではありません、パラメータ-XXについて考える：CMSInitiatingOccupancyFractionは、それではないでしょうか？公式文書要件min_free_kbytesを容易に直接リサイクルを誘発されていない、1G（8G大容量メモリシステムで設定）よりも小さくありません。
このように、Linuxのメモリ・リカバリ・トリガ機構の基本的な解釈と最初の引数は、私たちの注意をvm.min_free_kbytes。次に、Linuxのメモリの回復がリサイクルされているもので、簡単なルック。Linuxのメモリの回復は主に次の2つのタイプに分けられます。
1.ファイルキャッシュ、これは回避ファイルにハードディスクから各時間データは、システムのパフォーマンスを向上させるためにメモリに保存されているホットデータとなることを理解しやすいです。あなたが唯一のメモリ回復の外にファイルを読み込むだけで、このメモリを解放する必要があることができれば、次回も読んでファイルデータは、（HBaseのファイルキャッシュに似ています）ハードディスクから直接読み取ることができます。あなたがそのファイルだけを読み出し、ファイルをキャッシュされたこれらのデータは（汚い）を変更した場合は、メモリの回復は、あなたがして（MySQLのファイルキャッシュに似ています）ハードディスクをリリースする予定のデータファイルのこの部分を記述する必要があります。
2.匿名メモリは、このメモリは、実際にハードディスクファイルのキャッシュファイルとは異なり、キャリア、典型的なヒープ、スタックデータなどのAキャリア、ではありません。このメモリは、リサイクルまたは同様の文書がメディアに書き戻されたときに、このメカニズムから、このスワップに従事するために、直接放出、このタイプのメモリはハードディスクにスワップアウトして、必要なときにそれをロードすることはできません。
Linuxは気にしない、ここで匿名性を回復するためにどのファイルやキャッシュメモリのニーズを識別するためのアルゴリズムを使用してどのような具体的な、我々は中にはここで見つけることができます興味を持っています。しかし、我々は考える必要があるという問題点がある：あるメモリの2種類を回復させることができるので、その後、メモリのこれら2つのタイプの場合に回収することができ、最終的にはLinuxはどのようにそれを回復することで最終的にメモリのタイプを決定するのですか？またはその両方が回収されるのでしょうか？ここでは、第二の懸念のパラメータを引き出す：swappinessをし、この値は、カーネルは積極的に、値を下げてスワップを使用する方法を積極的にカーネルスワップ、より高い値を定義するために使用され、それはスワップの使用量を削減します熱意。値は0から100の範囲で、デフォルト値は60です。最後に、このswappinessのは、それを達成する方法ですか？具体的な原理は、制御メモリの回復、リサイクルやドキュメントのいくつかのより多くの匿名のページでswappinessのは、この効果を達成するためにいくつかのより多くのキャッシュを回復し、簡単に言え非常に複雑です。swappinessをすべての匿名メモリとキャッシュファイルが同じ優先度で復元され、100に等しい、デフォルトの優先度60は、ファイルキャッシュはファイルキャッシュアウト回復優先すべき理由として、うちリサイクルされることを示し、あなたが（通常はファイルキャッシュを回復について考えたいと思うかもしれIO動作）、低下させる、システム性能にあまり影響をもたらさないであろう。データベースが関係しているために、スワップが可能な限り避けるべきである、我々は0に設定する必要があります。それは、ここで注意しなければならないが、ゼロに設定されているが、ああスワップを行っていないという意味ではありません！
これまでのところ、我々はLinuxのメモリトリガ機構から回復した、Linuxのメモリ復旧対象は、スワップに話をされただけでなく、パラメータmin_free_kbytes swappinessを説明しました。その後、別のスワップ関連のパラメータを見て取る：zone_reclaim_modeを、文書がNUMAゾーン再利用をオフにするこのパラメータを0に設定し、これはそれがどのようにありますか？リフトNUMA、両方とも満足しているデータベース、DBAの多くは、あまりにも悲惨なピットとなっています。なお、ここでは簡単な説明は、3つの少し質問：どのようなNUMAこと？NUMAとスワップの関係は何ですか？zone_reclaim_mode特定の意味は？
NUMA（非均一メモリ・アクセス）が示すように、（ネットワークからの画像）を以下に示すように、比較的、CPUアーキテクチャ、CPU初期設計UMA構成の両方の設計を話すUMAあります。
示すように、（ネットワークからの画像）を以下に示すように、リードチャネルマルチコアCPUのボトルネックを軽減するために、同一のメモリチップ設計エンジニアとNUMA構成に遭遇。
このアーキテクチャはUMAの問題に良い解決策、することができ、異なるCPUは、CPU間の「メモリ分離」を実現するために、また、ソフトウェアレベル2時をサポートする必要があり、排他的なメモリ領域があります。
1.メモリの割り当ては、現在配置されているCPU要求スレッドの専用記憶領域に確保されなければなりません。CPU専用メモリが他の領域に割り当てられている場合、分離は必然的にやや低下を横切るある程度、バスとメモリアクセス性能に影響することがバインドされています。
2.さらに、ローカルメモリ（専用メモリ）は、遠隔空きメモリのメモリ領域を借りなければならないかどうかを確認するのではなく、ローカルメモリのメモリページのうち、十分に、優先順位ではありません一度。
希望真剣にこの機能が不均一CPUのメモリ使用量をもたらす可能性がNUMAは、メモリの専用のCPU部分では十分ではありません、リサイクルに頻繁に必要性、そしてスワップが多数発生する可能性があり、システムの応答遅れ：それは本当に良い単独で達成したが、問題が来ていますジッタ。同時に、CPU専用メモリの残りの部分は非常にアイドル状態があります。これは奇妙な現象を生成する：現在のシステムだけでなく、いくつかの空き物理メモリを表示するために、自由なコマンドを使用して、システムは、いくつかの用途のために性能が急激に減少し、その結果、スワップに発生し続けています。イェジンロン先生のMySQL事例参照：「MySQLサーバがSWAPの犯人を持って見つけます。」
だから、小さなメモリ用のアプリケーションの観点から、NUMAは逆に、ローカルメモリ、かなりもたらしたパフォーマンスに、顕著ではない。この問題をもたらしました。しかし、データベースメモリに飢えた、安定性のリスクをもたらしたNUMAデフォルトポリシーのこのタイプのために受け入れられません。強く改善のNUMAのデフォルトポリシーを作成するよう促されたデータベースので、二つの側面を向上させることができるがあります。
1.モードインターリーブ親和性へのデフォルトモードのメモリ割り当て戦略は、すなわち、メモリはCPUゾーンの異なる改ページに割り当てられます。メモリは、ある程度、上記の問題の奇妙なケースを容易にするため、このように偏在の問題を解決することができます。MongoDBのために、それは、起動時にメモリ割り当て戦略インターリーブの使用を促すメッセージが表示されます：
警告：あなたはNUMAマシン上で実行されています。 私たちは、パフォーマンスの問題を避けるために、このような起動のmongodをお勧め： numactl -interleave =全てのmongod [その他のオプション]
2.改良されたメモリ復旧戦略：ここでは最後に、今日の第三の主人公のパラメータzone_reclaim_modeを呼び出し、このパラメータは次のNUMAメモリアーキテクチャ別のリカバリ戦略が値0が現地を表し0/1/3/4を取ることができます定義ケースメモリの他のメモリ領域を割り当てるための十分でないメモリであってもよい。図1は、ローカルメモリは、ローカル再分配を回復するのに十分ではない場合を示し、図3は、オブジェクトとして回収するローカルキャッシュファイルの回復を表し、4ローカルリサイクル優先的に使用スワップを表します回復匿名メモリ。目に見える、HBaseのはある程度0の発生確率を低減させる構成zone_reclaim_mode =スワップを推奨しました。
いないすべてのスワップの事
これまでのところ、我々はスワップに関連する3つのシステムパラメータ、およびこれらの三つのパラメータLinuxシステムのメモリ割り当て、スワップ、およびNUMAの周りの深い解釈と他の知識のポイントを説明してきました。また、データベース・システムのために、特に懸念の2つの非常に重要なパラメータがあります。
1. IOスケジューリング戦略：これは結果のみを与えることを意図していないこのトピックは詳細に説明し、オンラインでたくさんあります。通常、OLTPデータベース用のSATAディスクのため、締切スケジューリングアルゴリズムは最良の選択です。
2. THPオフ特性（透明の巨大なページ）。私は長い間疑問に思っているTHP特性は、疑いの二つの主なポイントがあり、一つはTHPであるとHugePageは同じことではなく、HBaseのは、THPの閉鎖を要求する理由秒です。前後の後、多くの時間が関連文書にアクセスし、最終的にいくつかの手がかりを見つけました。ここでTHPを説明するための4つのドットの特徴：
（1）HugePageは何ですか？
オンライン解釈HugePage多くがありますが、私たちは、読み取りを取得することができます。手短に言えば、コンピュータ・メモリアドレッシングメモリの最小単位として4KBのページとして、メモリマップされたテーブル（インデックステーブルメモリ）を介して、現在のシステム・メモリをアドレス指定されています。メモリが増加すると、インデックステーブルメモリのサイズが増加していきます。4G程度のマシンの256Gメモリ、あなたは小さな4KBのページサイズを使用している場合にのみ、インデックステーブル。インデックステーブルがメモリにロードされなければならないが、また、CPUのメモリ内に、あまりにも多くのミスの多くが起こるか知るためには、メモリアドレッシングパフォーマンスが低下します。
メモリはインデックステーブルのサイズが小さくて、その後、すべてのミスを防ぐために、CPUのメモリに詰め制御することができますので、HugePageは、この問題を解決することで、HugePageは、メモリを管理する代わりに、伝統的な小さなページ2MBの大ページサイズを使用します。
（2）THP（透明の巨大なページ）とは何ですか？
HugePageは特性がそれをHugePageその特定の使用方法を、大きなページの理論でありますか？現在、システムは、1つは、静的巨大ページ、別の透明な巨大なページであると呼ばれ、2つの方法を提供します。前者は名前で知ることができるシステムが起動し、フォローアップが変化しないとき、これはラージ・ページの対応する番号を生成します、手動でシステムメモリのサイズに応じて多数のページを設定するには、ユーザーが必要な、静的な管理戦略です。透明の巨大なページが動的な経営戦略である、それは大きなページの実行時の動的な割り当てでアプリケーションになり、これらのページは、大規模な管理するために、ユーザーに対して完全に透過的、任意の設定を必要としません。また、唯一の匿名のメモリ領域の現在のTHP。
（3）のHBase（データベース）は、なぜTHP特性の閉鎖を求めていますか？
THPは、実行時に動的管理戦略、管理割り当て大きいページであるため、データベース・システムの待ち時間追求する許容できない遅延の分布のある程度、存在します。また、THPは、他の多くの欠点がありますが、あなたは記事を参照することができ、「なぜ-tokudb-嫌い-透明のhugepages」
（4）THP OFF / ONはほとんど影響書き込み性能HBaseの権利がありますか？
THPの効果を検証するために、私はテスト環境で簡単なテストでしたどのくらいの最後にHBaseのパフォーマンスを開くために閉じ：試験荷重比を読み書き、唯一のテストクラスタリージョンサーバーを1：1です。THPは、常に、決して二つのオプションであり、システムの部分でのmadviseシステムと呼ばれるセクションでより多くのオプション。コマンドを使用することができ、決して/常に> / SYS /カーネル/ MM / transparent_hugepageエコー/オープン/クローズTHPに有効。試験結果を以下に示します：
上記図、（決して）HBaseの最適な性能のシナリオでは、比較的安定したオフTPH。シーンオフ性能の低下に比べTHP開口シーン（常に）は、約30％、および大きなジッタ曲線を有します。目に見える、HBaseのオンラインTHPを閉じることを忘れないでください。
概要
任意のデータベース・システムのパフォーマンスは、多くの要因に関連し、また、基盤となるシステムに及ぼす影響に加えて、このようなデータベースの構成など、データベース自体の様々な要因、クライアントが使用する、キャパシティプランニング、設計テーブル方式は、あるされています重要な、このようなオペレーティングシステム、JVMなどのように。非常に多くの調査のための具体的な理由を見つけることができません右、いくつかのデータベースのパフォーマンスの問題が発生左側をチェックして、この時間は、コンフィギュレーションのオペレーティングシステムが妥当なものであるかどうかを確認する必要があります。いくつかのパラメータから公式ドキュメントの要件をHBaseの開始、これらのパラメータの意味は、特定の詳細について説明します。カバー比較的多くの興味のある学生は、詳細な記事最後に参照記事を表示することができます。
これは、スイッチ：http://hbasefly.com/2017/05/24/hbase-linux/?lkfgjq=xbbdl2
