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