Linux ページ キャッシュで大きな問題があり、IO が遅くなります。たとえば、dd を使用して LVM パーティションをコピーすると、Linux はデータをバッファーまたはキャッシュ (free –m) にキャッシュします。これは問題ではありませんが、バッファーが特定の値に達すると、コピー プロセスが停止し、数 MB または KB まで遅くなります。ディスクまたは /dev/null への書き込みで多くのテストを実行しましたが、問題はソース ドライブまたは宛先とはまったく関係ありません。
詳細に：
- ほぼ同一のサーバーが 2 台あります。どちらも同じカーネルで CentOS 6.5 を実行しています。ディスク、セットアップ、その他のハードウェアはすべて同じです。唯一の違いは、1 台のサーバーには 2 つの CPU と 64 GB の RAM があり、もう 1 台のサーバーには 1 つの CPU と 32 GB の RAM があることです。
- 次のコピー プロセスのイメージも示します。https://i.stack.imgur.com/tYlym.jpg
- こちらも meminfo を含む新しいバージョンです。meminfo は別の実行からのものであるため、値は同一ではありませんが、動作は完全に同じです。https://i.stack.imgur.com/4SIJG.jpg
- dd またはその他のファイルシステム コピー プログラムを使用してコピーを開始します。
- バッファまたはキャッシュがいっぱいになり始めます。すべて正常です。
- バッファまたはキャッシュが最大数に達する (64GB RAM サーバーでは 32GB または 17GB のような値、32GB RAM サーバーではすべての空きメモリ)
- 64GB RAM サーバーでは、コピー プロセスが停止するか、数 MB に制限されます。32GB RAM サーバーではすべて正常です。
- 64GB RAM サーバーでは、「sync; echo 3 > /proc/sys/vm/drop_caches」でキャッシュを強制することで、一時的に問題を解決できます。しかし、もちろん、バッファはすぐに再び大きくなり始め、問題が再び発生します。
結論：
この問題は、2 番目の CPU またはメモリの総量に関係しています。各 CPU に独自の 32 GB RAM があり、コピー プロセスが CPU 上でのみ実行されていることが問題である可能性があるという「予感」があります。そのため、最終的にコピー プロセスによってバッファー/キャッシュが 32 GB 近くまで、または他の CPU の未使用のメモリまで増加し、Linux は、まだメモリがあるのでバッファーをさらに増やしてもよいが、下のハードウェアはメモリにアクセスできない、などと考えます。
誰かアイデアや解決策を持っていますか?もちろん、direct フラグ付きの dd を使用することもできますが、samba 経由の extern アクセスなどもあるため、それでは問題は解決しません。
編集1:
以下は、64GB RAM サーバーの /proc/zoneinfo です: 1.http://pastebin.com/uSnpQbeD(dd が開始する前) 2.http://pastebin.com/18YVTfdb(dd が動作を停止した場合)
編集2:
- VM設定:http://pastebin.com/U9E9KkFS
- /proc/sys/vm/zone_reclaim_mode は、32 GB RAM サーバー 0 と 64 GB RAM サーバー 1 にありました。この値には触れません。インストーラーが設定しました。一時的に 0 に変更して、テストを再試行します。これで、すべてのメモリがバッファーとキャッシュに使用されます。他のサーバーと同様に、見た目は良好です。しかし、その後、すぐにフルスピードでスワップが始まります... swapiness を 0 に設定しました。これは役立ちますが、それでも 1 秒あたり数 MB のスワップが行われます。また、バッファーが毎秒増加します。つまり、バッファーをスワップするのではなく、バッファーを増やすために、VM のメモリをスワップしてメモリを増やします... おかしいですね。でも、これが正常なのかもしれません!?
編集3:
/proc/buddyinfo および numactl --hardware: http://pastebin.com/0PmXxxin
最終結果
- /proc/sys/vm/zone_reclaim_mode は確かに技術的には正しい方法ですが、その後マシンはうまく動作しませんでした。たとえば、ディスクをコピーすると、Linux は空きメモリの 100% をバッファに使用します (以前のように XGB のみを使用して停止するのではなく)。ただし、最後の空きメモリがバッファに使用された時点で、Linux は VM メモリのスワップを開始し、バッファとキャッシュの合計量を増やします。スワップは通常、私のシステムでは必要ないため、スワップ メモリは一部の VM と同じディスク上にあります。結果として、これらの VM のバックアップを作成すると、Linux はバックアップ用にディスクから読み取ると同時にスワップを書き込みます。したがって、VM を交換するのは良くありませんが、Linux がバックアップの読み取り速度を低下させるのは、さらに悪いことです... したがって、/proc/sys/vm/zone_reclaim_mode を 0 に設定しても、問題は完全には解決されません... 現在、10 秒ごとにキャッシュを同期およびフラッシュするスクリプトを画面で実行しています... 良くはありませんが、私にとってははるかにうまく機能します。 システムには Web サーバーや通常のファイル サーバーはありません。 VM を実行し、バックアップを作成し、Samba 経由でバックアップを保存します。 この解決策は気に入りません。
答え1
発生している動作は、Linux が NUMA システム上でメモリを割り当てる方法によるものです。
私は、32GB システムが非 NUMA であるか、Linux が考慮するほど NUMA が十分ではないと (知らずに) 想定しています。
NUMA の処理方法は/proc/sys/vm/zone_reclaim_modeオプションによって決まります。デフォルトでは、Linux は NUMA システムを使用しているかどうかを検出し、パフォーマンスが向上すると思われる場合は再利用フラグを変更します。
メモリはゾーンに分割されており、NUMA システムでは最初の CPU ソケット用のゾーンと 2 番目の CPU ソケット用のゾーンがあります。これらは および として表示されますnode0。node1cat を実行すると確認できます/proc/buddyinfo。
ゾーン再利用モードが 1 に設定されている場合、最初の CPU ソケットからの割り当てにより、その CPU に関連付けられたメモリ ゾーンで再利用が行われます。これは、ローカル NUMA ノードから再利用する方がパフォーマンスの点で効率的であるためです。この意味での再利用とは、キャッシュをクリアするなどページをドロップしたり、そのノードでスワップ アウトしたりすることです。
値を 0 に設定すると、ゾーンがいっぱいになった場合に再利用は行われず、代わりにメモリの外部 NUMA ゾーンに割り当てられます。これには、そのメモリ ゾーンへの排他的アクセスを取得するために他の CPU が短時間ロックされるというコストがかかります。
しかし、すぐにスワップが始まります! 数秒後: メモリ: 合計 66004536k、使用済み 65733796k、空き 270740k、バッファ 34250384k スワップ: 合計 10239992k、使用済み 1178820k、空き 9061172k、キャッシュ済み 91388k
スワッピングの動作とスワップするタイミングは、いくつかの要因によって決まります。その 1 つは、アプリケーションに割り当てられたページがどれだけアクティブであるかです。あまりアクティブでない場合は、キャッシュで発生しているより忙しい作業にスワップされます。VM 内のページがアクティブ化されることはあまりないと思います。