プロセスが「RAM不足により強制終了」された場合、何が起こる可能性がありますか？
linuxは、デフォルトではアプリケーションコードからのより多くのメモリの要求を拒否しないと言われることがありますmalloc()。1 これは実際には真実ではありません。デフォルトでは、ヒューリスティックを使用します。
アドレス空間の明らかな超過は拒否されます。典型的なシステムに使用されます。オーバーコミットを許可してスワップの使用量を削減しながら、深刻なワイルド割り当てが失敗することを保証します。
From [linux_src]/Documentation/vm/overcommit-accounting（すべての引用は3.11ツリーからのものです）。「真剣にワイルドな割り当て」とみなされるものは明確にされていないため、ソースを調べて詳細を決定する必要があります。また、脚注2（下記）の実験的手法を使用して、ヒューリスティックの一部を反映しようとすることもできます-それに基づいて、私の最初の経験的観察は、理想的な状況（==システムがアイドル状態）である場合、スワップがない場合は、RAMの約半分を割り当てることができます。スワップがある場合は、RAMの約半分とすべてのスワップを取得できます。これはプロセスごとに多少なります（ただし、この制限は動的であり、状態によって変化する可能性があることに注意してください。脚注5の所見をご覧ください）。
RAMの半分とスワップが、の「CommitLimit」フィールドの明示的なデフォルトです/proc/meminfo。これが何を意味するかです-そして、それが実際に議論した制限とは何の関係もないことに注意してください（から[src]/Documentation/filesystems/proc.txt）：
CommitLimit：オーバーコミット率（ 'vm.overcommit_ratio'）に基づいて、これは現在システムに割り当てられるメモリの合計量です。この制限は、厳密なオーバーコミットアカウンティングが有効になっている場合にのみ順守されます（「vm.overcommit_memory」のモード2）。CommitLimitは次の式で計算されます：CommitLimit =（ 'vm.overcommit_ratio' * Physical RAM）+ Swapたとえば、1Gの物理RAMと7Gのスワップで 'vm.overcommit_ratio'が30のシステムでは、次のようになります。 7.3GのCommitLimit。
以前に引用したovercommit-accountingのドキュメントには、デフォルトvm.overcommit_ratioが50であると記載されています。したがってsysctl vm.overcommit_memory=2、を使用すると、vm.covercommit_ratio（with sysctl）を調整して結果を確認できます。3 デフォルトモードは、CommitLimit施行されず、「アドレススペースの明白なオーバーコミットが拒否される」場合のみvm.overcommit_memory=0です。
デフォルト戦略にはプロセスごとの制限があり、「真剣にワイルドな割り当て」を防ぐことができますが、システム全体としては真剣にワイルドな割り当てを行うことができます。4 これは、ある時点でメモリ不足になり、OOM killerを介していくつかのプロセスに破産を宣言する必要があることを意味します。
OOMキラーは何を殺しますか？必ずしも何もなかったときにメモリを要求したプロセスである必要はありません。それは必ずしも真の有罪プロセスであるとは限らないためです。
これはおそらく2.6.xのソースを引用しているここから引用されています：
/*
* oom_badness - calculate a numeric value for how bad this task has been
*
* The formula used is relatively simple and documented inline in the
* function. The main rationale is that we want to select a good task
* to kill when we run out of memory.
*
* Good in this context means that:
* 1) we lose the minimum amount of work done
* 2) we recover a large amount of memory
* 3) we don't kill anything innocent of eating tons of memory
* 4) we want to kill the minimum amount of processes (one)
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
*/
それはまともな根拠のように思えます。ただし、フォレンジックを取得しないと、＃5（＃1の冗長性）は難しい実装のように見え、＃3は＃2の冗長性を持ちます。したがって、これを＃2/3と＃4に削減することを検討するのは理にかなっているかもしれません。
最近のソース（3.11）を読んで、このコメントが暫定的に変更されていることに気付きました。
/**
* oom_badness - heuristic function to determine which candidate task to kill
*
* The heuristic for determining which task to kill is made to be as simple and
* predictable as possible. The goal is to return the highest value for the
* task consuming the most memory to avoid subsequent oom failures.
*/
これは、より明確にについて少しです＃2：「目標は、ほとんどのメモリを消費するタスクは、後続のOOMの失敗を避けるために[キル]にある」と暗に＃4による（「我々は（プロセスの最小量を殺したいものを） ）。
OOMキラーの動作を確認するには、脚注5を参照してください。
1妄想ジルは、ありがたいことに私を追い払った、コメントを参照してください。
2次のCの簡単なビットは、メモリのチャンクをますます大きくして、追加の要求がいつ失敗するかを判断します。
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#define MB 1 << 20
int main (void) {
uint64_t bytes = MB;
void *p = malloc(bytes);
while (p) {
fprintf (stderr,
"%lu kB allocated.\n",
bytes / 1024
);
free(p);
bytes += MB;
p = malloc(bytes);
}
fprintf (stderr,
"Failed at %lu kB.\n",
bytes / 1024
);
return 0;
}
Cがわからない場合は、これをコンパイルしてgcc virtlimitcheck.c -o virtlimitcheckから実行できます./virtlimitcheck。プロセスは要求するスペースを使用しないため、完全に無害です。つまり、実際にRAMを使用することはありません。
4 GBシステムと6 GBのスワップを備えた3.11 x86_64システムでは、〜7400000 kBで失敗しました。数は変動するため、おそらく状態が要因です。これは偶然CommitLimitin /proc/meminfoに近いですが、このviaを変更vm.overcommit_ratioしても違いはありません。ただし、64 MBのスワップがある3.6.11 32ビットARM 448 MBシステムでは、〜230 MBで失敗します。これは、最初のケースではRAMの量がほぼ2倍であるのに対し、2番目のケースでは約1/4であるため、興味深いものです-スワップの量を強く示唆することが要因です。これは、障害しきい値が約1.95 GBに低下したときに最初のシステムでスワップをオフにすることで確認されました。これは、小さなARMボックスと非常によく似た比率です。
しかし、これは本当にプロセスごとですか？のようです。以下の短いプログラムは、ユーザーが定義したメモリチャンクを要求し、成功した場合は、リターンキーが押されるまで待機します。これにより、複数の同時インスタンスを試すことができます。
#include <stdio.h>
#include <stdlib.h>
#define MB 1 << 20
int main (int argc, const char *argv[]) {
unsigned long int megabytes = strtoul(argv[1], NULL, 10);
void *p = malloc(megabytes * MB);
fprintf(stderr,"Allocating %lu MB...", megabytes);
if (!p) fprintf(stderr,"fail.");
else {
fprintf(stderr,"success.");
getchar();
free(p);
}
return 0;
}
ただし、使用量に関係なく、RAMとスワップの量に関する厳密なものではないことに注意してください。システム状態の影響については、脚注5を参照してください。
3 CommitLimitは、vm.overcommit_memory = 2の場合にシステムに許可されるアドレス空間の量を示します。おそらく、割り当てることができる量は、すでにコミットされているものからCommitted_ASフィールドを引いたものである必要があります。
これを実証する潜在的に興味深い実験は#include <unistd.h>、virtlimitcheck.cの先頭（脚注2を参照）とループのfork()直前に追加することwhile()です。面倒な同期を行わずにここで説明されているように動作することは保証されていませんが、YMMVが実行される可能性は十分にあります。
> sysctl vm.overcommit_memory=2
vm.overcommit_memory = 2
> cat /proc/meminfo | grep Commit
CommitLimit: 9231660 kB
Committed_AS: 3141440 kB
> ./virtlimitcheck 2&> tmp.txt
> cat tmp.txt | grep Failed
Failed at 3051520 kB.
Failed at 6099968 kB.
これは理にかなっています-tmp.txtを詳細に見ると、プロセスがより大きな割り当てを交互に繰り返すことがわかります（出力にpidを投入すると、これは簡単です）。それから勝者はCommitLimitマイナスまですべてを自由につかむことができCommitted_ASます。
4この時点で、仮想アドレッシングとデマンドページングをまだ理解していない場合、そもそもオーバーコミットが可能になるのは、カーネルがユーザーランドプロセスに割り当てるものが物理メモリではないということです。仮想アドレススペース。たとえば、プロセスが何かのために10 MBを予約した場合、それは（仮想）アドレスのシーケンスとしてレイアウトされますが、それらのアドレスはまだ物理メモリに対応していません。そのようなアドレスにアクセスすると、ページ違反が発生しますそして、カーネルはそれを実際のメモリにマップして、実際の値を保存できるようにします。プロセスは通常、実際にアクセスするよりもはるかに多くの仮想スペースを予約するため、カーネルはRAMを最も効率的に使用できます。ただし、物理メモリは依然として有限のリソースであり、物理メモリのすべてが仮想アドレス空間にマッピングされた場合、一部の仮想アドレス空間を削除してRAMを解放する必要があります。
5最初に警告：でこれを試す場合はvm.overcommit_memory=0、作業を保存してから重要なアプリケーションをすべて閉じてください。システムは90秒までフリーズし、一部のプロセスが停止します。
アイデアは、90秒後にタイムアウトするフォークボムを実行することです。フォークはスペースを割り当て、その一部はstderrに報告しながら大量のデータをRAMに書き込みます。
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/time.h>
#include <errno.h>
#include <string.h>
/* 90 second "Verbose hungry fork bomb".
Verbose -> It jabbers.
Hungry -> It grabs address space, and it tries to eat memory.
BEWARE: ON A SYSTEM WITH 'vm.overcommit_memory=0', THIS WILL FREEZE EVERYTHING
FOR THE DURATION AND CAUSE THE OOM KILLER TO BE INVOKED. CLOSE THINGS YOU CARE
ABOUT BEFORE RUNNING THIS. */
#define STEP 1 << 30 // 1 GB
#define DURATION 90
time_t now () {
struct timeval t;
if (gettimeofday(&t, NULL) == -1) {
fprintf(stderr,"gettimeofday() fail: %s\n", strerror(errno));
return 0;
}
return t.tv_sec;
}
int main (void) {
int forks = 0;
int i;
unsigned char *p;
pid_t pid, self;
time_t check;
const time_t start = now();
if (!start) return 1;
while (1) {
// Get our pid and check the elapsed time.
self = getpid();
check = now();
if (!check || check - start > DURATION) return 0;
fprintf(stderr,"%d says %d forks\n", self, forks++);
// Fork; the child should get its correct pid.
pid = fork();
if (!pid) self = getpid();
// Allocate a big chunk of space.
p = malloc(STEP);
if (!p) {
fprintf(stderr, "%d Allocation failed!\n", self);
return 0;
}
fprintf(stderr,"%d Allocation succeeded.\n", self);
// The child will attempt to use the allocated space. Using only
// the child allows the fork bomb to proceed properly.
if (!pid) {
for (i = 0; i < STEP; i++) p[i] = i % 256;
fprintf(stderr,"%d WROTE 1 GB\n", self);
}
}
}
これをコンパイルしgcc forkbomb.c -o forkbombます。まず、試してみてsysctl vm.overcommit_memory=2ください。おそらく次のようになります。
6520 says 0 forks
6520 Allocation succeeded.
6520 says 1 forks
6520 Allocation succeeded.
6520 says 2 forks
6521 Allocation succeeded.
6520 Allocation succeeded.
6520 says 3 forks
6520 Allocation failed!
6522 Allocation succeeded.
この環境では、この種のフォーク爆弾はそれほど遠くありません。「says N forks」の数はプロセスの総数ではなく、チェーン/ブランチ内のそのプロセスに至るプロセスの数であることに注意してください。
今すぐ試してみてくださいvm.overcommit_memory=0。stderrをファイルにリダイレクトする場合、後で粗雑な分析を行うことができます。例えば：
> cat tmp.txt | grep failed
4641 Allocation failed!
4646 Allocation failed!
4642 Allocation failed!
4647 Allocation failed!
4649 Allocation failed!
4644 Allocation failed!
4643 Allocation failed!
4648 Allocation failed!
4669 Allocation failed!
4696 Allocation failed!
4695 Allocation failed!
4716 Allocation failed!
4721 Allocation failed!
1 GBの割り当てに失敗したプロセスは15個だけでした。これは、overcommit_memory = 0のヒューリスティックが状態の影響を受けることを示しています。プロセスはいくつありましたか？tmp.txtの最後を見ると、おそらく100,000を超えています。では、実際に1 GBを使用するにはどうすればよいでしょうか？
> cat tmp.txt | grep WROTE
4646 WROTE 1 GB
4648 WROTE 1 GB
4671 WROTE 1 GB
4687 WROTE 1 GB
4694 WROTE 1 GB
4696 WROTE 1 GB
4716 WROTE 1 GB
4721 WROTE 1 GB
8-これは理にかなっています。当時は、〜3 GBのRAM空き容量と6 GBのスワップがあったからです。
これを行った後、システムログを確認してください。OOMのキラーレポートスコアが表示されるはずです（特に）。おそらくこれはに関連していoom_badnessます。