スワップ スペースはディスク上の領域であり、パーティション、ファイル、またはそれらの組み合わせになります。
簡単に言うと、システムの物理メモリが不足している場合、Linux はアクセス頻度の低いデータをメモリに保存してスワップします。これにより、システムは各プロセスに対応できる物理メモリを増やすことができます。スワップに保存されているコンテンツにアクセスすると、スワップ上のデータがメモリにロードされます。これは、スワップ アウトとスワップ インとよく呼ばれるものです。
この質問に答えるには、スワップがどのようなメリットをもたらすのかを答える必要があります。
一部の大規模なアプリケーション (LibreOffice、ビデオ エディターなど) では、起動プロセス中に大量のメモリが使用されますが、このメモリは多くの場合、起動時にのみ使用され、使用されることはありません。このメモリは、その後の操作中に再使用されることはほとんどありません。スワップを使用すると、システムはこの方法で使用されないメモリ データの部分をスワップに保存できるため、システムが使用できる物理メモリがさらに解放されます。
多くのディストリビューション (ubuntu など) の休止機能はスワップ パーティションに依存しています。システムが休止状態になると、メモリ内のデータはスワップ パーティションに保存され、その後、メモリ内のデータはスワップ パーティションに保存されます。メモリにロードするとシステムの起動が高速化されるため、休止状態機能を使用する場合は、スワップ パーティションを構成し、そのサイズが物理メモリ以上である必要があります。
場合によっては、物理メモリが制限されていますが、メモリを消費するプログラムを実行したい場合はどうすればよいですか?このとき、十分なスワップ領域を設定することで目標を達成でき、多少遅くなりますが、少なくとも実行できます。
物理メモリはほとんどの場合十分ですが、プロセスが予想よりも多くのメモリを必要としたり、プロセスでメモリ リークが発生したりするなど、予期しない状況が常に発生します。 , カーネルの OOM キラーがトリガーされます。OOM キラーの設定に従って、いくつかのプロセスが強制終了されるか、システムが直接再起動されます (デフォルトでは、最も多くのメモリを消費するプロセスが最初に強制終了されます)。スワップをメモリとして使用すると、少し遅くなりますが、少なくともデバッグしたり、プロセスを強制終了したり、現在の作業の進行状況を保存したりする機会が得られます。
Linux のメモリ管理を見たことがある人なら、システムの I/O 速度を上げるために、システムは可能な限り多くの空きメモリをキャッシュに使用することがわかります。スワップ時に、より多くの物理メモリがキャッシュに使用されるため、システム全体のパフォーマンスが向上します。
スワップのメリットを紹介しましたが、スワップのデメリットはどうでしょうか。スワップはディスクに保存されます。ディスクの速度はメモリの速度よりも数桁遅くなります。スワップの読み取りと書き込みを続けると、特にシステムが正常に動作していない場合、システムのパフォーマンスに確実に影響を及ぼします。メモリが非常に不足しています。スワップ スペースの頻度が非常に高く、システムの動作がまるで死んでいるかのように非常に遅くなります。現時点では、物理メモリを追加することが唯一の解決策です。
システムは、使用頻度の低いメモリ データを自動的にスワップに移動するため、デスクトップ プログラムの場合、プログラムを最小化して再度開くと、メモリ データを移動する必要があるため、少し停止することがあります。データはメモリに再ロードされます。
上記では、スワップとは何か、そのメリットとデメリットを紹介しましたが、スワップを設定する必要があるでしょうか?答えは「状況による」です。
以下では、メモリ不足、メモリ不足、メモリ十分の 3 つの状況におけるサーバーおよびデスクトップ環境のスワップの選択について説明します。
デスクトップでもサーバーでも、明らかに物理メモリが不足していてプログラムを実行したい場合は、スワップを追加することが唯一の選択肢です。遅いほど良いです。全く働かないよりは。
スワップを構成して、カーネルが使用頻度の低いデータをメモリからスワップに移動し、より多くの物理メモリをシステム コールに使用できるようにすることをお勧めします。これにより、システムのパフォーマンスが向上すると同時に、時折発生する物理メモリ不足によるプロセスの異常終了も回避され、システムの安定性が向上します。ただし、サーバーの場合は、スワップ領域の使用量を制限または監視する必要があります。予想を超えているか、スワップイン/スワップアウトが頻繁に発生する場合は、時間内に対策を講じる必要があります。そうしないと、パフォーマンスに大きな影響を及ぼします。
理論的には、十分な物理メモリがあり、ハイバネーション機能は必要ないため、スワップは役に立ちません。しかし、重要な問題は、一部のプロセスが予想よりも多くのメモリを消費するなど、予期しない状況が常に存在するため、どのような状況でも物理メモリが十分であることを保証するのが難しいということです。予想を超えるサーバー負荷、メモリリークなど。
現在、明らかにメモリが不足しています。メモリ不足の原因は何ですか? mysql がサーバーのメモリ不足を直接引き起こすのはなぜですか?
物理メモリが 16G、スワップが 4G であると仮定します。 MySQL 自体がすでに 12G の物理メモリを占有しており、同時に他のプログラムまたはシステム モジュールが 6G のメモリを必要としている場合、オペレーティング システムは MySQL が所有するアドレス空間の一部をマップしてスワップする可能性があります。
率直に言うと、システムは、mysql が占有するスペースが大きすぎるため、特別なことを実行できないと考えています。他の必要なプロセス領域がメモリを使用するためのスペースを確保する必要があるため、プレイするにはスワップが遅くなります。バー!
mysql で最大のメモリ占有量は innodb_buffer_pool_size なので、最初にこの値が不当に設定されているかどうかを考慮する必要がありますか?
MySQL のメモリ消費量は次のように分類されます:
#1. セッション レベルのメモリ消費量: sort_buffer_size など、各セッションはsort_buffer_size を開く 並べ替え操作を実行するには
2. グローバル メモリ消費量: 例: innodb_buffer_pool_size など、グローバル共有メモリ セグメント
This DBA の専門的でない点は、最初の状況を考慮せず、セッション レベルでメモリ消費量を確認せず、innodb_buffer_pool_size を減らすように直接指示したことでした。
テーブル データとインデックス データをキャッシュし、ディスク上のデータをバッファ プールにロードして、アクセスごとのディスク IO を回避し、アクセスを高速化します。
MySQL の同時実行パフォーマンスは、バッファ プールによって割り当てられたメモリ サイズに直接比例します。割り当てられたメモリが大きいほど、同時実行パフォーマンスは向上します。マシンのメモリの 99% をすべてバッファ プールに割り当てる必要がありますか? ＃＃＃＃＃＃もちろん違います！言うまでもなく、オペレーティング システムのカーネルにも数ギガバイトのメモリが必要です。バッファ プールに加えて、MySQL には他の多くのメモリ データ構造もあります。これらはすべてメモリを必要とするため、上記の考えは絶対に実現不可能です。
より適切な比率は、バッファ プールのメモリ サイズがマシンの総メモリの 50% ～ 60% を占めることです。
show Engine innodb status\G; でヒット ステータスを確認できます。ヒットが 97% を超えない場合は、メモリの追加を検討できます。もちろん、これはビジネスにも関係します。たとえば、マスターへの書き込み量が多く、読み取り Less は特殊なケースです。
その他の場合、97% を超えない場合、および大規模な読み取りの場合は、 98%以上に達しない場合はバッファが不足していることを意味しますので拡張可能ですが、逆にメモリを20%に分割するとヒット率は100%に達する可能性があり、空きページ数があれば十分です。また、空きページ数に応じて計算してメモリを削減することもできます。そのメモリを使用してみてはいかがでしょうか。
以上がLinux スワップ領域の使用率が高い問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
