アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
スラッシング (スコア:1)
vmware や firefox 等を長時間使い続けていると、メモリを食い潰していき、しまいにはスラッシングが起きてしまい、ハードウェアリセットするしかなくなります。
これが嫌で今は Linux から X を立ち上げていません。
スラッシングを防ぐ仕組み等が備われば、ミッションクリティカルな用途への対応も少しは進むような気がしますが、現状のままでは疑問に思います。
Kernel-2.4.10～2.4.17を使っていませんか？ (スコア:1)
このバージョンに該当する場合、スラッシングが若干多めに発生した覚えがあります。
最近のカーネルでは解決されている印象があるのですがいかがでしょうか？
個人的にLinuxは、ミッションクリティカル用途で使える品質はあると思いますが、
ディストリビューションの選択・ファイルシステム・カーネル・glibcの選択で
難儀しそうな印象があります。
よっぽどLinuxが詳しい人が居ないと厳しいかもしれませんね。
Re:Kernel-2.4.10～2.4.17を使っていませんか？ (スコア:1)
当時私は既に2.6系を使っていました。
Re:スラッシング (スコア:0)
Re:スラッシング (スコア:0)
スラッシングが弱いって例に出しただけだって事もわかる。
でもあえて言う。
＞vmware や firefox 等を長時間使い続けていると、メモリを食い潰していき、しまいにはスラッシングが起きてしまい、ハードウェアリセットするしかなくなります。
そもそもミッションクリティカルなシステムにvmwareやWebブラウザなんて使わないから
社内LANでWindows系サーバ入れたとき、そのマシンにOfiice突っ込んで
普通に通常業務用マシンとしても使ってた上司思い出したので愚痴レス。
＃自分でそんな事に使ってる上で「なんか処理遅いんじゃない？」とか文句言うの
＃もうね・・・ orz
Re:スラッシング (スコア:1)
- 私がミッションクリティカルなシステムでvmwareやwebブラウザを使おうとしている訳ではありません。
- また、ミッションクリティカルなシステムでvmwareやwebブラウザを使うことを奨励している訳でもありません。
しかし、ミッションクリティカルなシステムで稼動させるアプリケーションの挙動が、vmwareやwebブラウザのようなメモリ食い潰し虫でない可能性はゼロとは言えません。
# もしも東証のシステムがLinuxだったら、ライブドアの取引殺到でスラッシングが起こるのかな?なんちって。
Re:スラッシング (スコア:0)
それが嫌なら最初から最大メモリと実行優先度を実行前にきちんと設定しておくべきです。
Re:スラッシング (スコア:1)
私は最初からMS-Windowsは考慮の対象として考えていません。
比較するつもりも毛頭ありません。
それは他の人がさんざん議論し尽くしているでしょうから。
誰もLinuxに対する具体的な欠点を列挙しなかったので、敢えて思い付くものを出しました。
> それが嫌なら最初から最大メモリと実行優先度を実行前にきちんと設定しておくべきです。
そうなんでしょうか?
それが「当り前」なんでしょうか?
他のスレッドでは商用UNIXを挙げている方を見掛けます。
Linuxより堅牢であると思われる理由があるからではないでしょうか。
私はあくまでエンドユーザでしかないので、OSの細かい話は良く解りませんが、私は、エンドユーザの目から見て、Linuxに対して、巷で言われる程堅牢なイメージを持っておりません。
Re:スラッシング (スコア:0)
そもそも、そんなアプリでシステムを組みません。
客が勝手に組み込んだプログラムがメモリとかCPUとか食い潰して大変なことになったということは何度かありますが、当然動作保証外です。
＃東証の場合は知りませんが、普通は設計時に想定した(＆動作試験で保証した)
＃ラインを超えそうだったら処理を止めるなり、負荷を下げるよう処置したりするんじゃないですか？
Re:スラッシング (スコア:1)
アプリのバグの話じゃない？
ギチギチにテストしてその上で
・linuxでもオッケーなので出荷
・念のため高いsolarisで出荷
という選択に思える。
これはトレードオフだと思うので、どっちもありなんじゃないの。
あ、あと金払いのいい客がヘマをしてもなるべくダメージが少ないようにするのはよい心掛けだと思うよ。
Re:スラッシング (スコア:1)
そうです。
この業界、「絶対大丈夫」はあり得ませんから。
あるシステムに乗って稼動するアプリが、いつどのような状況にあっても常に問題なく稼動できるか、といわれれば、そうでないことの方が多いでしょう。
アプリのせいにするのは簡単ですが、OSが停止してしまっては自動復旧処理等もできなくなってしまいます。
よく、MS-WindowsはアプリがこけるとブルーバックになってOSももろとも落ちる、と言われますが、Linuxのスラッシングもほぼ同じようなものだと思います。
そういう時のためのスラッシング防止機構というか、フェイルセーフ機能が備わっていてもいいんじゃないかな、と思う次第です。
例えば、メモリ消費量が閾値を超えたら、そのアプリに対しては malloc() を許容しない、で、アプリが規定時間を越えても応答しなくなったら kill -TERM させて再起動させる、みたいな感じでしょうか。
それと、vmwareを否定されていた方もいましたが、果たして全否定してしまって良いでしょうか。
将来、陳腐化したハードウェアで稼動していたアプリを使い続ける為に、エミュレータを用いる可能性もないとは言い切れません。
新しいハードウェア及びOS向けにコードを書き換えるか、エミュレータで過去の資産を稼動させるか、の選択を考慮する時が来るかもしれません。
Re:スラッシング (スコア:0)
＞ あるシステムに乗って稼動するアプリが、いつどのような状況にあっても常に問題なく稼動できるか、といわれれば、そうでないことの方が多いでしょう。
そのとおりです。なので、普通は常時動作(処理量やマシンの状態etc...)を監視してます。そのためのオペレータですから。
ちなみに、アプリが異常動作したときの挙動は商用UNIXでもあまり変わりませんね。OSが頑強でも、行儀の悪いプロセスがいればシステムを落とす事は簡単です。
Re:スラッシング (スコア:0)
>例えば、メモリ消費量が閾値を超えたら、そのアプリに対しては malloc() を許容しない、で、アプリが規定時間を越えても応答しなくなったら kill -TERM させて再起動させる、みたいな感じでしょうか。
以前、linux 2.4.21のkernelで、メモリをすべて使い切るようなものを作って試した時には、mallocした途端にそのアプリが落ちていました。(スワップもフルの状態ね)
linux自体が落ちるということは一回もありませんでしたが？
アプリが使用するメモリはulimitで設定できるはずですし、問題ないと思うんですが。