Transparent hugepageがforkに遭遇すると
2269 ワード
詳細
オンラインカウントシステムは奇妙な問題に遭遇し、プロセスがバックアップを行うと、システムメモリが急速に小さくなり、25 Gメモリが食べられ、最後にプロセスがswapを大量に占有し、サービス応答が遅くなり、SLAの低下が深刻になる.
最後にTransparent hugepageに関連していることが判明し,具体的な記録は以下の通りである.
1カウントシステムバックアップの説明
Cacheシステムは10-100 Gレベルのメモリを占有し、バックアップは毎日未明の低ピーク時間に行われ、バックアップロジック:メインプロセスfork、それからサブプロセスは着地タスクを実行し、親プロセスは要求に応答し続け、バックアップ期間中、システムの変更量は少なく、単一kvのbyteは64 btes以内で、変更したtpsは100以下である.
2 osバージョンとthp
オンラインLinuxカーネルは2.6.38-2.7ですが、Linuxカーネルは2.6.38以降、Transparent hugepageがデフォルトでオンになっています.複雑なhugepageからメリットを得ることができなかったアプリケーションは、今では何の修正もせずにパフォーマンスの改善が得られ、パフォーマンスの向上は10%前後と予想されています.
3メモリ行方分析
ログ分析によると、バックアッププロセス全体が10分間続き、プロセス全体の変更kvの個数は100*60*10=60000で、有効メモリの変更は60000*64=約4 Mである.
forkプロセスでは、親プロセスの変更はcowのプロセスであり、最も極端な状況を先に計算することができる.すなわち、変更するたびにkvが1つのpageに分散し、最大値を計算する.
普通のpageの場合、消費すべきメモリ:4 M*4 K=16 G;このプロセスは最大16 Gを占めています
システムのデフォルトはTHPをオンにして、各pageは2 Mになったので、この過程の最大占有メモリ4 M*2 M=8192 G;
kvのsizeは小さいため、多くのkvは同じpageにあるため、実際の占有内には25 G mem&20 G+swapが存在する.
4 THPオフ
THPをオフにし、カウントサービスを再起動し、100 Gデータのバックアッププロセスを再起動し、更新に圧力がかかりません.
まとめてみると、forkバックアップでは、メインプロセスの変更プロセスがcowになり、LinuxではデフォルトでTHPが有効になり、書き込み増幅(1 byteを更新しても、実際のメモリは2 M bytesを新たに消費する必要がある可能性があります)が発生し、メモリがボトルネックになり、swap、応答が遅く、極端な状況ではosに乾かされてcrashなどが発生します.
5 THPをオフにする方法
1)boot時に有効にgrubを修正する.cfg
2)runtimeは修正
6 More about THP
Transparent hugepageはhugepage管理の簡略化版で、Linux 2.6.38以降に自動的に有効になり、anonymous memのみに有効になり、grep-i AnonHugePages/proc/meminfoで実際の使用状況を表示できます.
通常のcacheアプリケーションでは,デフォルトのTHPは性能が向上するが,forkがありforkが長い場合は資源占有状況を観測する必要があり,必要に応じてTHPを閉じる.
runtime期間中はTHPをオフにし、以前に割り当てられたhugepageは引き続き有効になり、新しい割り当てられたpageに対してのみhugepageを採用せず、osもscan&merge pagesを採用しない.
プロセスはmadviseでTHPを有効にするかどうかを設定できます.
参照先:
https://access.redhat.com/solutions/46111
http://lwn.net/Articles/423584/
http://lwn.net/Articles/423592/
オンラインカウントシステムは奇妙な問題に遭遇し、プロセスがバックアップを行うと、システムメモリが急速に小さくなり、25 Gメモリが食べられ、最後にプロセスがswapを大量に占有し、サービス応答が遅くなり、SLAの低下が深刻になる.
最後にTransparent hugepageに関連していることが判明し,具体的な記録は以下の通りである.
1カウントシステムバックアップの説明
Cacheシステムは10-100 Gレベルのメモリを占有し、バックアップは毎日未明の低ピーク時間に行われ、バックアップロジック:メインプロセスfork、それからサブプロセスは着地タスクを実行し、親プロセスは要求に応答し続け、バックアップ期間中、システムの変更量は少なく、単一kvのbyteは64 btes以内で、変更したtpsは100以下である.
2 osバージョンとthp
オンラインLinuxカーネルは2.6.38-2.7ですが、Linuxカーネルは2.6.38以降、Transparent hugepageがデフォルトでオンになっています.複雑なhugepageからメリットを得ることができなかったアプリケーションは、今では何の修正もせずにパフォーマンスの改善が得られ、パフォーマンスの向上は10%前後と予想されています.
3メモリ行方分析
ログ分析によると、バックアッププロセス全体が10分間続き、プロセス全体の変更kvの個数は100*60*10=60000で、有効メモリの変更は60000*64=約4 Mである.
forkプロセスでは、親プロセスの変更はcowのプロセスであり、最も極端な状況を先に計算することができる.すなわち、変更するたびにkvが1つのpageに分散し、最大値を計算する.
普通のpageの場合、消費すべきメモリ:4 M*4 K=16 G;このプロセスは最大16 Gを占めています
システムのデフォルトはTHPをオンにして、各pageは2 Mになったので、この過程の最大占有メモリ4 M*2 M=8192 G;
kvのsizeは小さいため、多くのkvは同じpageにあるため、実際の占有内には25 G mem&20 G+swapが存在する.
4 THPオフ
THPをオフにし、カウントサービスを再起動し、100 Gデータのバックアッププロセスを再起動し、更新に圧力がかかりません.
まとめてみると、forkバックアップでは、メインプロセスの変更プロセスがcowになり、LinuxではデフォルトでTHPが有効になり、書き込み増幅(1 byteを更新しても、実際のメモリは2 M bytesを新たに消費する必要がある可能性があります)が発生し、メモリがボトルネックになり、swap、応答が遅く、極端な状況ではosに乾かされてcrashなどが発生します.
5 THPをオフにする方法
1)boot時に有効にgrubを修正する.cfg
transparent_hugepage=never2)runtimeは修正
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag6 More about THP
Transparent hugepageはhugepage管理の簡略化版で、Linux 2.6.38以降に自動的に有効になり、anonymous memのみに有効になり、grep-i AnonHugePages/proc/meminfoで実際の使用状況を表示できます.
通常のcacheアプリケーションでは,デフォルトのTHPは性能が向上するが,forkがありforkが長い場合は資源占有状況を観測する必要があり,必要に応じてTHPを閉じる.
runtime期間中はTHPをオフにし、以前に割り当てられたhugepageは引き続き有効になり、新しい割り当てられたpageに対してのみhugepageを採用せず、osもscan&merge pagesを採用しない.
プロセスはmadviseでTHPを有効にするかどうかを設定できます.
#include
int madvise(void *addr, size_t length, int advice); 参照先:
https://access.redhat.com/solutions/46111
http://lwn.net/Articles/423584/
http://lwn.net/Articles/423592/