Linuxサーバーはメモリの60％しか使用していないため、スワップ
バキュラバックアップシステムを実行している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カーネルパラメータを高い値と低い値の両方に調整しようとしましたが、ここでの動作に変化はありません。何が起こっているのかわからない。これを引き起こしている原因を見つけるにはどうすればよいですか？
pdate：システムは完全に64ビットシステムであるため、32ビットの問題によるメモリ制限の問題はありません。
pdate2：元の質問で述べたように、swappinessを0を含むあらゆる種類の値に調整しようとしました。結果は常に同じで、約1.6 GBのメモリが未使用のまま残ります。
pdate3：上記の情報に上位の出力を追加しました。
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をほとんど使用しませんが、速度を再調整すると、利用可能な容量の25％-40％をすぐに消費する可能性がありますRAMなので、私は推測することができますが、出力にそれらの数が与えられた場合、バックアップを実行している間、ある種の本番データベースを実行していますこれは、良い前兆ではありません。なぜそれが実行されているかについてさらに情報を提供しますか？すべてのpostmasterプロセスの共有メモリパラメータのサイズは何ですか？サービスをシャットダウンするか、データベースを一時的に再構成して、使用する接続数を減らします/バックアップの実行中にバッファを使用しますか？これは、すでに負荷のかかったI/OとRAMの空き容量を減らすのに役立ちます。各postmasterプロセスはRAMデータベースが内部キャッシュに使用する範囲を超えているため、メモリ設定を調整するときは どちらが「共有」され、どれが「プロセスごと」であるかに注意してください 。
バックアッププロセスの一部としてPostgreSQLを使用している場合は、 最小接続数 を受け入れるように再調整して、プロセスごとのパラメーターを適切な値に縮小してください（それぞれわずか数メガ）。これの欠点は、PostgreSQLがRAMのデータセットを希望どおりに処理できない場合、実際にはディスクI/Oを増やすので、慎重に調整してください。
X11自体は多くのメモリを必要としませんが、完全なデスクトップセッションは数メガを消費する可能性があります。持っているアクティブなセッションをログアウトし、コンソールまたはSSH経由で接続を実行します。
それでも、それは完全にメモリの問題ではないと思います。50％I/Oより優れている場合長時間待つ（そして70年代に触れる数値を投稿している）結果として生じるボトルネックが最終的にシステムの残りの部分を破壊します。 Darth Vader のように首をつぶします。
フラッシュスレッド はいくつ構成されていますか？使用する
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操作へのプレッシャーの量を減らすために数を減らすことを考えましたか？または、処理するスピンドルとチャネルの数が膨大ですか？その場合、フラッシュスレッドの数を増やすと考えましたか？
追伸スワップアウトを防ぐために、スワップピネスを高い値ではなく低い値に設定する必要があります。最高値= 100 =正しいと感じたときに狂ったようにスワップし、最低値= 0 =まったくスワップしないようにします。
IOで1秒あたりに読み込まれたブロック（bi）を見ると、スワップアクティビティが何桁も小さくなっています。スワップの使用がディスクのスラッシングを引き起こしている原因ではないと思います。ディスクのアクティビティ（読み取り）を多く引き起こしているボックスで何かが実行されていると思います。
実行中のアプリケーションを調査し、原因を見つけることができるかどうかを確認します。
スワップを完全に無効にしてみてください。
swapoff /dev/hdb2
またはそのようなもの-少なくとも、それがスワッピングであり、他の問題ではないことを検証します。
このリンクがあなたの質問のいくつかに答えているかどうかを確認してください。 Linuxのページング（スワップではなく）がメモリ使用率の60％をはるかに超えるずっと前から定期的に見ています。これは、予想されるメモリ調整の一部です。
http://www.sheepguardingllama.com/?p=2252
しかし、バッファ/キャッシュの不足が心配です。それは非常に珍しく見えます。だから私はもっと何かがおかしいと思っています。
デフォルトではswappinessは60に設定されています。
cat/proc/sys/vm/swappiness 6
Swappinessは、カーネルがRAMよりもスワップを優先する程度を微調整するために使用されるカーネルです。高いswappinessはカーネルが大量にスワップアウトすることを意味し、低いswappinessはカーネルがスワップ空間を使用しないことを試みることを意味します。
/ etc/sysctl.confのvm.swappinessの値を編集して、これを変更できます。
カーネルの swappinness を手動で設定できます。これは/proc/sys/vm/swappinessで確認するか、コマンドsysctl vm.swappinessを発行して確認できます。 swappinessは、使用されるスワップの量を決定するカーネル設定です。
Sudo sysctl vm.swappiness=0を設定すると、スワップパーティションを効率的に非アクティブ化できます。この変更を永続的にするには、vm.swappiness=0の/etc/sysctl.confを追加/変更します。あなたにとって何が良い価値であるかを見るべきです。私はそれをvm.swappiness=10に設定しました。デフォルト値は60です。
おそらく、大量のメモリを使用する短期間のプロセスがあり、それらに気付く機会が得られる前に終了します。
これは、とにかく見ているものと一致します。
Iノードキャッシュの問題を調査しましたか？ slabtopは、このような状況に遭遇した場合でも、少なくとも開始点を提供するはずです。
あなたが見たいかもしれないもう一つのことはあなたのカーネル実行キューであり、中断できないプロセス（vmstatの「r」と「b」列）はシステムが時々飽和していることを示しています。補足として、飽和と使用率を混同しないでください... realの問題は、飽和したカーネルに対するプロセススタックが不足している可能性があります:-(
また、 'pmap -x [PID]'を実行して、より負荷の高いプロセスのいくつかから追加のメモリの詳細を取得することもできます。私はあなたの幸運を祈ります！
マット
システムが64ビットの場合、システムは使用可能なすべてのメモリを実際にアドレス指定できない場合があります。これはチップセットの制限です。たとえば、前世代のMac miniは4 GBのRAMを「サポート」していますが、実際にアドレス指定できるのは3.3 GBだけでした。