アカウント名:
パスワード:
Linuxに関わっていない者ですがOSとしてこういう動作はどうよ？っと思いますずっと前からあるらしいし議論も尽くされているんでしょうが…
oom killerをデフォルトで使っているのは、oom killerなんか気にしていないカジュアルユーザぐらいだと思いますよ。
基幹システムのモデルテストをやっていた頃は、panic_on_oomでoom時にpanicさせて、kdumpでvmcore採って、検死作業なんてルーチンワークがあったなあ。
最近では、cgroupでメモリ資産管理をやって、oomの原因になったgroupに限定してoom killerを動かすという議論があったと思います。絶対にOOM killerで殺されないプロセスというのも、cgroupを使えば設定可能になっていたはずです。富士通とIBMの関係者が基幹システム向けに必要だというので、ご執心だった記憶がある。
たまには、Documentation/cgroups/memory.txtを読んでおいた方がいいですよ。
#富士通の下請けで働いていた時にお世話になった亀澤氏は、元気にしているかなあ。#確か、cgroupの専門家の重鎮だったはずです。
長年使ってるがOOMキラーが発動したのは数回しか経験ないな。緊急対応としては仕方ない。むしろ実にシンプルな方法なので気に入ってる。使えるメモリを完全に食い尽くしてしまうような状況に陥っていることが問題の根なわけだからさ、そうっちをどうにかしなきゃならん。
>緊急対応としては仕方ない
いや、そんなわけはないでしょう。メモリ確保の段階でチェックするのがあるべき姿で、Linuxがさぼっているだけです。（Linuxのメモリ確保はけして失敗しない）
まあチェックといっても難しいのですが。
それに加えて、panic_on_oom=1すればいいじゃない。
>まあチェックといっても難しいのですが。
最新のlinuxのメモリ管理がどうなっているのか判らないのですが
sbrkで要求された空間分をswapに予約しておく。swapに空きがなければsbrkを失敗させる。
というだけの話では済まないのでしょうか?
> 使えるメモリを完全に食い尽くしてしまうような状況に陥っていることが問題の根なわけだからさ、そうっちをどうにかしなきゃならん。
同様に考えていましたが、最近VMware仮想環境を使うようになったらOOM Killerが発動するようになってしまい困りました。Linux VMに十分なメモリを割り当てていたのでOOM Killerとは無縁と考えていましたが、VMware Toolsが未使用メモリを回収してしまうため、アプリの高負荷時にOOM Killerが発動してしまいました。解決法はないのだろうか。。。
出尽くしてるけど、オーバコミットを禁止する設定に変えるか、保護したいプロセスを指定するか、OOM Killerを止める(panic_on_oomでOSを落とす)設定にするかすればいい。…でも、そのケースはVM絡みだしなんか違う可能性もあるような気がちょびっと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
この仕組ってどうなのよ？ (スコア:0)
Linuxに関わっていない者ですがOSとしてこういう動作はどうよ？っと思います
ずっと前からあるらしいし議論も尽くされているんでしょうが…
Re:この仕組ってどうなのよ？ (スコア:5, 参考になる)
oom killerをデフォルトで使っているのは、oom killerなんか気にしていないカジュアルユーザぐらいだと思いますよ。
基幹システムのモデルテストをやっていた頃は、panic_on_oomでoom時にpanicさせて、kdumpでvmcore採って、検死作業なんてルーチンワークがあったなあ。
最近では、cgroupでメモリ資産管理をやって、oomの原因になったgroupに限定してoom killerを動かすという議論があったと思います。絶対にOOM killerで殺されないプロセスというのも、cgroupを使えば設定可能になっていたはずです。富士通とIBMの関係者が基幹システム向けに必要だというので、ご執心だった記憶がある。
たまには、Documentation/cgroups/memory.txtを読んでおいた方がいいですよ。
#富士通の下請けで働いていた時にお世話になった亀澤氏は、元気にしているかなあ。
#確か、cgroupの専門家の重鎮だったはずです。
Re:この仕組ってどうなのよ？ (スコア:1)
長年使ってるがOOMキラーが発動したのは数回しか経験ないな。
緊急対応としては仕方ない。むしろ実にシンプルな方法なので気に入ってる。
使えるメモリを完全に食い尽くしてしまうような状況に陥っていることが問題の根なわけだからさ、そうっちをどうにかしなきゃならん。
Re: (スコア:0)
>緊急対応としては仕方ない
いや、そんなわけはないでしょう。メモリ確保の段階でチェックするのがあるべき姿で、Linuxがさぼっているだけです。
（Linuxのメモリ確保はけして失敗しない）
まあチェックといっても難しいのですが。
Re:この仕組ってどうなのよ？ (スコア:2, 参考になる)
2にすれば，overcommit_ratio で指定した上限以上のメモリを確保しようとしたときに，その場で失敗します．
参考: https://www.centos.org/docs/4/4.5/Reference_Guide/s3-proc-sys-vm.html
ただ，overcommit をやめただけでは， OOM Killer の発動を完全には止められないらしいです．
(詳細わかってません．カーネル空間でのメモリ使用量が増えるときに，ユーザ空間のプロセスが追い出されるのかも)
Re: (スコア:0)
それに加えて、panic_on_oom=1すればいいじゃない。
Re: (スコア:0)
>まあチェックといっても難しいのですが。
最新のlinuxのメモリ管理がどうなっているのか判らないのですが
sbrkで要求された空間分をswapに予約しておく。
swapに空きがなければsbrkを失敗させる。
というだけの話では済まないのでしょうか?
Re: (スコア:0)
> 使えるメモリを完全に食い尽くしてしまうような状況に陥っていることが問題の根なわけだからさ、そうっちをどうにかしなきゃならん。
同様に考えていましたが、最近VMware仮想環境を使うようになったらOOM Killerが発動するようになってしまい困りました。
Linux VMに十分なメモリを割り当てていたのでOOM Killerとは無縁と考えていましたが、VMware Toolsが未使用メモリを回収してしまう
ため、アプリの高負荷時にOOM Killerが発動してしまいました。
解決法はないのだろうか。。。
Re: (スコア:0)
出尽くしてるけど、オーバコミットを禁止する設定に変えるか、保護したいプロセスを指定するか、OOM Killerを止める(panic_on_oomでOSを落とす)設定にするかすればいい。
…でも、そのケースはVM絡みだしなんか違う可能性もあるような気がちょびっと。