socket.ioのheartbeat時におけるメモリリークについて

[koexuka]

こんにちわ、koexukaです。

socket.ioについて質問させて頂きます。

Linux(CentOS5.5) + Node(v0.6.18) + express + socket.io(v0.9.6)で簡単なアプリを作りベンチマークを取っております。

簡単なアプリと言うのは、

サーバ側はsocket.ioを使い接続を待受けるだけで内部的な処理は何もありません。

------// ソースここから ------------------------------------------------------------

var io = require('socket.io');

var socket = io.listen(app);

socket.on('connection', function(client) {

  // disconnect時だけconsoleにログ出力します。

  client.on('disconnect', function() {

    console.log('client disconnected');

  });

});

------// ソースここまで-----------------------------------------

また、socket.ioはconfigure()でheartbeat intervalを5秒に設定しています。

（heartbeat時のメモリリークを分かりやすくするために5秒にしています。）

------// ソースここから ------------------------------------------------------------

socket.configure('development', function() {

  socket.set('heartbeat interval', 5);

});

------// ソースここまで-----------------------------------------

この状態でクライアントから接続した場合、

heartbeatのタイミング（この例では5秒おき）でNodeがサーバのメモリを確保しているようです。

※メモリ確保量はpsコマンド出力のRSSの値（単位:Kbyte）で確認

※ちなみにheartbeat intervalを「3 」に変更すると、3秒おきにメモリ確保が見られます

確保されたメモリはGCにより定期的に開放されますが、

同時接続数を上げれば上げるほど確保されるメモリ量が多くなり、GCによる開放が間に合わない状態です。

（メモリ確保の量はまちまちですが、同時100接続の場合1回あたり1MB〜1.5MB確保される場合もあります）

接続を保ったまましばらく放置すると確保されるメモリ量は0に近づいていきますが、

もし実運用した場合、頻繁にクライアントからの接続はあるでしょうし、メモリリークが心配です。

hearbeatのタイミングでメモリの量が増加するので

heartbeat処理に狙いをつけてsocket.ioのソースを追ってみているところなのですが、

そのタイミングでWebsocket#writeメソッドにてクライアントへデータを送っている事までは分かりました。

内部的にはnet.Socket#writeが呼ばれていますが、公式のドキュメントにある

http://nodejs.jp/nodejs.org_ja/docs/v0.6/api/net.html#net_socket_buffersize

http://nodejs.jp/nodejs.org_ja/docs/v0.6/api/net.html#net_socket_write_data_encoding_callback

を読んで、送信データをバッファリングしていると示されていますが、

socket.bufferSizeを見ても返ってくる値は「0（ゼロ）」でどこに問題があるのか行き詰まっている状態です。

僕のプログラムソースが悪いのか、Linuxの設定が悪いのか、既知の問題なのか、、

もし何か情報をお持ちの方がいらっしゃれば、何でも構いませんので返信頂きたく思います。

すみませんが、よろしくお願い致します。

[Shigeki Ohtsu]

大津です。

> 僕のプログラムソースが悪いのか、Linuxの設定が悪いのか、既知の問題なのか、、
> もし何か情報をお持ちの方がいらっしゃれば、何でも構いませんので返信頂きた
> く思います。

ちょっと質問の意図が読み取れないのですが、何が「問題」なんでしょうか？

1. もしかしたらメモリリークしているかもしれないという心配が存在すること
が問題
2. heartbeat で使用されるメモリが想定している量より大きいことが問題
3. 接続が多数になるとGCが間に合わない状況になることが問題

GC 後に不要なメモリがちゃんと解放されているなら動作的には問題ないと思う
のですけど。

2. や 3. なら「パフォーマンスチューニングの方法が知りたい」ですよね。

[koexuka]

大津さん

koexukaです。返信ありがとうございます。

質問が分かりづらいですね。すみません。

ちょっと質問の意図が読み取れないのですが、何が「問題」なんでしょうか？ 
1. もしかしたらメモリリークしているかもしれないという心配が存在すること 
が問題 
2. heartbeat で使用されるメモリが想定している量より大きいことが問題 
3. 接続が多数になるとGCが間に合わない状況になることが問題 

問題なのは「３」です。

ベンチマークではサーバに対し多数（0〜1000）接続 し、disconnectやconnectを繰り返し

Nodeのメモリ使用量を監視していますが、

定期的に使用量がグッと下がる（恐らくGC）ことはありますが、長いスパンで見ると全体として増え続けています。

※どこかのタイミングで接続数を0（ゼロ）にしてしばらく経過すると、メモリ使用量はNode起動時の状態に戻りますが、実運用ではあり得ない状態だと思います。

この状態であれば、例えばメモリを2GB積んだサーバの場合、

２〜３日でメモリが枯渇してしまうのではないかと危惧しています。

この事について、もし似たような経験をお持ちの方がいらっしゃれば知恵をお借りできないかと思い、質問致しました。

よろしくお願い致します。

2012年5月30日水曜日 14時48分08秒 UTC+9 shigeki:

[Shigeki Ohtsu]

大津です。

> ベンチマークではサーバに対し多数（0〜1000）接続 し、disconnectやconnect
> を繰り返し
> Nodeのメモリ使用量を監視していますが、
> 定期的に使用量がグッと下がる（恐らくGC）ことはありますが、長いスパンで見
> ると全体として増え続けています。
> ※どこかのタイミングで接続数を0（ゼロ）にしてしばらく経過すると、メモリ使
> 用量はNode起動時の状態に戻りますが、実運用ではあり得ない状態だと思います。
>
> この状態であれば、例えばメモリを2GB積んだサーバの場合、
> ２〜３日でメモリが枯渇してしまうのではないかと危惧しています。

ちょっと使用量が大きいですね。

ちなみにベンチマークするクライアントでは socket.io-client がちゃんと動作
していますでしょうか？ (1000接続をどうシミュレートしたのか気になります。）

socket.io の heartbeat はサーバから送信する時に毎回 setTimeout() でタイ
マーを登録するので heartbeat が返ってこないとタイムアウト時間(default 60
秒)までタイマーが登録されたままです。デバッグ出力に

debug - got heartbeat packet
debug - cleared heartbeat timeout for client XXXXXX

とか出力されていますか？

[koexuka]

大津さん

koexukaです。

度々の返信ありがとうございます。

ちなみにベンチマークするクライアントでは socket.io-client がちゃんと動作 
していますでしょうか？ (1000接続をどうシミュレートしたのか気になります。） 

肝心な部分が伝え漏れていました。申し訳ございません。

クライアントは２パターンでテストしています。

１）ブラウザ（Mac版Firefox/Safari、socket.io-client）

　→複数タブ、ウィンドウで複数接続します。

２）Objective-Cによる実装

　→@growthfieldさんのNNSocketIO（https://github.com/growthfield/NNSocketIO）を使っています。

サーバ側で出力されるデバッグログですが、ブラウザでもObjective-Cでも

[2012-05-30 18:25:53.065] [INFO] console - debug: 'emitting heartbeat for client' '644389363226675471'                                                                

[2012-05-30 18:25:53.066] [INFO] console - debug: 'websocket writing' '2::'

[2012-05-30 18:25:53.067] [INFO] console - debug: 'set heartbeat timeout for client' '644389363226675471'

[2012-05-30 18:25:53.068] [INFO] console - debug: 'got heartbeat packet'

[2012-05-30 18:25:53.069] [INFO] console - debug: 'cleared heartbeat timeout for client' '644389363226675471'

[2012-05-30 18:25:53.069] [INFO] console - debug: 'set heartbeat interval for client' '644389363226675471' 

のように出ており、クライアント側は特に問題がないかなと思っています。

ちなみに、ブラウザからsocket.io-clientを使って1接続のみで試してみた場合ですが、

やはり少しずつ（10KB〜30KB）、heartbeat interval秒ごとにNodeが使用するメモリが上昇していきます。

ですが、ベンチマークのとり方、プログラムソースの間違いやクライアント側に問題がないかどうか、

再度確かめてみます。

よろしくお願い致します。

2012年5月30日水曜日 16時32分44秒 UTC+9 shigeki:

[Koichi Kobayashi]

小林 (koichik) です．

V8 の GC の傾向として，ヒープが枯渇する直前まで
フル GC を先延ばしにしている様子が見受けられます．

Node 側ではイベントループがアイドルになったときに GC を
キックしていたはずですが，それではあまりゴミは回収されない
ようで，ヒープが足りなくなると一気に利用可能な領域が
元に戻る感じです．
その時はストップ・ザ・ワールドになるので，V8 の GC は
(少なくとも現時点では) サーバ向けではないんだろうな，
という印象を持っています．

なので，本当にメモリリークが発生していていずれはヒープが
枯渇するのか，それともフル GC が先延ばしにされているだけ
なのかを見極める必要があるのではないかと思います．

> やはり少しずつ（10KB?30KB）、heartbeat interval秒ごとにNodeが使用するメモリが上昇していきます。

>
>
> ですが、ベンチマークのとり方、プログラムソースの間違いやクライアント側に問題がないかどうか、
> 再度確かめてみます。
>
>
> よろしくお願い致します。
>
> 2012年5月30日水曜日 16時32分44秒 UTC+9 shigeki:
> >
> > 大津です。
> >

> > > ベンチマークではサーバに対し多数（0?1000）接続 し、disconnectやconnect

> > > を繰り返し
> > > Nodeのメモリ使用量を監視していますが、
> > > 定期的に使用量がグッと下がる（恐らくGC）ことはありますが、長いスパンで見
> > > ると全体として増え続けています。
> > > ※どこかのタイミングで接続数を0（ゼロ）にしてしばらく経過すると、メモリ使
> > > 用量はNode起動時の状態に戻りますが、実運用ではあり得ない状態だと思います。
> > >
> > > この状態であれば、例えばメモリを2GB積んだサーバの場合、

> > > ２?３日でメモリが枯渇してしまうのではないかと危惧しています。

> >
> > ちょっと使用量が大きいですね。
> >
> > ちなみにベンチマークするクライアントでは socket.io-client がちゃんと動作
> > していますでしょうか？ (1000接続をどうシミュレートしたのか気になります。）
> >
> > socket.io の heartbeat はサーバから送信する時に毎回 setTimeout() でタイ
> > マーを登録するので heartbeat が返ってこないとタイムアウト時間(default 60
> > 秒)までタイマーが登録されたままです。デバッグ出力に
> >
> > debug - got heartbeat packet
> > debug - cleared heartbeat timeout for client XXXXXX
> >
> > とか出力されていますか？
> >

--
{
name: "Koichi Kobayashi",
mail: "koi...@improvement.jp",
blog: "http://d.hatena.ne.jp/koichik/",
twitter: "@koichik"
}

[Shigeki Ohtsu]

大津です。

> なので，本当にメモリリークが発生していていずれはヒープが
> 枯渇するのか，それともフル GC が先延ばしにされているだけ
> なのかを見極める必要があるのではないかと思います．

そうですよねぇ。

ちょっと調べたら socket.io の heartbeat を捕まえることができたので、１つ
の端末でクライアントから返ってきたタイミングの memoryUsage の変化を５分
程度見てみました。コードはこれです。

https://gist.github.com/2836908

heartbeat interval を極端に短く 0.1 秒にして node-v0.6.18 と 0.7.10-pre
(master) での比較です。GC のタイミングだけ見たいので値が減った時のみ出力
しています。頭はカウンターなのでだいたい0.1秒刻みのカウンターです。
(socket.io 0.9.6 は master でも動くんですね。驚きでした。)

これみると極端なメモリーリークはなさそうですが、heap確保に伴ってメモリ利
用量は増えていますね。でも確保ができなくなった限界時の挙動で差が出るかも
しれないのでなんとも言えないです。V8 3.6 では 1G 限界でしたっけ？ 確か今
はリミット外されているようなことを聞いた覚えがあります。

一度これでエージングしてみたらいかがでしょうか？

> node -e 'console.log(process.versions)'
> { node: '0.6.18',
> v8: '3.6.6.25',
> ares: '1.7.5-DEV',
> uv: '0.6',
> openssl: '1.0.1' }
> unixjp:~/tmp/socketio> node test.js
> info - socket.io started
> client connected
> 93 { rss: 11591680, heapTotal: 5027296, heapUsed: 3502640 } 'delta:' { rss: 4096, heapTotal: 524288, heapUsed: -434016 }
> 194 { rss: 12124160, heapTotal: 5170176, heapUsed: 3547104 } 'delta:' { rss: 4096, heapTotal: 142880, heapUsed: -416068 }
> 311 { rss: 12214272, heapTotal: 5170176, heapUsed: 3571988 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -481880 }
> 429 { rss: 12230656, heapTotal: 5170176, heapUsed: 3598660 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -483576 }
> 547 { rss: 12242944, heapTotal: 5170176, heapUsed: 3625764 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -483580 }
> 664 { rss: 12259328, heapTotal: 5170176, heapUsed: 3654864 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -483748 }
> 782 { rss: 12271616, heapTotal: 5300736, heapUsed: 3681024 } 'delta:' { rss: 0, heapTotal: 130560, heapUsed: -484112 }
> 900 { rss: 12353536, heapTotal: 5300736, heapUsed: 3707880 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -483788 }
> 1018 { rss: 12365824, heapTotal: 5300736, heapUsed: 3734372 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -484048 }
> 1136 { rss: 12378112, heapTotal: 5300736, heapUsed: 3760760 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -484036 }
> 1251 { rss: 12398592, heapTotal: 5300736, heapUsed: 3797192 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -481168 }
> 1369 { rss: 12414976, heapTotal: 6471712, heapUsed: 3826752 } 'delta:' { rss: 0, heapTotal: 1170976, heapUsed: -481056 }
> 1610 { rss: 13021184, heapTotal: 6471712, heapUsed: 3877292 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -990048 }
> 1847 { rss: 13565952, heapTotal: 6471712, heapUsed: 3930112 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -971504 }
> 2084 { rss: 13590528, heapTotal: 6594112, heapUsed: 3980724 } 'delta:' { rss: 0, heapTotal: 122400, heapUsed: -972468 }
> 2322 { rss: 13680640, heapTotal: 6594112, heapUsed: 4035644 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -972676 }
> 2559 { rss: 13705216, heapTotal: 6594112, heapUsed: 4088056 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -972204 }
> 2796 { rss: 13799424, heapTotal: 6724672, heapUsed: 4138332 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -972556 }
> 3033 { rss: 13824000, heapTotal: 6847072, heapUsed: 4190640 } 'delta:' { rss: 0, heapTotal: 122400, heapUsed: -972548 }

> ~/tmp/github/node/node -e 'console.log(process.versions)'
> { http_parser: '1.0',
> node: '0.7.10-pre',
> v8: '3.11.1',
> ares: '1.7.5-DEV',
> uv: '0.6',
> zlib: '1.2.3',
> openssl: '1.0.0f' }
> unixjp:~/tmp/socketio> ~/tmp/github/node/node test.js
> info - socket.io started
> client connected
> 165 { rss: 12722176, heapTotal: 8232576, heapUsed: 4473320 } 'delta:' { rss: 12288, heapTotal: 1048576, heapUsed: -870816 }
> 333 { rss: 14213120, heapTotal: 10263936, heapUsed: 4812396 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: -794844 }
> 511 { rss: 14606336, heapTotal: 10263936, heapUsed: 5091004 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -855820 }
> 693 { rss: 14774272, heapTotal: 10263936, heapUsed: 5267516 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -853648 }
> 875 { rss: 14598144, heapTotal: 10263936, heapUsed: 4374072 } 'delta:' { rss: -348160, heapTotal: 0, heapUsed: -1928132 }
> 1071 { rss: 14602240, heapTotal: 10263936, heapUsed: 4629124 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -901220 }
> 1250 { rss: 14606336, heapTotal: 10263936, heapUsed: 4806356 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -838748 }
> 1432 { rss: 14606336, heapTotal: 10263936, heapUsed: 4976116 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -850560 }
> 1613 { rss: 14651392, heapTotal: 12361088, heapUsed: 5148352 } 'delta:' { rss: 36864, heapTotal: 2097152, heapUsed: -852704 }
> 1994 { rss: 15818752, heapTotal: 12361088, heapUsed: 5512352 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -1784196 }
> 2362 { rss: 17039360, heapTotal: 12361088, heapUsed: 5875796 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -1703584 }
> 2624 { rss: 17338368, heapTotal: 12361088, heapUsed: 7339076 } 'delta:' { rss: -4096, heapTotal: 0, heapUsed: 14996 }
> 2733 { rss: 17395712, heapTotal: 12361088, heapUsed: 6235204 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: -1707464 }
> 3104 { rss: 17776640, heapTotal: 13376768, heapUsed: 6611072 } 'delta:' { rss: 0, heapTotal: 1015680, heapUsed: -1707284 }

[Shigeki Ohtsu]

大津です。

>> なので，本当にメモリリークが発生していていずれはヒープが
>> 枯渇するのか，それともフル GC が先延ばしにされているだけ
>> なのかを見極める必要があるのではないかと思います．

そういえば、node で手動GCできる方法があったなぁと思いだしたので、チョッ
ト試してみました。0.1秒毎に heartbeat を出し、クライアントから受け取った
らすかさずGCする例です。

https://gist.github.com/2840165

600heartbeat毎にメモリ状況を出力した結果です。超マメGCは見事に heap使用
量がそろってますね。他方 Node にお任せGCはバラバラ。

BenもMLで今の Node の 「idle だったら GC 呼び出す」のはいくつかのケース
でうまくいかないので今後アルゴリズムを変えると書いていましたので、今回の
ケースもそれに当てはまるケースじゃないですかね。

heartbeat受け取る毎に手動GC (node-v0.6.18)
> unixjp:~/tmp/socketio> node --nouse_idle_notification --expose_gc test.js

> info - socket.io started
> client connected

> 0 { rss: 21876736, heapTotal: 16209952, heapUsed: 4284792 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: 0 }
> 600 { rss: 21417984, heapTotal: 15616032, heapUsed: 3648380 } 'delta:' { rss: -458752, heapTotal: -593920, heapUsed: -636412 }
> 1200 { rss: 21422080, heapTotal: 24004640, heapUsed: 3644136 } 'delta:' { rss: 4096, heapTotal: 8388608, heapUsed: -4244 }
> 1800 { rss: 21430272, heapTotal: 24004640, heapUsed: 3644208 } 'delta:' { rss: 8192, heapTotal: 0, heapUsed: 72 }
> 2400 { rss: 21434368, heapTotal: 24004640, heapUsed: 3644256 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: 48 }
> 3000 { rss: 21438464, heapTotal: 24004640, heapUsed: 3644292 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: 36 }
> 3600 { rss: 21446656, heapTotal: 24004640, heapUsed: 3644332 } 'delta:' { rss: 8192, heapTotal: 0, heapUsed: 40 }
> 4200 { rss: 21450752, heapTotal: 24004640, heapUsed: 3644364 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: 32 }
> 4800 { rss: 21454848, heapTotal: 24004640, heapUsed: 3644704 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: 340 }
> 5400 { rss: 21463040, heapTotal: 24004640, heapUsed: 3644760 } 'delta:' { rss: 8192, heapTotal: 0, heapUsed: 56 }
> 6000 { rss: 21467136, heapTotal: 24004640, heapUsed: 3644792 } 'delta:' { rss: 4096, heapTotal: 0, heapUsed: 32 }

Nodeによるお任せGC (node-v0.6.18)

> unixjp:~/tmp/socketio> node test.js
> info - socket.io started
> client connected

> 0 { rss: 23203840, heapTotal: 17729184, heapUsed: 9885436 } 'delta:' { rss: 0, heapTotal: 0, heapUsed: 0 }
> 600 { rss: 25260032, heapTotal: 17729184, heapUsed: 12557360 } 'delta:' { rss: 2056192, heapTotal: 0, heapUsed: 2671924 }
> 1200 { rss: 25821184, heapTotal: 18300640, heapUsed: 11676544 } 'delta:' { rss: 561152, heapTotal: 571456, heapUsed: -880816 }
> 1800 { rss: 24408064, heapTotal: 16797408, heapUsed: 5267092 } 'delta:' { rss: -1413120, heapTotal: -1503232, heapUsed: -6409452 }
> 2400 { rss: 24428544, heapTotal: 16797408, heapUsed: 7849444 } 'delta:' { rss: 20480, heapTotal: 0, heapUsed: 2582352 }
> 3000 { rss: 12955648, heapTotal: 5329568, heapUsed: 3973844 } 'delta:' { rss: -11472896, heapTotal: -11467840, heapUsed: -3875600 }
> 3600 { rss: 13090816, heapTotal: 5460128, heapUsed: 4127740 } 'delta:' { rss: 135168, heapTotal: 130560, heapUsed: 153896 }
> 4200 { rss: 13225984, heapTotal: 5590688, heapUsed: 4258476 } 'delta:' { rss: 135168, heapTotal: 130560, heapUsed: 130736 }
> 4800 { rss: 12963840, heapTotal: 5321408, heapUsed: 3672084 } 'delta:' { rss: -262144, heapTotal: -269280, heapUsed: -586392 }
> 5400 { rss: 13103104, heapTotal: 5451968, heapUsed: 3826204 } 'delta:' { rss: 139264, heapTotal: 130560, heapUsed: 154120 }
> 6000 { rss: 13238272, heapTotal: 6622944, heapUsed: 3955288 } 'delta:' { rss: 135168, heapTotal: 1170976, heapUsed: 129084 }

[koexuka]

大津さん、小林（koichik）さん

koexukaです。

情報ありがとうございます！

＞小林さん

NodeのGCの説明、大変参考になります。

なので，本当にメモリリークが発生していていずれはヒープが 
枯渇するのか，それともフル GC が先延ばしにされているだけ 
なのかを見極める必要があるのではないかと思います．

なるほどですね。

フルGCが先延ばしにされているかも、という考えはありませんでした。

僕が行ったベンチマークからだけですとその事が原因である可能性もかなり高いと思います。

また、ストップ・ザ・ワールドしてでもいずれ一気にメモリ解放される日が来るのであれば

個人的には全然嬉しい情報です。

この件では時間的に難しいですが、いずれ大量接続（とdisconnect）を繰り返しながら

ヒープが限界に達する２〜３日間ベンチマークを取り続ける試みもやってみたいです。

 

＞大津さん

サンプルソースまで作成頂きありがとうございます。

ちょっと今バタバタしており、すぐ確認はできませんがあとで僕の環境でも試してみたいと思います！

頂いた結果を見て、また言われている通り極端なメモリリークは見られませんね。

僕の環境でもジワジワ〜・・・と増えたり減ったりを繰り返しながら、でも少しずつ増える、

という状態だったのですが、もう少しいろんなパターンでベンチを試してみたいと思います。

そういえば、node で手動GCできる方法があったなぁと思いだしたので、チョッ 
ト試してみました。

Oh!!

MLに質問してよかったと、心から感じました！

この情報、とてもありがたいです。

600heartbeat毎にメモリ状況を出力した結果です。超マメGCは見事に heap使用 
量がそろってますね。他方 Node にお任せGCはバラバラ。 

本当ですね。

これが該当してる線が濃厚になってまいりました。

僕のベンチマーク処理にも超マメGC組み込んで試してみます。

まだ実際の動作は確認出来ておりませんが、取り急ぎ先に返事をさせて頂きます！

よろしくお願い致します。

2012年5月31日木曜日 10時42分00秒 UTC+9 shigeki: