| 著作一覧 |
using System;
using System.IO;
public class Mem {
public static void Main() {
//System.Console.WriteLine("MaxWorkingSet=" + System.Diagnostics.Process.GetCurrentProcess().MaxWorkingSet);
String content = new String(' ', 1024 * 1024);
MemoryStream ms = new MemoryStream();
using (StreamWriter sw = new StreamWriter(ms)) {
try {
for (int i = 0; i < 1000000; i++) {
sw.Write(content);
}
} catch (OutOfMemoryException) {
System.Console.WriteLine(ms.Position);
System.Console.WriteLine(GC.GetTotalMemory(false));
}
}
}
}
を動かすと、その時々のマシンの空きメモリーによって異なる結果になる。
C:\Home\arton\test>Mem Mem 134217728 136361180 C:\Home\arton\test>Mem Mem 134217728 136339824 ハンドルされていない例外 : OutOfMemoryException. C:\Home\arton\test>Mem Mem 268435456 270828636
ちゃんと終了できる場合もあれば、「ハンドルされていない例外：……」で結局殺される場合もある。
Javaだと
C:\Home\arton\test>java -Xms1024m -Xmx1024m Zen java -Xms1024m -Xmx1024m Zen Error occurred during initialization of VM Could not reserve enough space for object heap
最低メモリーサイズを指定すれば、そもそも動けない場合には最初から実行されない。お仕事実行の場合は、こっちのほうが望ましい。いつもは200MB余裕で動くけどたまたま128MBで殺されるというのでは（そこまでの実行時間が無駄になるし）運用が厄介だ。
というわけで、*.configで指定できるんじゃなかろうかと思ってMSDNを引っくり返したがそんな要素は無いみたいに見える。
実行に必要なメモリーサイズの下限／上限の指定の仕方をご存知の方がいたら教えていただけませんか？
追記：流れてしまったけどNyaRuRuさんやLady.BUGさんからご教示をいただきました。ありがとうございます。結論から言うとCLRHosting APIを利用して自分でやる、ということのようです。いろいろ参考になるURLを教えていただいているので、興味がある方はBefore...をクリックして参照してください。大人になると誰も指摘してくれなくなるかわりにはてなB（と書くのか?）にクソミソ書かれるわけだが、書かれたほうが大人の場合、反省の弁がきちんと内容を理解した上で(だからYahoo!ブログの特異性がこれまたわかって興味深い反応になったり)出てくるということか。
ただ、どうもよくわからないのは注意書きがついた元の記事と同じ内容で注意書きなしの別の記事があることなんだけど、これはなんなのだろう。バックアップ? こっちも注意書きを入れたほうがいいんじゃないかな。(追記：5月のほうのはコメント欄に注が入ってた)
あなたの管理者が知っておくべきことって副題だが。
ジェズイットを見習え |
> 実行に必要なメモリーサイズの下限／上限<br>確実なのは CLRHosting API を利用して，自前のメモリアロケータに置き換えてしまうことですかね．この部分は Visual C++ でも引っ張り出して Unmanaged な COM で書く必要がありますけど．<br>http://community.bartdesmet.net/blogs/bart/archive/2005/07/24/2984.aspx<br>http://www.amazon.de/exec/obidos/ASIN/0735619883<br>SQL Server 2005 はこの手で SQLCLR の使用メモリをトラックしています．<br><br>*.config では出来そうな気もしますしそこまで気が回らなそうな気もします．
日本の Amazon に訂正．<br>http://www.amazon.co.jp/exec/obidos/ASIN/0735619883<br>ただしこの本は .NET 2.0 のベータ版向けに書かれたものなので，いくつかの記述は古いかもしれません．
おお、どうもありがとうございます。<br>それにしても自前かぁ……メモリーが確保できなければ実行しないというユースケース（というかパターン言語というか）って無いのかな……
このあたりは Hosting API 運用になりますね。<br><br>http://d.hatena.ne.jp/ladybug/20050712<br><br>これは、mscorlib.dll を COM コンポーネントとしてインポートして、自分で自分に対して CorBindToCurrentRuntime() を実行し、自分自身のメモリアロケーションを制御しようとしています。
CLR の代表ホストといえば ASP.NET だと思いますが、メモリに関しては上限を設定できますけど起動下限は設定でいないですね。<br>他には、標準の実行可能ファイル形式と比較すると、ASP.NET ワーカープロセスには SMP 環境では CPU マスクが設定できたりします。<br><br>標準の実行ファイル形式のホスティングは、Windows の場合 OS によって実装が異なるので、Windows 2000 などに限定すれば editbin /heap で多少の対応がとれるかもしれません。
http://d.hatena.ne.jp/ladybug/20050712 <br>難しいけど、やっと意味がわかりました(intfX.GetYYY(out intfY); // throw NullReferenceExceptionの行は、intfYがnullで戻るという意味なのか呼び出しそのものが例外となるのかわからないですが)。<br>確かに、運用がどうしたという話であれば、自分で作れば良いだけなので大した問題じゃなかったですね。<br>どうもありがとうございます。<br>#それにしても知らない間に、世の中は随分先に進んでいますね。
NyaRuRuさんが紹介してくれた本って面白そうだけど迷うなぁ
>メモリーが確保できなければ実行しないというユースケース（というかパターン言語というか）<br><br>CLR 2.0 は良くも悪くも SQL Server 2005 に組み込むという具体的なシナリオがあったので，色々それに絡んだ機構が導入されています．この資料あたりがおすすめです．<br>http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/default.aspx<br><br>なんだかんだで CLR はほぼ全てユーザモードで実装されるため，AppDomain のような擬似プロセスの実装にもカーネル内部の仕組みは使えません．カーネルリソースに対してカーネルが行っているようなリーク対策を CLR はユーザモードで実装することになります．<br>これは ASP.NET のように短期間でプロセスが終了するような場合であればそれなりに運用でカバーできる面もありますが (つまり最後はカーネルがカバーする) ，SQLCLR のように長期間稼動するプロセス内部にホストされ続ける場合には，カーネル並の信頼性を CLR に再実装する必要が現実の問題として現れます．<br>.NET 1.0 が出た直後から開発者の blog では言及されていて気になってたんだろーなーという印象を受けましたが，今回めでたく優先して作業することができたみたいですね．<br><br>今回の取り組みでは，従来の「例外が発生したらどうする？」という議論から一歩踏み込んだ話に進める可能性を感じます．なんとなくですが．<br>例えば「失敗後の被害」をあらかじめ属性でマーキングする（「実行しても安全だとマークされている ActiveX コントロール」並に怪しいですが）ReliabilityContract 属性によって，致命的問題の性質の記述に一定の文法が生まれています．<br>他にも PrepareConstrainedRegions は，コールグラフにまで踏み込む実行時コード検証によって，トランザクショナルな実行のサポートを行います．(悲惨な理由で失敗するかどうか先に調べられる)<br><br>先ほどのこれに出てくる EMemoryCriticalLevel もある意味のパターン化でしょうかね．<br>http://community.bartdesmet.net/blogs/bart/archive/2005/07/24/2984.aspx
追記．<br>先ほどの MSDN Magazine の記事ですが，MSDN Flash ニュースレター購読者の方向けにこちらで邦訳が公開されています．<br>https://www.microsoft.com/japan/msdn/msdnmag/issues/05/10/Reliability/default.aspx
"Java to Ruby"は正確には達人の本棚シリーズです。http://www.pragmaticprogrammer.com/titles/fr_j2r/index.html<br>"Beyond Java"のBruce A.Tateの新刊。
NyaRuRuさん、このHIGH Availabilityの記事は確かに読む価値がありますね。どうもありがとうございます（とりあえず最初の節だけ読んだ−と思ったら翻訳の紹介もしていただいていたんですね。パスポート持ってて良かった）。<br>>達人の本棚<br>うーむ、達人になるに連れて道具が軽くなる（最初は真剣、次は木刀、最後は扇子）みたいな。
しかしCLRはどんどん方向を外しているようにも見える。これをマネージドの世界でやる意味あるんだろうか？ クリティカルな領域はバイナリーの世界に置いておいたほうが良いのではないか、とかいろいろ。ああ、そうか、.NET 2.0だったな（そろそろ「2.0」も飽きたけど）