アカウント名:
パスワード:
じゃあかんの?マルチユーザーやシングルユーザーでも特定プロセスの暴走でメモリー不足からのシステム不良が起こるなら事前に最大ヒープサイズを制限するとかじゃあかんの?他にも有ったけど問題のないプロセスを無作為に殺す仕様が理解できない
(昔のこと)Linuxカーネルの場合、メモリ不足でプロセスが死ぬのは、メモリを確保した時点ではなくて、ホントにそのメモリに書き込んだときだったのね。かなり端折って言えば、mallocは常に成功(overcommit)、確保したメモリに初めて書こうとした時点でカーネルが実際にメモリを確保、その時点 でメモリ不足になっていたら例外発生ってな感じ。これじゃあまともなアプリは作れないってんで、overcommit=0にする設定もあったんだけど、デフォルト0じゃなかったのね。この仕掛けだと、メモリ不足になったのは大食いのアプリがあったからなんだろうけど、killされるプロセスはメモリ不足に陥ったときにたまたま(メモリ確保を伴う)メモリ書き込みをしたプロセスなのね。それじゃあ理不尽でしょ。
(今のこと)しらん。
飛行機のオーバーブッキングみたいねチケット持ってるのに、後から来たという理由で乗れない
だって乗客がめちゃくちゃに空予約するから、オーバーブックしないと座席ガラガラなんですよ。
今はovercommit=0がデフォルトだけど、0でもovercommitするぞ。馬鹿げたサイズのアロケーションは弾くって程度のチェックであって、事実上1と大差ない。厳密にチェックするのは2。
とはいえ、VSSとRSSが大きく乖離するなんて当たり前だし、こいつらを近づけるのはかーなーり面倒くさい。スレッド立てるだけでもスタックサイズ気にしないとだし、mallocすら気軽に叩けない。
overcommit=0 にして安全に利用できる範囲に絞り込むと、サービスやバッチの実行の組み合わせ等がシビアになる一方で、メモリの実使用率がすっかすかになるんですよね……。
# OOM killerの仕組みは端的に言ってクソだと思うけど、# 既にovercommit + OOM killerの組み合わせが前提になってる気がする。
> # OOM killerの仕組みは端的に言ってクソだと思うけど、 この仕組みを初めて知った時、目が点になりましたよ。
スワップいっぱい取ればいいだけちゃうのか。今時ディスクなんか安いんだし。# OOM Killerの話を聞いた時には唖然とした。
複数のデータベースのプロセスが数TBのスパースファイルをまるっとmmapしたら「ディスクなんて安いんだし」なんて太平楽はこいてられなくなる、って話じゃないかな。知らんけど。
ファイルをmmapするとファイルバックエンドなメモリになる(逆はanonymousで、スワップに書き出される対象)ので、スワップの空きによらずmmapいけるんじゃないかと思う。
CRTだかOSだかしらんけど、最近の環境ではアロケートは成功するのにアクセスすると SEGV になったりするので、「アロケートに失敗したら適切に終了する」ができなかったりするんですよ。
現実の運用は、デスクトップならallocateが失敗しない様に(OOMに至らない様に)、ユーザが利用可能メモリを監視し、不要なプロセスを終了する。というものです。
「問題のないプロセス〜」ではなく「加護のないプロセスを無作為に殺す仕様」だったかと思います。
毎日毎日rebootするたびに子供にecho -17 /proc/***/oom_adjして回りました。
OOM Killerに亭主を殺されて一年が経ちました。 [tumblr.com]
ところで、「アロケートに失敗したら適切にエラー処理をする」と言いますが、実際にしたことありますか?「適切に処理する」「適切にエラー処理をする」とだけ書いてある仕様書渡されて、コード書けますか?「適切にエラー処理をす
自分はデスクトップアプリケーションの開発だからメニュー等から機能を選択→処理過程で失敗→原状復帰して「メモリー不足で実行できません」と表示の流れで処理してましたが?そもそも私がここで詳細仕様を提示する必要がありませんGC前提の富豪プロレスしかしたことない人には想像できないのでしょうがオフトピです電気のアロケーション処理?は専門外だから知りません節電も何も普段から無駄に電気を使ってないですが待機電源を減らすためにプラグを抜くような事はしてませんよ例え話のつもりかも知れませんが例えになってないただのオフトピです
> 自分はデスクトップアプリケーションの開発だから
main() がコールされる前にメモリ不足になった場合の処理はどうやって実装してますか?「メモリー不足で実行できません」を表示する処理でメモリ不足が起きた場合のエラー処理はどう実装してますか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
アロケートに失敗したら適切にエラー処理をする (スコア: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すら気軽に叩けない。
Re:アロケートに失敗したら適切にエラー処理をする (スコア:1)
overcommit=0 にして安全に利用できる範囲に絞り込むと、サービスやバッチの実行の組み合わせ等がシビアになる一方で、メモリの実使用率がすっかすかになるんですよね……。
# OOM killerの仕組みは端的に言ってクソだと思うけど、
# 既にovercommit + OOM killerの組み合わせが前提になってる気がする。
Re: (スコア:0)
> # OOM killerの仕組みは端的に言ってクソだと思うけど、
この仕組みを初めて知った時、目が点になりましたよ。
Re: (スコア:0)
スワップいっぱい取ればいいだけちゃうのか。今時ディスクなんか安いんだし。
# OOM Killerの話を聞いた時には唖然とした。
Re: (スコア:0)
複数のデータベースのプロセスが数TBのスパースファイルをまるっとmmapしたら「ディスクなんて安いんだし」なんて太平楽はこいてられなくなる、って話じゃないかな。知らんけど。
Re: (スコア:0)
ファイルをmmapするとファイルバックエンドなメモリになる(逆はanonymousで、スワップに書き出される対象)ので、スワップの空きによらずmmapいけるんじゃないかと思う。
Re: (スコア:0)
CRTだかOSだかしらんけど、最近の環境ではアロケートは成功するのに
アクセスすると SEGV になったりするので、「アロケートに失敗したら
適切に終了する」ができなかったりするんですよ。
Re: (スコア:0)
現実の運用は、デスクトップならallocateが失敗しない様に(OOMに至らない様に)、ユーザが利用可能メモリを監視し、不要なプロセスを終了する。というものです。
「問題のないプロセス〜」ではなく「加護のないプロセスを無作為に殺す仕様」だったかと思います。
毎日毎日rebootするたびに子供にecho -17 /proc/***/oom_adjして回りました。
OOM Killerに亭主を殺されて一年が経ちました。 [tumblr.com]
ところで、「アロケートに失敗したら適切にエラー処理をする」と言いますが、実際にしたことありますか?
「適切に処理する」「適切にエラー処理をする」とだけ書いてある仕様書渡されて、コード書けますか?
「適切にエラー処理をす
Re: (スコア:0)
自分はデスクトップアプリケーションの開発だから
メニュー等から機能を選択→処理過程で失敗→原状復帰して「メモリー不足で実行できません」と表示
の流れで処理してましたが?
そもそも私がここで詳細仕様を提示する必要がありません
GC前提の富豪プロレスしかしたことない人には想像できないのでしょうがオフトピです
電気のアロケーション処理?は専門外だから知りません
節電も何も普段から無駄に電気を使ってないですが
待機電源を減らすためにプラグを抜くような事はしてませんよ
例え話のつもりかも知れませんが例えになってないただのオフトピです
Re: (スコア:0)
> 自分はデスクトップアプリケーションの開発だから
main() がコールされる前にメモリ不足になった場合の処理はどうやって実装してますか?
「メモリー不足で実行できません」を表示する処理でメモリ不足が起きた場合のエラー処理はどう実装してますか?
Re: (スコア:0)
main() がコールされる前の話とか、この予備領域の確保にすら失敗する状態のことまでは流石に対策してないけどね