2010年11月 4日

[pgsql-jp: 40493] Re: 仮想メモリが解放されない

(2010/11/03 8:26), Hiroshi Inoue wrote:
> 井上です。
>
> (2010/11/01 11:41), 錦戸 暖 wrote:
>> (2010/10/29 14:32), 錦戸 暖 wrote:
>>> (2010/10/29 14:09), Itagaki Takahiro wrote:
>>>> つまり、アプリ側でのメモリリークをデバッグする話になる ので、 がん
>>>> ばってくださいとしか言えません。ADO の使い方であれば、 この MLでも誰

>>>> かが答えてくれるかもしれませんが…。 また、一般的な話ですが、仮 想メモ
>>>> リのリークって、本当に メモリリークなんでしたっけ? free() した 仮想
>>>> アドレスが 返却するか否かは、Cランタイムの作りに依存していたはずで
>>>> す。 該当の処理を繰り返してみて、本当に修正が必要なリークなのか 確認
>>>> す るのが先決なのでは。
>>> ご返信ありがとうございます。
>>> 調査致します。
>>>
>>>
>> 調査した結果、以下のような単純なプログラムを実行した場合も
>> 確保した仮想メモリが減少しないことがわかりました。
>> ------------------------------------------------------------------
>> // COMの初期化
>> CoInitalizeEx(NULL, COINIT_MULTITHREADED)
>>
>> // コネクションの取得
>> _ConnectionPtr c;
>> c.CreateInstance(_T("ADODB.Connection"));
>> c.->Open(/*接続文字列*/,/*ユーザID*/,/*パスワード*
>> /,adConnectUnspecified);
>>
>> // レコードセットポインタの取得
>> _RecordsetPtr r;
>> r.CreateInstance(_T("ADODB.Recordset"));
>> r->CursorLocation = adUseClient;
>>
>> // SQL実行
>> r->Open(/*SQL文(SELECT)*/, _variant_t(IDispatch)c, true);
>>
>> // レコードセットのクローズ
>> r->Close();
>> r->Release();
>> r=NULL;
>>
>> // コネクションのクローズ
>> c->Close();
>> c->Release();
>> c = NULL;
>>
>> // COMの終了処理
>> ::CoUninitalize();
>> ------------------------------------------------------------------
>>
>> SELECT文により取得したデータのために確保された仮想メモリ使用量が
>> レコードセット、コネクションのクローズ後も確保されたままとなるのですが、
>> この現象は当然のことなのでしょうか?
>> 上記処理繰り返すと仮想メモリ使用量が徐々に増加してしまい、仮想メモリ
>> オーバーが発生します。
>
> こちらで簡単なケースを試してみましたが再現しません。何度位繰り返すと
> 発生するのでしょうか?
以下のようなデータをSELECTした場合ならば、1度SQLを発行し終えた時点で
発行前の仮想メモリ使用量までは減少しません。
レコード数:231427レコード
1レコードのバイト数:327バイト
>
> 又、古いドライバをお使いになられているなら最新のドライバ(9.0.0200)
> を一度お試しください。もしかしたら改善されているかもしれません。
古いドライバを使用していましたので最新のドライバ(9.0.02.00)にて確認しま
した。
改善はされていない模様です。

以上、よろしくお願いします。


投稿者 xml-rpc : 2010年11月 4日 09:28
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/99702
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。