Linuxサーバーはメモリの60％しか使用していないので、スワッピング

baculaバックアップシステムを実行しているLinuxサーバーがあります。マシンは交換するために重くなっているため、狂ったように粉砕されています。問題は、物理メモリの60％しか使用していないことです！

からの出力はfree -m次のとおりです。

free -m
             total       used       free     shared    buffers     cached
Mem:          3949       2356       1593          0          0          1
-/+ buffers/cache:       2354       1595
Swap:         7629       1804       5824

およびからのサンプル出力vmstat 1：

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 1843536 1634512      0   4188   54   13  2524   666    2    1  1  1 89  9  0
 1 11 1845916 1640724      0    388 2700 4816 221880  4879 14409 170721  4  3 63 30  0
 0  9 1846096 1643952      0      0 4956  756 174832   804 12357 159306  3  4 63 30  0
 0 11 1846104 1643532      0      0 4916  540 174320   580 10609 139960  3  4 64 29  0
 0  4 1846084 1640272      0   2336 4080  524 140408   548 9331 118287  3  4 63 30  0
 0  8 1846104 1642096      0   1488 2940  432 102516   457 7023 82230  2  4 65 29  0
 0  5 1846104 1642268      0   1276 3704  452 126520   452 9494 119612  3  5 65 27  0
 3 12 1846104 1641528      0    328 6092  608 187776   636 8269 113059  4  3 64 29  0
 2  2 1846084 1640960      0    724 5948    0 111480     0 7751 116370  4  4 63 29  0
 0  4 1846100 1641484      0    404 4144 1476 125760  1500 10668 105358  2  3 71 25  0
 0 13 1846104 1641932      0      0 5872  828 153808   840 10518 128447  3  4 70 22  0
 0  8 1846096 1639172      0   3164 3556  556 74884   580 5082 65362  2  2 73 23  0
 1  4 1846080 1638676      0    396 4512   28 50928    44 2672 38277  2  2 80 16  0
 0  3 1846080 1628808      0   7132 2636    0 28004     8 1358 14090  0  1 78 20  0
 0  2 1844728 1618552      0  11140 7680    0 12740     8  763 2245  0  0 82 18  0
 0  2 1837764 1532056      0 101504 2952    0 95644    24  802 3817  0  1 87 12  0
 0 11 1842092 1633324      0   4416 1748 10900 143144 11024 6279 134442  3  3 70 24  0
 2  6 1846104 1642756      0      0 4768  468 78752   468 4672 60141  2  2 76 20  0
 1 12 1846104 1640792      0    236 4752  440 140712   464 7614 99593  3  5 58 34  0
 0  3 1846084 1630368      0   6316 5104    0 20336     0 1703 22424  1  1 72 26  0
 2 17 1846104 1638332      0   3168 4080 1720 211960  1744 11977 155886  3  4 65 28  0
 1 10 1846104 1640800      0    132 4488  556 126016   584 8016 106368  3  4 63 29  0
 0 14 1846104 1639740      0   2248 3436  428 114188   452 7030 92418  3  3 59 35  0
 1  6 1846096 1639504      0   1932 5500  436 141412   460 8261 112210  4  4 63 29  0
 0 10 1846104 1640164      0   3052 4028  448 147684   472 7366 109554  4  4 61 30  0
 0 10 1846100 1641040      0   2332 4952  632 147452   664 8767 118384  3  4 63 30  0
 4  8 1846084 1641092      0    664 4948  276 152264   292 6448 98813  5  5 62 28  0

さらに、CPU時間でソートされたtopの出力は、スワップがシステムを動かさないという理論をサポートしているようです。

top - 09:05:32 up 37 days, 23:24,  1 user,  load average: 9.75, 8.24, 7.12
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.4%sy,  0.0%ni, 76.1%id, 20.6%wa,  0.1%hi,  0.2%si,  0.0%st
Mem:   4044632k total,  2405628k used,  1639004k free,        0k buffers
Swap:  7812492k total,  1851852k used,  5960640k free,      436k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 4174 root      17   0 63156  176   56 S    8  0.0   2138:52  35,38 bacula-fd                                                                                                                            
 4185 root      17   0 63352  284  104 S    6  0.0   1709:25  28,29 bacula-sd                                                                                                                            
  240 root      15   0     0    0    0 D    3  0.0 831:55.19 831:55 kswapd0                                                                                                                              
 2852 root      10  -5     0    0    0 S    1  0.0 126:35.59 126:35 xfsbufd                                                                                                                              
 2849 root      10  -5     0    0    0 S    0  0.0 119:50.94 119:50 xfsbufd                                                                                                                              
 1364 root      10  -5     0    0    0 S    0  0.0 117:05.39 117:05 xfsbufd                                                                                                                              
   21 root      10  -5     0    0    0 S    1  0.0  48:03.44  48:03 events/3                                                                                                                             
 6940 postgres  16   0 43596    8    8 S    0  0.0  46:50.35  46:50 postmaster                                                                                                                           
 1342 root      10  -5     0    0    0 S    0  0.0  23:14.34  23:14 xfsdatad/4                                                                                                                           
 5415 root      17   0 1770m  108   48 S    0  0.0  15:03.74  15:03 bacula-dir                                                                                                                           
   23 root      10  -5     0    0    0 S    0  0.0  13:09.71  13:09 events/5                                                                                                                             
 5604 root      17   0 1216m  500  200 S    0  0.0  12:38.20  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  580  248 S    0  0.0  11:58.00  11:58 java

以下は、仮想メモリのイメージサイズでソートされた同じものです。

top - 09:08:32 up 37 days, 23:27,  1 user,  load average: 8.43, 8.26, 7.32
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  3.4%sy,  0.0%ni, 62.2%id, 30.2%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   4044632k total,  2404212k used,  1640420k free,        0k buffers
Swap:  7812492k total,  1852548k used,  5959944k free,      100k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 5415 root      17   0 1770m   56   44 S    0  0.0  15:03.78  15:03 bacula-dir                                                                                                                           
 5604 root      17   0 1216m  492  200 S    0  0.0  12:38.30  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  476  200 S    0  0.0  11:58.20  11:58 java                                                                                                                                 
 4598 root      16   0  117m   44   44 S    0  0.0   0:13.37   0:13 eventmond                                                                                                                            
 9614 gdm       16   0 93188    0    0 S    0  0.0   0:00.30   0:00 gdmgreeter                                                                                                                           
 5527 root      17   0 78716    0    0 S    0  0.0   0:00.30   0:00 gdm                                                                                                                                  
 4185 root      17   0 63352  284  104 S   20  0.0   1709:52  28,29 bacula-sd                                                                                                                            
 4174 root      17   0 63156  208   88 S   24  0.0   2139:25  35,39 bacula-fd                                                                                                                            
10849 postgres  18   0 54740  216  108 D    0  0.0   0:31.40   0:31 postmaster                                                                                                                           
 6661 postgres  17   0 49432    0    0 S    0  0.0   0:03.50   0:03 postmaster                                                                                                                           
 5507 root      15   0 47980    0    0 S    0  0.0   0:00.00   0:00 gdm                                                                                                                                  
 6940 postgres  16   0 43596   16   16 S    0  0.0  46:51.39  46:51 postmaster                                                                                                                           
 5304 postgres  16   0 40580  132   88 S    0  0.0   6:21.79   6:21 postmaster                                                                                                                           
 5301 postgres  17   0 40448   24   24 S    0  0.0   0:32.17   0:32 postmaster                                                                                                                           
11280 root      16   0 40288   28   28 S    0  0.0   0:00.11   0:00 sshd                                                                                                                                 
 5534 root      17   0 37580    0    0 S    0  0.0   0:56.18   0:56 X                                                                                                                                    
30870 root      30  15 31668   28   28 S    0  0.0   1:13.38   1:13 snmpd                                                                                                                                
 5305 postgres  17   0 30628   16   16 S    0  0.0   0:11.60   0:11 postmaster                                                                                                                           
27403 postfix   17   0 30248    0    0 S    0  0.0   0:02.76   0:02 qmgr                                                                                                                                 
10815 postfix   15   0 30208   16   16 S    0  0.0   0:00.02   0:00 pickup                                                                                                                               
 5306 postgres  16   0 29760   20   20 S    0  0.0   0:52.89   0:52 postmaster                                                                                                                           
 5302 postgres  17   0 29628   64   32 S    0  0.0   1:00.64   1:00 postmaster

swappinessカーネルパラメーターを高い値と低い値の両方に調整しようとしましたが、ここでの動作を変更するものはありません。何が起こっているのかわからない。これの原因を調べるにはどうすればよいですか？

更新：システムは完全に64ビットシステムであるため、32ビットの問題によるメモリ制限の問題はありません。

Update2：元の質問で述べたように、0を含むすべての種類の値にswappinessを調整しようとしました。結果は常に同じで、約1.6 GBのメモリが未使用のままです。

Update3：上記の情報にトップ出力を追加しました。

Baculaのパフォーマンスはデータベースに大きく依存しています。おそらく、サーバーを殺しているのはpostgresqlです。高い負荷平均と待機状態で費やされたCPU時間のかなり大きい％は、明らかにディスクI / Oを待機していることを示しています...そして、これはPostgreSQLが行っていることです。バックアップ内のすべてのファイルに対して、少なくともUPDATEステートメントの実行を設定します。スワップについて心配する必要はありません。

PostgreSQLのインストールを調整してください。個別のデータベース（またはテーブル）に独自のディスク/ RAIDセットを与えて、I / Oを分散させることができます。非同期の書き込みが使用されていない場合は、PostgreSQLに強制的に書き込みを行うことができます...ただし、書き込みパフォーマンスのためにデータベースの整合性が犠牲になります。PostgreSQLで使用可能な共有メモリを大幅に強化します。これにより、データベースでの読み取りの少なくとも多くが軽減されます。一度も実行したことがない場合は、BaculaデータベースでVACCUM ANALYZEを実行して、クエリオプティマイザーに操作できるようにします。

Baculaの最も弱い点は、データベースの依存関係（およびその一部の脳の死）です。 .. Baculaは比較的少数の大きなファイルを好みますが、そうでなければ犬です。

あなたはI / Oバウンドです。 お使いのシステムは小さな救命いかだで、高さ100フィートのバッファ/キャッシュ/ VMページングのうねりの嵐の海でボロボロです。

ワオ。ただ...すごい。I / Oを約100Mバイト/秒で移動し、I / O待機でCPU時間の50％をはるかに超えており、4GbのRAMがあります。このサーバーのVMのバックプレッシャーは膨大でなければなりません。「通常の」状況では、システムがバッファ/キャッシュを開始するため、使用していた空きRAM は40秒以内に生きたまま食べられます。

から設定を投稿することは可能/proc/sys/vmですか？これにより、カーネルが「正常」であると考えるものについての洞察が得られます。

これらのpostmasterプロセスは、PostgreSQLをバックグラウンドで実行していることも示しています。これはあなたのセットアップでは正常ですか？デフォルト設定のPostgreSQLはRAMをほとんど使用しませんが、速度を再調整すると、使用可能なRAMの25％〜40％をすばやく噛むことができます。そのため、出力にそれらの数があれば、バックアップを実行している間に何らかの実動データベースを実行していると推測できます。 これはうまくいきません。 なぜ実行されているのか、さらに情報を提供できますか？すべての共有メモリパラメータのサイズは何ですかpostmasterプロセス？サービスのシャットダウン、またはバックアップの実行中に使用する接続/バッファの数を減らすために一時的にデータベースを再構成することは可能でしょうか？これにより、すでに負荷がかかっているI / Oと空きRAMの負荷をある程度軽減できます。それぞれに留意してください postmasterプロセスは、データベースが内部キャッシュに使用する以上のRAMを消費する。したがって、メモリ設定を調整するときは、どちらが「共有」で、どちらが「プロセスごと」であるかに注意してください。

バックアッププロセスの一部としてPostgreSQLを使用している場合、最小数の接続のみを受け入れるように再調整し、プロセスごとのパラメーターを適切な値（それぞれ数MB程度）に縮小してください。これのデメリットは、PostgreSQLがRAM内のデータセットを希望どおりに動作できない場合、ディスクに流出するため、実際にディスクI / O が増加するため、慎重に調整することです。

X11自体は多くのメモリを必要としませんが、デスクトップセッション全体で数メガを消費する可能性があります。アクティブなセッションをログアウトし、コンソールまたはSSH経由で接続を実行します。

それでも、私はそれが完全にメモリの問題だとは思わない。 長時間にわたって50％のI / O待機時間を超えている場合（および70年代に近い数値を投稿している場合）、結果として生じるボトルネックは最終的にシステムの残りの部分を押しつぶします。ダースベイダーが首を潰すように。

何個のフラッシュスレッドを設定しますか？使用する

cat /proc/sys/vm/nr_pdflush_threads

見つけて

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

単一のスレッドに設定します。最後のコマンドは、再起動時に永続的にロードすることに注意してください。そこに1または2が見えるのは珍しいことではありません。I / O用に複数のコアまたは多数のスピンドル/バス容量がある場合、これらを（わずかに）増やしたいと思うでしょう。フラッシュスレッドが増えると、I / Oアクティビティが増えますが、I / O待機に費やされるCPU時間も増えます。

それはデフォルト値ですか、それともバンプしましたか？ぶつかった場合は、I / O操作の負荷を軽減するために数を減らすことを検討しましたか？または、使用するスピンドルとチャネルの数が膨大ですか？その場合、増加を検討しましたか？フラッシュスレッドの数をか？

PSスワップアウトを防ぐために、swappinessを高い値ではなく低い値に設定します。最高値= 100 =気分がよければクレイジーのようにスワップし、最低値= 0 =まったくスワップしないようにします。

IOで1秒あたりの読み込みブロック数（bi）を見ると、スワップアクティビティが数桁小さくなります。スワップの使用がディスクスラッシングの原因であるとは思わない。ボックス上で実行されているものが、単に多くのディスクアクティビティ（読み取り）を引き起こしていると思う。

実行中のアプリケーションを調査し、原因を見つけられるかどうかを確認します。

このリンクが質問の一部に答えるかどうかを確認してください。使用率が60％を超えるずっと前に、Linuxがメモリをページングする（スワップしない）のを定期的に見ます。これは、メモリチューニングの期待される部分です。

http://www.sheepguardingllama.com/?p=2252

しかし、バッファ/キャッシュの不足が心配です。それは非常に珍しいようです。だから、もっと何かがおかしいと思っています。

スワップを完全に無効にできますか？

swapoff /dev/hdb2

または少なくとも、それはあなたの問題であり、他の何かではないことを交換することを検証します。

デフォルトでは、swappinessは60に設定されています。

cat / proc / sys / vm / swappiness 60

Swappinessは、カーネルがRAMよりもスワップを好む度合いを微調整するために使用されるカーネルです。高い交換性は、カーネルが多くスワップアウトすることを意味し、低い交換性は、カーネルがスワップ空間を使用しないことを意味します。

私たちは、の値が編集し、これを変更することができますvm.swappinessでは/etc/sysctl.confを。

カーネルのスワップピンネスを手動で設定できます。これ/proc/sys/vm/swappinessは、コマンドの実行時または発行時に確認できますsysctl vm.swappiness。swappinessは、スワップの使用量を決定するカーネル設定です。

設定sudo sysctl vm.swappiness=0することで、スワップパーティションを効果的に非アクティブ化できます。この変更を恒久的なものにするには、追加することができます/変更vm.swappiness=0の中で/etc/sysctl.conf。何があなたにとって良い値であるかがわかるはずです。個人的にはvm.swappiness=10、デフォルト値の60に設定されています。

カーネルの実行キューと相互運用不能プロセス（vmstatの「r」および「b」列）は、システムが時々飽和状態になっていることを示す指標です。補足として、飽和と使用率を混同しないでください。実際の問題は、飽和したカーネルに対する飢ved状態のプロセススタックである可能性があります:-(

「pmap -x [PID]」を実行して、より多くの消費プロセスから追加のメモリ詳細を取得することもできます。私はあなたの幸運を祈ります！

マット

大量のメモリを使用する短命のプロセスがあり、それらに気付く前に終了する可能性があります。

これは、とにかく見ているものと一致します。

iノードキャッシュの問題を調査しましたか？slabtopこのようなものに遭遇した場合、少なくとも出発点を与える必要があります。

システムが64ビットである間、システムは利用可能なメモリのすべてを実際にアドレス指定できない場合があります。これはチップセットの制限です。たとえば、前世代のMac miniは4GBのRAMを「サポート」していますが、実際には3.3GBのみがアドレス可能でした。