Kouhei Sutou
kou****@clear*****
2016年 10月 19日 (水) 10:27:06 JST
須藤です。 In <43987****@web10*****> "[groonga-dev,04156] Re: PGroongaの大量件数該当時のscore関数のエラーについて" on Wed, 19 Oct 2016 09:58:09 +0900 (JST), tak_kaz24****@yahoo***** wrote: >>また、`SELECT pgroonga.command('dump --dump_records no')`の >>結果を見せてもらえませんか？ > > 結果は以下となりました。idがテーブル定義のCOLUMN1に相当する想定です。 ありがとうございます。 実はテーブル・カラムが大量にある、ということかも？と思ったの ですがそういうことではないことがわかりました。 > VMMapツールについても連携ありがとうございます。 > ファイル転送が制限されている環境なので詳細の共有は難しいですが、 > 計測したところHeapとPage Tableが以下のようにかなり増大します。 > > ■Heap:Size > SQL初回実行時： 3,250,216K > SQL複数回実行時：12,300,520K > 事象発生時： 15,792,888K > > ■Page Table:Size > SQL初回実行時： 10,692K > SQL複数回実行時：37,708K > 事象発生時： 48,600K ありがとうございます。 Heapの値が異常なことがわかりました。 メモリーリークしている気がします。 メモリーリークしている場合はこちらの環境でも再現できないと調 査が難しいので、再現する手順を確立して共有してもらえないでしょ うか？ 参考までに、再現手順に必要なものは以下の通りです。 （もしかしたら漏れがあるかもしれません。まっさらな環境から問 題が再現できる状態になるための手順、が必要なので、それ基準で まとめてもらってもよいです。） CREATE TABLE ...; CREATE INDEX ...; INSERT INTO ...; SELECT ...; -- ←を実行するごとにHeapが増えていくんだと思います。 -- もしかしたら複数パターンのSELECTが必要なのかもしれません。 再現しているかどうかはVMMapでHeapの値を確認すればわかると思 います。SELECTしているだけなのに値が増えていくなら再現してい ます。 実データは提供できないということなので、手間だとは思うのです が、提供できるテストデータで再現させてそれを提供してもらえま せんか？ -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート： http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス： http://www.clear-code.com/recruitment/ OSS開発支援サービス: http://www.clear-code.com/blog/2016/6/27.html
