アカウント名:
パスワード:
じゃあかんの?マルチユーザーやシングルユーザーでも特定プロセスの暴走でメモリー不足からのシステム不良が起こるなら事前に最大ヒープサイズを制限するとかじゃあかんの?他にも有ったけど問題のないプロセスを無作為に殺す仕様が理解できない
(昔のこと)Linuxカーネルの場合、メモリ不足でプロセスが死ぬのは、メモリを確保した時点ではなくて、ホントにそのメモリに書き込んだときだったのね。かなり端折って言えば、mallocは常に成功(overcommit)、確保したメモリに初めて書こうとした時点でカーネルが実際にメモリを確保、その時点 でメモリ不足になっていたら例外発生ってな感じ。これじゃあまともなアプリは作れないってんで、overcommit=0にする設定もあったんだけど、デフォルト0じゃなかったのね。この仕掛けだと、メモリ不足になったのは大食いのアプリがあったからなんだろうけど、killされるプロセスはメモリ不足に陥ったときにたまたま(メモリ確保を伴う)メモリ書き込みをしたプロセスなのね。それじゃあ理不尽でしょ。
(今のこと)しらん。
今はovercommit=0がデフォルトだけど、0でもovercommitするぞ。馬鹿げたサイズのアロケーションは弾くって程度のチェックであって、事実上1と大差ない。厳密にチェックするのは2。
とはいえ、VSSとRSSが大きく乖離するなんて当たり前だし、こいつらを近づけるのはかーなーり面倒くさい。スレッド立てるだけでもスタックサイズ気にしないとだし、mallocすら気軽に叩けない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
アロケートに失敗したら適切にエラー処理をする (スコア:0)
じゃあかんの?
マルチユーザーやシングルユーザーでも特定プロセスの暴走でメモリー不足からのシステム不良が起こるなら事前に最大ヒープサイズを制限するとかじゃあかんの?
他にも有ったけど問題のないプロセスを無作為に殺す仕様が理解できない
Re: (スコア:1)
(昔のこと)
Linuxカーネルの場合、メモリ不足でプロセスが死ぬのは、メモリを確保した時点ではなくて、ホントにそのメモリに書き込んだときだったのね。
かなり端折って言えば、mallocは常に成功(overcommit)、確保したメモリに初めて書こうとした時点でカーネルが実際にメモリを確保、その時点 でメモリ不足になっていたら例外発生ってな感じ。
これじゃあまともなアプリは作れないってんで、overcommit=0にする設定もあったんだけど、デフォルト0じゃなかったのね。
この仕掛けだと、メモリ不足になったのは大食いのアプリがあったからなんだろうけど、killされるプロセスはメモリ不足に陥ったときにたまたま(メモリ確保を伴う)メモリ書き込みをしたプロセスなのね。それじゃあ理不尽でしょ。
(今のこと)
しらん。
Re:アロケートに失敗したら適切にエラー処理をする (スコア:0)
今はovercommit=0がデフォルトだけど、0でもovercommitするぞ。
馬鹿げたサイズのアロケーションは弾くって程度のチェックであって、事実上1と大差ない。
厳密にチェックするのは2。
とはいえ、VSSとRSSが大きく乖離するなんて当たり前だし、こいつらを近づけるのはかーなーり面倒くさい。
スレッド立てるだけでもスタックサイズ気にしないとだし、mallocすら気軽に叩けない。