十分な空きメモリが残っているときにスワップが使用されるのはなぜですか？

35

優れたメモリリソースを備えた非常に優れたWeb（専用）サーバーがあります。

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)

ご覧のとおり、使用可能な空きメモリが十分にある場合、サーバーはスワップを使用しています。

これは正常ですか、構成またはコーディングに何か問題がありますか？

NB
私のMySQLプロセスは何らかの理由でCPUパワーの160％以上を使用しています。理由はわかりませんが、70人以上の同時ユーザーはいません...

linux mysql php

— user1179459
ソース

アプリケーションはLinuxのCPUを100％以上使用できますか？Erm

— ...-BlueRaja

5

@BlueRaja：はい。Linuxでは、システムのすべてのCPUではなく、単一のCPUを基準にしてCPU使用率が測定されるためです。したがって、8個のCPUを搭載したマシンでは、最大800％のCPUを使用できます。

— ダニエル・プライデン

使用しているMySQLのバージョン???

— -RolandoMySQLDBA

@RolandoMySQLDBAバージョン5.5

— user1179459

61

これは完全に正常です。

システムの起動時に、いくつかのサービスが開始されます。これらのサービスは自身を初期化し、構成ファイルを読み取り、データ構造を作成します。彼らはいくつかのメモリを使用します。これらのサービスの多くは、使用していないため、システムが稼働している間は二度と実行されません。それらの一部は、数時間、数日、または数週間で実行されます。しかし、このデータはすべて物理メモリにあります。

もちろん、システムはこのデータを捨てることはできません。文字通り決してアクセスされないことを証明することはできません。たとえば、これらのサービスの1つは、ボックスへのリモートアクセスを提供するサービスです。1週間は使用しなかったかもしれませんが、実際に使用した方がうまくいきました。

しかし、システムは、その物理メモリをディスクキャッシュなどに使用したり、パフォーマンスを改善する他の方法で使用したりすることを知っています。したがって、日和見交換が行われます。何もすることがない場合、非常に長い時間使用されていないデータをスワップ領域を使用してディスクに書き込みます。ただし、ページは物理メモリに保持されます。したがって、それらをスワップインすることなくアクセスできます。

現在、システムが後でその物理メモリを他の何かのために必要とする場合、それらはすでにスワップ用に書き込まれているため、それらのページを単に捨てることができます。これにより、システムは両方の長所を備えています。データは引き続きメモリに保持されるため、ディスクから読み取る必要なくアクセスできます。しかし、システムが別の目的でそのメモリを必要とする場合、最初にメモリを書き出す必要はありません。すべての周りの大きな勝利。

— デビッド・シュワルツ
ソース

その場合、スワップスペースがまったく使用されないことがある理由を説明してください。メモリ：合計49554484k、使用済み4087592k、無料45466892k、無料349244kバッファスワップ：合計94204k、0k使用、94204k空き、1113644kキャッシュ

— 12

4

@ananthan：多くの理由が考えられます。最も可能性が高いのは、バッファリングされた書き込みであっても、システムがメモリ不足に陥ることはなかったため、日和見スワップコードがトリガーされなかった可能性があることです。また、誰かがスワップの使用法が悪いと思ったために、システムを日和見的にスワップしないように誤って調整した可能性もあります（swappinessを減らします）。

— デビッドシュワルツ

6

これは、過去のある時点で、マシンの物理RAMよりも多くのメモリが必要な場合に発生する可能性があります。その時点で、一部のデータがスワップスペースに書き込まれます。

後でメモリが解放されると、スワップからのデータは自動的にRAMに読み戻されません。これは、スワップ内のデータが実際に何らかのプロセスで必要な場合にのみ発生します。これは完全に正常です。

mysqlプロセスに関して：これはすべて、実行するクエリのタイプに依存します。理論的には、ユーザー数に関係なく、非常に複雑なクエリでこのような負荷を十分に満たすことができます。スロークエリログを有効にして、どのクエリが負荷が集中するかについてより多くの洞察を得ることができます。

— brain99
ソース

いいえ-スワップの使用は最高水準点ではありません。スワップアウトされたページがマップバックされると、ディスクページは使用されていないものとしてマークされます（ただし、まだデータが含まれている場合があります）。

— -symcbean

スワップを使用できるシナリオを1つだけ挙げましたが、これは実際に十分な物理メモリがないことを必ずしも示しているわけではありません-上記のDavid Schwartzによっても説明されています

— -brain99

3

また、によってこの動作を変更することもできます。これによりsysctl -w vm.swappiness=10、実際に必要になるまでスワップの使用が大幅に削減されます。

MySQLについては、少なくともTuning-primer.shスクリプトを使用してベースライン構成テストを実行しましたか？

— 混Daのデーモン
ソース

1

これにより、キャッシュ/バッファが回収される傾向が高まります。残念ながら、29.53％の数値にバッファ/キャッシュが含まれているかどうかは元の質問から明らかではありません。含まれていない場合、変更を行うとパフォーマンスに悪影響が及びます。このdbmsが広範囲にinnodbを使用している場合、おそらく適切に構成されていません（ただし、Webサーバーとして使用するための単一の8コア16gbボックスは、最初は悪い選択です）

— -symcbean

なぜあなたはウェブサーバーの悪い選択を言うのですか？私は私が読みので.... 70％であり、30％のみを書き込みのMyISAMを好むまだずっと私のInnoDBを使用していけない

— user1179459

1

これはおそらく、Davidが説明したように、Linuxカーネルの通常の動作ですが、MySQLの「スワップ狂気」問題の発生でもある可能性があります。あなたの場合（8 CPU、合計16 GB RAM、5 GB使用）、そのためには、コンピューターは4ノード（ソケット）とノードあたり4 GBのRAMと4のMySQL InnoDBバッファープールを持つNUMAシステムである必要がありますGB。

要するに（詳細については上記のリンクを読む必要があります）、これは何が起こるかです：

システムが起動すると、メモリの一部を使用して、プロセスがすべてのNUMAノードに分散されます。
MySQLが起動すると、InnoDBバッファープールに4 GBが割り当てられ、NUMAノードのRAMがいっぱいになり、他のノードでRAMが使用されます。
次に、割り当てられたRAMをあるNUMAノードから別のNUMAノードに移動できないLinuxカーネルは、飢star状態のノードからページをスワップアウトすることをお勧めします（または、ページをスワップインする必要があるため、ページをスワップアウトする必要があります）。

これを回避するには、MySQLのメモリ割り当てを変更して、すべてのコアにRAMを割り当てます（詳細については、上記のリンクを参照してください）。

— jfg956
ソース