From koyama ＠ ecmix.net Tue Sep 4 13:11:52 2007 From: koyama ＠ ecmix.net (ecmix =?ISO-2022-JP?B?GyRCPi47MxsoQg==?=) Date: Tue, 04 Sep 2007 13:11:52 +0900 Subject: [Ludia-users 81] =?iso-2022-jp?b?GyRCIVZNeE1RO3ZOYyFXJFgkTjdHOlwbKEI=?= Message-ID: <20070904130729.E83E.KOYAMA@ecmix.net> Ludia-usersメーリングリストさま 有限会社インシエメの小山と申します。 LudiaプロジェクトWebページの「利用事例」に掲載して頂きたく メールさしあげました。 弊社で開発中の社内ツール「Biz-Com」にLudiaを採用させて頂いております。 以下URLの「Biz-Comサンプル版」のログイン後のページ、右上の検索部分で利用させていただいてます。 http://www.insieme.jp/groupware3 何かご不明な点がございましたら、私、小山(koyama ＠ ecmix.net)宛に ご連絡ください。 どうぞよろしくお願いいたします。 ┌──────────────────────────── │有限会社インシエメ │小山　昌徳（コヤマ　アキノリ）　　　koyama ＠ ecmix.net │………………………………………………………………………… │〒170-0013　東京都豊島区東池袋3-7-8 │セントヒルズ池袋1202 │(TEL)03-6907-7825 │(FAX)03-6907-7826 │(URL)http://www.insieme.jp/ └──────────────────────────── From iwasakims ＠ nttdata.co.jp Tue Sep 4 14:42:57 2007 From: iwasakims ＠ nttdata.co.jp (iwasakims ＠ nttdata.co.jp) Date: Tue, 4 Sep 2007 14:42:57 +0900 Subject: [Ludia-users 82] Re: =?iso-2022-jp?b?GyRCIVZNeE1RO3ZOYyFXJFgkTjdHOlwbKEI=?= References: <20070904130729.E83E.KOYAMA@ecmix.net> Message-ID: 小山様 岩崎です。 > LudiaプロジェクトWebページの「利用事例」に掲載して頂きたく > > メールさしあげました。 ありがとうございます！ さっそく掲載させていただきました。 http://ludia.sourceforge.jp/cgi-bin/moin.cgi/LudiaFrontPage#id18 記載した内容に問題などがありましたらご指摘ください。 よろしくおねがいします。 -- 岩崎 正剛 / IWASAKI Masatake mailto:iwasakims ＠ nttdata.co.jp From umi.tanuki ＠ gmail.com Wed Sep 12 10:29:27 2007 From: umi.tanuki ＠ gmail.com (H.Harada) Date: Wed, 12 Sep 2007 10:29:27 +0900 Subject: [Ludia-users 83] =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JTMlOSVIP2REajRYP3QkSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= Message-ID: Ludia使わせてもらっています。 このほどPostgreSQLを8.1→8.2にバージョンアップしたので Ludiaも0.8→1.2にバージョンアップしたのですが、 一部のクエリが異様に遅くなりました。 原因をつきとめたところ、 Ludiaが負の値のインデックスコストを算出してくれた模様。 これが比較的深いNestLoopでつかわれていたため、 外側のクエリで（負の値　×　外のコスト）というモラルハザードな計算をもたらし、 結果としてPostgreSQLがもっとも「早い」と勘違いした、もっとも遅いプランが選択されていたのでした。 ソース的にはludia-1.2.0/pgsenna.cの929行目あたり、 #if defined(POSTGRES82) || defined(POSTGRES83) *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; #endif の部分ですが、なぜDEFAULT_RANDOME_PAGE_COSTを「引く」必要があるのでしょうか。 取り急ぎ該当作業ではindexTotalCostに定数0.3を返すように書き換えたところ、 期待通りに動くようにはなったのですが（下記参照）。。。 ちなみに環境は、 Windows XP SP2 PostgreSQ-L8.2.4 Ludia-1.2.0 Senna-1.0.8 Senna built on VC++2005 Mingw gcc 3.4.2 *** pgsenna2.c.org Wed Aug 08 23:28:41 2007 --- pgsenna2.c Wed Sep 12 10:25:38 2007 *************** *** 929,934 **** --- 929,936 ---- *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; #endif *indexCorrelation = 1.0; + + *indexTotalCost = 0.3; elog(DEBUG1, "pgsenna2: cost=(%f,%f,%f)", *indexStartupCost, *indexTotalCost, *indexSelectivity); PG_RETURN_VOID(); Hitoshi Harada umi.tanuki ＠ gmail.com From kousakadi ＠ nttdata.co.jp Wed Sep 12 14:28:29 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Wed, 12 Sep 2007 14:28:29 +0900 Subject: [Ludia-users 84] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JTMlOSVIP2REajRYP3QbKEI=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71BF6@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 現在のLudiaはインデックススキャンとシーケンシャルスキャンの 二種類を実装しています。 しかし、シーケンシャルスキャンはインデックススキャンと比較して、 まだ機能が不十分です。 そのため、プランナに「強引に」インデックススキャンを選択させるために、 > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; のような記述をしています。 この記述がないと、シーケンシャルスキャンが使われる事象が増えます。 困ります。 ほとんどのクエリでは、上記の記述により強引にインデックススキャンを 選択させるべきですが、Haradaさんのような事象では、 > + *indexTotalCost = 0.3; のような記述もありだと思います。 しかし、このような記述をした場合は、EXPLAINでシーケンシャルスキャンが 使われているかチェックしてください。 シーケンシャルスキャンの機能はLudia1.0と1.2で追加してきました。 あと少しでインデックススキャンと変わらない機能となる予定です。 その際に、コストを正確な物にする予定です。 参考までに、どのようなクエリを発行したのか教えて頂けないでしょうか？ > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of H.Harada > Sent: Wednesday, September 12, 2007 10:29 AM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 83]インデックスコスト推定関数について > > Ludia使わせてもらっています。 > > このほどPostgreSQLを8.1→8.2にバージョンアップしたので > Ludiaも0.8→1.2にバージョンアップしたのですが、 > 一部のクエリが異様に遅くなりました。 > > 原因をつきとめたところ、 > Ludiaが負の値のインデックスコストを算出してくれた模様。 > これが比較的深いNestLoopでつかわれていたため、 > 外側のクエリで（負の値　×　外のコスト）というモラルハザードな計算をもたら し、 > 結果としてPostgreSQLがもっとも「早い」と勘違いした、もっとも遅いプランが選 択されていたのでした。 > > ソース的にはludia-1.2.0/pgsenna.cの929行目あたり、 > #if defined(POSTGRES82) || defined(POSTGRES83) > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > #endif > の部分ですが、なぜDEFAULT_RANDOME_PAGE_COSTを「引く」必要があるのでしょう か。 > > > 取り急ぎ該当作業ではindexTotalCostに定数0.3を返すように書き換えたところ、 > 期待通りに動くようにはなったのですが（下記参照）。。。 > > ちなみに環境は、 > Windows XP SP2 > PostgreSQ-L8.2.4 > Ludia-1.2.0 > Senna-1.0.8 > Senna built on VC++2005 > Mingw gcc 3.4.2 > > > *** pgsenna2.c.org Wed Aug 08 23:28:41 2007 > --- pgsenna2.c Wed Sep 12 10:25:38 2007 > *************** > *** 929,934 **** > --- 929,936 ---- > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > #endif > *indexCorrelation = 1.0; > + > + *indexTotalCost = 0.3; > elog(DEBUG1, "pgsenna2: cost=(%f,%f,%f)", > *indexStartupCost, *indexTotalCost, *indexSelectivity); > PG_RETURN_VOID(); > > > Hitoshi Harada > umi.tanuki ＠ gmail.com > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From umi.tanuki ＠ gmail.com Wed Sep 12 16:29:59 2007 From: umi.tanuki ＠ gmail.com (H.Harada) Date: Wed, 12 Sep 2007 16:29:59 +0900 Subject: [Ludia-users 85] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JTMlOSVIP2REajRYP3QbKEI=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71BF6@MAILSV11.msg.nttdata.co.jp> References: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71BF6@MAILSV11.msg.nttdata.co.jp> Message-ID: こんにちは。 > そのため、プランナに「強引に」インデックススキャンを選択させるために、 > > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > のような記述をしています。 個人的な思い込みで申し訳ないのですが、 RANDOM_PAGE_COSTは引き算というより掛け算するものかと思っていたので。 SQL（擬似）は以下のような感じです。 それぞれ15万件ほどのレコードが存在します。 EXPLAIN SELECT COUNT(*), COUNT(m_productCode) FROM _search_product INNER JOIN( SELECT productIndex FROM _search_text WHERE productText @@ 'ポケット' )keyword USING(productIndex) CROSS JOIN( SELECT null::int4 AS m_productCode )m_product で、プラン（最悪）は： "Aggregate (cost=-309589.39..-309589.37 rows=1 width=222)" " -> Nested Loop (cost=-309596.08..-309593.26 rows=140 width=222)" " -> Result (cost=0.00..0.01 rows=1 width=0)" " -> Materialize (cost=-309596.08..-309594.68 rows=140 width=218)" " -> Nested Loop (cost=0.00..-309596.22 rows=140 width=218)" " Join Filter: (_search_product.productindex = _search_text.productindex)" " -> Seq Scan on _search_product (cost=0.00..4501.79 rows=140379 width=218)" " -> Index Scan using ludia_index on _search_text (cost=0.00..-3.99 rows=140 width=4)" " Index Cond: ((producttext)::text @@ 'ポケット'::text)" パッチ適用後： "Aggregate (cost=1074.98..1075.00 rows=1 width=222)" " -> Nested Loop (cost=0.00..1071.10 rows=140 width=222)" " -> Result (cost=0.00..0.01 rows=1 width=0)" " -> Nested Loop (cost=0.00..1069.68 rows=140 width=218)" " -> Index Scan using ludia_index on _search_text (cost=0.00..4.31 rows=140 width=4)" " Index Cond: ((producttext)::text @@ 'ポケット'::text)" " -> Index Scan using _search_product_pkey on _search_product (cost=0.00..7.60 rows=1 width=218)" " Index Cond: (_search_product.productindex = _search_text.productindex)" 最悪時はLudiaIndexのスキャン結果のシークスキャンがN回となっているのに対し、 適用後はLudiaIndex一回のスキャンでJOINにはPrimaryKeyのスキャンが使われています。 > しかし、このような記述をした場合は、EXPLAINでシーケンシャルスキャンが > 使われているかチェックしてください。 上記のようなプランですが、Ludiaのシークスキャンが使われているのでしょうか？？ Hitoshi Harada umi.tanuki ＠ gmail.com 07/09/12 に kousakadi ＠ nttdata.co.jp さんは書きました: > 幸坂です。こんにちは。 > > 現在のLudiaはインデックススキャンとシーケンシャルスキャンの > 二種類を実装しています。 > しかし、シーケンシャルスキャンはインデックススキャンと比較して、 > まだ機能が不十分です。 > そのため、プランナに「強引に」インデックススキャンを選択させるために、 > > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > のような記述をしています。 > この記述がないと、シーケンシャルスキャンが使われる事象が増えます。 > 困ります。 > > ほとんどのクエリでは、上記の記述により強引にインデックススキャンを > 選択させるべきですが、Haradaさんのような事象では、 > > + *indexTotalCost = 0.3; > のような記述もありだと思います。 > しかし、このような記述をした場合は、EXPLAINでシーケンシャルスキャンが > 使われているかチェックしてください。 > > シーケンシャルスキャンの機能はLudia1.0と1.2で追加してきました。 > あと少しでインデックススキャンと変わらない機能となる予定です。 > その際に、コストを正確な物にする予定です。 > > 参考までに、どのようなクエリを発行したのか教えて頂けないでしょうか？ > > > -----Original Message----- > > From: ludia-users-bounces ＠ lists.sourceforge.jp > > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > > Of H.Harada > > Sent: Wednesday, September 12, 2007 10:29 AM > > To: ludia-users ＠ lists.sourceforge.jp > > Subject: [Ludia-users 83]インデックスコスト推定関数について > > > > Ludia使わせてもらっています。 > > > > このほどPostgreSQLを8.1→8.2にバージョンアップしたので > > Ludiaも0.8→1.2にバージョンアップしたのですが、 > > 一部のクエリが異様に遅くなりました。 > > > > 原因をつきとめたところ、 > > Ludiaが負の値のインデックスコストを算出してくれた模様。 > > これが比較的深いNestLoopでつかわれていたため、 > > 外側のクエリで（負の値　×　外のコスト）というモラルハザードな計算をもたら > し、 > > 結果としてPostgreSQLがもっとも「早い」と勘違いした、もっとも遅いプランが選 > 択されていたのでした。 > > > > ソース的にはludia-1.2.0/pgsenna.cの929行目あたり、 > > #if defined(POSTGRES82) || defined(POSTGRES83) > > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > > #endif > > の部分ですが、なぜDEFAULT_RANDOME_PAGE_COSTを「引く」必要があるのでしょう > か。 > > > > > > 取り急ぎ該当作業ではindexTotalCostに定数0.3を返すように書き換えたところ、 > > 期待通りに動くようにはなったのですが（下記参照）。。。 > > > > ちなみに環境は、 > > Windows XP SP2 > > PostgreSQ-L8.2.4 > > Ludia-1.2.0 > > Senna-1.0.8 > > Senna built on VC++2005 > > Mingw gcc 3.4.2 > > > > > > *** pgsenna2.c.org Wed Aug 08 23:28:41 2007 > > --- pgsenna2.c Wed Sep 12 10:25:38 2007 > > *************** > > *** 929,934 **** > > --- 929,936 ---- > > *indexTotalCost += -DEFAULT_RANDOM_PAGE_COST; > > #endif > > *indexCorrelation = 1.0; > > + > > + *indexTotalCost = 0.3; > > elog(DEBUG1, "pgsenna2: cost=(%f,%f,%f)", > > *indexStartupCost, *indexTotalCost, *indexSelectivity); > > PG_RETURN_VOID(); > > > > > > Hitoshi Harada > > umi.tanuki ＠ gmail.com > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > From yoneyama ＠ cont.yamaha.co.jp Thu Sep 13 18:13:13 2007 From: yoneyama ＠ cont.yamaha.co.jp (=?ISO-2022-JP?B?GyRCSkY7MxsoQiAbJEI1MTBsGyhC?=) Date: Thu, 13 Sep 2007 18:13:13 +0900 Subject: [Ludia-users 86] =?iso-2022-jp?b?ZHVtcCAvIHJlc3RvcmUgGyRCJE4xP01RJEskRCQkJEYbKEI=?= Message-ID: <46E8FF29.7070802@cont.yamaha.co.jp> ヤマハの米山と申します。 # 岩崎様、ご無沙汰しております いつも便利に Ludia を利用させていただいております。 MySound も導入事例に掲載いただきましてありがとうございます。 さて、半年以上利用させていただいていていまさらの質問なのですが、Ludia で は dump / restore はどのように運用するのが正解なのでしょうか？ 普通に pg_dump して、psql -f で restore しただけでは psql:/www/tmp/serch.dump:541887: ERROR: access method "fulltextu" does not exist というエラーが出てしまいます。 アーカイブ形式で dump して pg_restore してみても pg_restore: [archiver (db)] could not execute query: ERROR: access method "fulltextu" does not exist Command was: ALTER OPERATOR CLASS public.text_ops USING fulltextu OWNER TO yoneyama; となってしまいます。 無視して、もう一回 pgsenna2.sql して、REINDEX すればいいのかもしれません がどうもすっきりしません。 弊社ではバックアップをいまだに dump / restore で運用していることが多いの で、少し困っています。何かいい運用方法がありましたらご教示いただけますと 幸いです。 よろしくお願いします。 -- 米山 輝一 [Teruhito YONEYAMA] From iwasakims ＠ nttdata.co.jp Fri Sep 14 11:25:33 2007 From: iwasakims ＠ nttdata.co.jp (iwasakims ＠ nttdata.co.jp) Date: Fri, 14 Sep 2007 11:25:33 +0900 Subject: [Ludia-users 87] Re: =?iso-2022-jp?b?ZHVtcCAvIHJlc3RvcmUgGyRCJE4xP01RJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= References: <46E8FF29.7070802@cont.yamaha.co.jp> Message-ID: 米山様 岩崎です。こんにちは。 # ごぶさたしてます。 > 普通に pg_dump して、psql -f で restore しただけでは > > psql:/www/tmp/serch.dump:541887: ERROR: access method "fulltextu" does > not exist > > というエラーが出てしまいます。 pgsenna2.sqlを実行した際にシステムカタログ(pg_am)に追加されたデータは、 ダンプデータに含まれないことが原因です。 運用としてはリストア先のデータベースに先にpgsenna2.sqlを実行しておき、 それからリストアを行うというやり方がよいのではないかと思います。 ただし、その場合今度は、:: ERROR: operator class "text_ops" for access method "fulltextu" already exists のような感じの "already exists"というエラーメッセージがいくつか出てきてしまうと思います が、、 問題はないはずです。 -- 岩崎 正剛 / IWASAKI Masatake mailto:iwasakims ＠ nttdata.co.jp -----Original Message----- From: ludia-users-bounces ＠ lists.sourceforge.jp [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of 米山 輝一 Sent: Thursday, September 13, 2007 6:13 PM To: ludia-users ＠ lists.sourceforge.jp Subject: [Ludia-users 86]dump / restore の運用について ヤマハの米山と申します。 # 岩崎様、ご無沙汰しております いつも便利に Ludia を利用させていただいております。 MySound も導入事例に掲載いただきましてありがとうございます。 さて、半年以上利用させていただいていていまさらの質問なのですが、Ludia で は dump / restore はどのように運用するのが正解なのでしょうか？ 普通に pg_dump して、psql -f で restore しただけでは psql:/www/tmp/serch.dump:541887: ERROR: access method "fulltextu" does not exist というエラーが出てしまいます。 アーカイブ形式で dump して pg_restore してみても pg_restore: [archiver (db)] could not execute query: ERROR: access method "fulltextu" does not exist Command was: ALTER OPERATOR CLASS public.text_ops USING fulltextu OWNER TO yoneyama; となってしまいます。 無視して、もう一回 pgsenna2.sql して、REINDEX すればいいのかもしれません がどうもすっきりしません。 弊社ではバックアップをいまだに dump / restore で運用していることが多いの で、少し困っています。何かいい運用方法がありましたらご教示いただけますと 幸いです。 よろしくお願いします。 -- 米山 輝一 [Teruhito YONEYAMA] _______________________________________________ Ludia-users mailing list Ludia-users ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/ludia-users From yoneyama ＠ cont.yamaha.co.jp Fri Sep 14 12:38:33 2007 From: yoneyama ＠ cont.yamaha.co.jp (=?ISO-2022-JP?B?GyRCSkY7MxsoQiAbJEI1MTBsGyhC?=) Date: Fri, 14 Sep 2007 12:38:33 +0900 Subject: [Ludia-users 88] Re: =?iso-2022-jp?b?ZHVtcCAvIHJlc3RvcmUgGyRCJE4xP01RJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: References: <46E8FF29.7070802@cont.yamaha.co.jp> Message-ID: <46EA0239.2020309@cont.yamaha.co.jp> 岩崎 様 米山です。 お世話になります。 > 運用としてはリストア先のデータベースに先にpgsenna2.sqlを実行しておき、 > それからリストアを行うというやり方がよいのではないかと思います。 こちらを試してみたところ、確かに "already exists" はたくさん出てきました が、無事 INDEX も作られているようで、問題なく restore できました。 ありがとうございました。 今後ヤマハグループ内で Ludia をどんどん活用させていただきたいと思ってい ますので、今後ともよろしくお願いいたします。 Ludia の益々のご発展、お祈りしております。 -- 米山 輝一 [Teruhito YONEYAMA] From morita ＠ razil.jp Thu Sep 20 17:44:56 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Thu, 20 Sep 2007 17:44:56 +0900 Subject: [Ludia-users 89] Re: =?iso-2022-jp?b?Q3JlYXRlSW5kZXgbJEIkRyUoJWkhPBsoQg==?= In-Reply-To: References: <000a01c7d8cc$0fae07e0$3600a8c0@public.local> Message-ID: <20070920084456.GA2450@epepe.com> こんにちは。森です。 ずいぶん時間が空いてしまったのですが、 windows環境で論理空間の消費を抑えられるかも知れない方法を実装してみました。 といってもごく単純な考えなのですが、 SEN.i.c*ファイルの読み書きに関しては、MapViewOfFileを使用せず、 すべてReadFile, WriteFileで処理すます。 (SEN, SEN.i, SEN.lファイルについては従来どおりMapViewOfFileを使用します) インデックスが大きくなると、主にSEN.i.c*ファイルが成長しますので、 その読み書きにメモリを消費しなくなれば、論理空間の枯渇も抑えられるのではないかと。 Senna rev552ではこの挙動になっています。 (WIN32以外の環境での挙動は変わっていません) もしよろしければお試し下さい。 >>> iwasakims ＠ nttdata.co.jp さんは書きました： > 岩崎です。 > > > ちょっとWindwosで大きなデータベースを作ったので、 > 遅ればせながら2GB超のインデックスを試してみました。 > 予想に反して?インデックスが正常にできました。 > > 環境は:: > > OS:WindowsXP Professinal(32bit) > PostgreSQL:8.2.4 > Senna:1.0.8 > Ludia:1.2.0 > > で、作成したインデックスのサイズは:: > > 844292.SEN 71434240 > 844292.SEN.i 181338112 > 844292.SEN.i.c 1073676288 > 844292.SEN.i.c.001 1073741824 > 844292.SEN.i.c.002 767819776 > 844292.SEN.l 42074112 > > という感じです。 > 同じ単語が500万回くらい出現するようにしてみてます。 > > 問題は > > http://support.microsoft.com/kb/830783/ja > > のあたりだったりするのでしょうか？ > > > -- > 岩崎 正剛 / IWASAKI Masatake > mailto:iwasakims ＠ nttdata.co.jp > > > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of Shingo > Kawamura > Sent: Tuesday, August 07, 2007 5:22 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 73] Re:CreateIndexでエラー > > 河村です。 > > > Windows上でmmapに相当するAPIの調査を進めてきました。 > > その結果、 > > 論理空間を枯渇させないような実装の方向性が > > ある程度分かってきました。 > > やはり、あの実装では問題がありそうですか…。 > テストが足りないまま出してしまい申し訳ありませんでした。 > > > いまだ実験・実装等に着手できていないのですが、 > > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように > > 開発を続けております。 > > 期待しています！ > > 私の方でも、もう少し見てみたいと思っています。 > > ----- Original Message ----- > From: "Tasuku SUENAGA" > To: > Sent: Monday, August 06, 2007 9:20 PM > Subject: [Ludia-users 72] Re: CreateIndexでエラー > > > > 末永です。 > > > > Windows上でmmapに相当するAPIの調査を進めてきました。 > > その結果、 > > 論理空間を枯渇させないような実装の方向性が > > ある程度分かってきました。 > > > > いまだ実験・実装等に着手できていないのですが、 > > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように > > 開発を続けております。 > > > > Shingo Kawamura さんは書きました: > >> ご無沙汰しています。河村です。 > >> > >> 「1プロセス内で2GB」なのか、「1インデックスで2GB」なのか > >> を特定しようと思い、以下の調査を行いました。 > >> > >> CSV_ODD > >> と > >> CSV_EVEN > >> 二つのテーブルを用意して、各インデックスが1.5GB弱で、 > >> 合計が3GB以上になるようにデータ量を調節して、 > >> 1プロセス内で各テーブルへのInsertを交互に行ってみたのですが > >> 正常に動作完了しました。 > >> #/3GBスイッチははずしています > >> > >> 各テーブルのインデックスサイズは以下の通りです。 > >> ・CSV_ODD > >> サイズ：260,880 KB > >> --- > >> .SEN 12,416 KB > >> .SEN.i 84,160 KB > >> .SEN.i.c 524,096 KB > >> .SEN.i.c.001 523,264 KB > >> .SEN.i.c.002 492,544 KB > >> .SEN.i.c.003 145,408 KB > >> .SEN.l 8,320 KB > >> --- > >> ・CSV_EVEN > >> サイズ：260,880 KB > >> --- > >> .SEN 12,416 KB > >> .SEN.i 84,160 KB > >> .SEN.i.c 524,096 KB > >> .SEN.i.c.001 522,496 KB > >> .SEN.i.c.002 513,792 KB > >> .SEN.i.c.003 144,896 KB > >> .SEN.l 8,320 KB > >> --- > >> > >> このテストでもエラーが起きるかな、と思ったのですが、 > >> 正常終了してしまいました。^^; > >> > >> 最悪、このような方法で動作できそうなら、 > >> 件数でテーブルを振り分けて、全テーブルをUNIONして使う、 > >> という方法もありかなと思っています。 > >> > >> > >> ----- Original Message ----- > >> From: > >> To: > >> Sent: Thursday, July 12, 2007 2:11 PM > >> Subject: [Ludia-users 70] Re:CreateIndexでエラー > >> > >> > >>> 森です。お世話になっています。。 > >>> > >>>> パッチを当てて再度実行してみました。 > >>>> --- > >>>> 07/11:06:49:10.021|A| MapViewOfFile failed #8 <400293888> > >>>> 07/11:06:49:10.071|A| io_win_map(8183, 287121676) failed!! > >>> ありがとうございます。 > >>> > >>> ひょっとするとSennaロジックのレベルでちゃんとメモリを解放していないので > はないかと > >>> 考えたのですが、お蔭様でその疑いは晴れました。 > >>> > >>> どうやらUnmapViewOfFile, CloseHandleという手順を踏んでも > >>> 意図したように論理空間が解放できていないように見受けられます。 > >>> > >>> 一点、気にかかっているのは、WIN32_FMO_EACHの場合は、 > >>> CreateFileMappingでoffset + length分のmappingを作成している点です。 > >>> mmapと違ってファイルの途中から一部分だけmappingすることができないので、 > >>> このような手段を取っているのですが、そうすると論理空間を、 > >>> length分ではなく、offset + length分消費してしまうのかも知れません。 > >>> > >>> また、WIN32_FMO_EACHでない場合は、UnmapViewOfFileの際にCloseHandleを発行 > していないので、 > >>> これも問題かも知れません > >>> > >>> 以上、すぐには着手できないのですが、私達の方でも検証してみたいと思いま > す。 > >>> > >>> > >>> -- > >>> mori > > --- > > Tasuku SUENAGA > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > -- mori From morita ＠ razil.jp Thu Sep 20 17:44:56 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Thu, 20 Sep 2007 17:44:56 +0900 Subject: [Ludia-users 90] Re: =?iso-2022-jp?b?Q3JlYXRlSW5kZXgbJEIkRyUoJWkhPBsoQg==?= In-Reply-To: References: <000a01c7d8cc$0fae07e0$3600a8c0@public.local> Message-ID: <20070920084456.GA2450@epepe.com> こんにちは。森です。 ずいぶん時間が空いてしまったのですが、 windows環境で論理空間の消費を抑えられるかも知れない方法を実装してみました。 といってもごく単純な考えなのですが、 SEN.i.c*ファイルの読み書きに関しては、MapViewOfFileを使用せず、 すべてReadFile, WriteFileで処理すます。 (SEN, SEN.i, SEN.lファイルについては従来どおりMapViewOfFileを使用します) インデックスが大きくなると、主にSEN.i.c*ファイルが成長しますので、 その読み書きにメモリを消費しなくなれば、論理空間の枯渇も抑えられるのではないかと。 Senna rev552ではこの挙動になっています。 (WIN32以外の環境での挙動は変わっていません) もしよろしければお試し下さい。 >>> iwasakims ＠ nttdata.co.jp さんは書きました： > 岩崎です。 > > > ちょっとWindwosで大きなデータベースを作ったので、 > 遅ればせながら2GB超のインデックスを試してみました。 > 予想に反して?インデックスが正常にできました。 > > 環境は:: > > OS:WindowsXP Professinal(32bit) > PostgreSQL:8.2.4 > Senna:1.0.8 > Ludia:1.2.0 > > で、作成したインデックスのサイズは:: > > 844292.SEN 71434240 > 844292.SEN.i 181338112 > 844292.SEN.i.c 1073676288 > 844292.SEN.i.c.001 1073741824 > 844292.SEN.i.c.002 767819776 > 844292.SEN.l 42074112 > > という感じです。 > 同じ単語が500万回くらい出現するようにしてみてます。 > > 問題は > > http://support.microsoft.com/kb/830783/ja > > のあたりだったりするのでしょうか？ > > > -- > 岩崎 正剛 / IWASAKI Masatake > mailto:iwasakims ＠ nttdata.co.jp > > > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of Shingo > Kawamura > Sent: Tuesday, August 07, 2007 5:22 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 73] Re:CreateIndexでエラー > > 河村です。 > > > Windows上でmmapに相当するAPIの調査を進めてきました。 > > その結果、 > > 論理空間を枯渇させないような実装の方向性が > > ある程度分かってきました。 > > やはり、あの実装では問題がありそうですか…。 > テストが足りないまま出してしまい申し訳ありませんでした。 > > > いまだ実験・実装等に着手できていないのですが、 > > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように > > 開発を続けております。 > > 期待しています！ > > 私の方でも、もう少し見てみたいと思っています。 > > ----- Original Message ----- > From: "Tasuku SUENAGA" > To: > Sent: Monday, August 06, 2007 9:20 PM > Subject: [Ludia-users 72] Re: CreateIndexでエラー > > > > 末永です。 > > > > Windows上でmmapに相当するAPIの調査を進めてきました。 > > その結果、 > > 論理空間を枯渇させないような実装の方向性が > > ある程度分かってきました。 > > > > いまだ実験・実装等に着手できていないのですが、 > > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように > > 開発を続けております。 > > > > Shingo Kawamura さんは書きました: > >> ご無沙汰しています。河村です。 > >> > >> 「1プロセス内で2GB」なのか、「1インデックスで2GB」なのか > >> を特定しようと思い、以下の調査を行いました。 > >> > >> CSV_ODD > >> と > >> CSV_EVEN > >> 二つのテーブルを用意して、各インデックスが1.5GB弱で、 > >> 合計が3GB以上になるようにデータ量を調節して、 > >> 1プロセス内で各テーブルへのInsertを交互に行ってみたのですが > >> 正常に動作完了しました。 > >> #/3GBスイッチははずしています > >> > >> 各テーブルのインデックスサイズは以下の通りです。 > >> ・CSV_ODD > >> サイズ：260,880 KB > >> --- > >> .SEN 12,416 KB > >> .SEN.i 84,160 KB > >> .SEN.i.c 524,096 KB > >> .SEN.i.c.001 523,264 KB > >> .SEN.i.c.002 492,544 KB > >> .SEN.i.c.003 145,408 KB > >> .SEN.l 8,320 KB > >> --- > >> ・CSV_EVEN > >> サイズ：260,880 KB > >> --- > >> .SEN 12,416 KB > >> .SEN.i 84,160 KB > >> .SEN.i.c 524,096 KB > >> .SEN.i.c.001 522,496 KB > >> .SEN.i.c.002 513,792 KB > >> .SEN.i.c.003 144,896 KB > >> .SEN.l 8,320 KB > >> --- > >> > >> このテストでもエラーが起きるかな、と思ったのですが、 > >> 正常終了してしまいました。^^; > >> > >> 最悪、このような方法で動作できそうなら、 > >> 件数でテーブルを振り分けて、全テーブルをUNIONして使う、 > >> という方法もありかなと思っています。 > >> > >> > >> ----- Original Message ----- > >> From: > >> To: > >> Sent: Thursday, July 12, 2007 2:11 PM > >> Subject: [Ludia-users 70] Re:CreateIndexでエラー > >> > >> > >>> 森です。お世話になっています。。 > >>> > >>>> パッチを当てて再度実行してみました。 > >>>> --- > >>>> 07/11:06:49:10.021|A| MapViewOfFile failed #8 <400293888> > >>>> 07/11:06:49:10.071|A| io_win_map(8183, 287121676) failed!! > >>> ありがとうございます。 > >>> > >>> ひょっとするとSennaロジックのレベルでちゃんとメモリを解放していないので > はないかと > >>> 考えたのですが、お蔭様でその疑いは晴れました。 > >>> > >>> どうやらUnmapViewOfFile, CloseHandleという手順を踏んでも > >>> 意図したように論理空間が解放できていないように見受けられます。 > >>> > >>> 一点、気にかかっているのは、WIN32_FMO_EACHの場合は、 > >>> CreateFileMappingでoffset + length分のmappingを作成している点です。 > >>> mmapと違ってファイルの途中から一部分だけmappingすることができないので、 > >>> このような手段を取っているのですが、そうすると論理空間を、 > >>> length分ではなく、offset + length分消費してしまうのかも知れません。 > >>> > >>> また、WIN32_FMO_EACHでない場合は、UnmapViewOfFileの際にCloseHandleを発行 > していないので、 > >>> これも問題かも知れません > >>> > >>> 以上、すぐには着手できないのですが、私達の方でも検証してみたいと思いま > す。 > >>> > >>> > >>> -- > >>> mori > > --- > > Tasuku SUENAGA > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > -- mori From iwasakims ＠ nttdata.co.jp Fri Sep 21 10:58:47 2007 From: iwasakims ＠ nttdata.co.jp (iwasakims ＠ nttdata.co.jp) Date: Fri, 21 Sep 2007 10:58:47 +0900 Subject: [Ludia-users 91] =?iso-2022-jp?b?THVkaWEgMS4zLjAgGyRCJHIlaiVqITwlOSQ3JF4kNyQ/GyhC?= =?iso-2022-jp?b?GyRCISMbKEI=?= Message-ID: 岩崎です。こんにちは。 Ludia 1.3.0 をリリースしました。 変更内容は以下のような感じで、 マルチカラムインデックス対応が目玉になってます。 - マルチカラムインデックス対応 - REINDEXコマンド実行時の挙動改善 　- Sennaインデックスのオプションが引き継がれる 　- Sennaインデックスファイルが削除される マルチカラムインデックスについては、 下記のユーザガイド(応用編)も参照してみてください。 http://ludia.sourceforge.jp/cgi-bin/moin.cgi/LudiaReadmeAdvanced 利用していてなにか不具合があれば、 ご報告いただければと思います。 よろしくおねがいします。 -- 岩崎 正剛 / IWASAKI Masatake mailto:iwasakims ＠ nttdata.co.jp From sh.kawamura ＠ gmail.com Fri Sep 21 13:28:29 2007 From: sh.kawamura ＠ gmail.com (Shingo Kawamura) Date: Fri, 21 Sep 2007 13:28:29 +0900 Subject: [Ludia-users 92] Re: =?iso-2022-jp?b?Q3JlYXRlSW5kZXgbJEIkRyUoJWkhPBsoQg==?= References: <000a01c7d8cc$0fae07e0$3600a8c0@public.local> <20070920084456.GA2450@epepe.com> Message-ID: <001801c7fc07$de989260$3600a8c0@public.local> 森様 おお…。対応ありがとうございます。 今少々立て込んでまして直ぐは難しいですが、 以前のデータは残ってますので、時間を見つけて試してみたいと思います。 岩崎様 お返事が遅くなりました。申し訳ありません。 私の方でも新しいLudia1.2で一度試したのですが、 以前は2GB辺りで落ちたのが、2.7GB近くで落ちると若干動作が変わりました…^^; が、結局成功はしませんでした。 データにもよるのでしょうか… ----- Original Message ----- From: To: Sent: Thursday, September 20, 2007 5:44 PM Subject: [Ludia-users 89] Re:CreateIndexでエラー > こんにちは。森です。 > > ずいぶん時間が空いてしまったのですが、 > windows環境で論理空間の消費を抑えられるかも知れない方法を実装してみました。 > > > といってもごく単純な考えなのですが、 > SEN.i.c*ファイルの読み書きに関しては、MapViewOfFileを使用せず、 > すべてReadFile, WriteFileで処理すます。 > > (SEN, SEN.i, SEN.lファイルについては従来どおりMapViewOfFileを使用します) > > インデックスが大きくなると、主にSEN.i.c*ファイルが成長しますので、 > その読み書きにメモリを消費しなくなれば、論理空間の枯渇も抑えられるのではないかと。 > > Senna rev552ではこの挙動になっています。 > (WIN32以外の環境での挙動は変わっていません) > > もしよろしければお試し下さい。 > >>>> iwasakims ＠ nttdata.co.jp さんは書きました： >> 岩崎です。 >> >> >> ちょっとWindwosで大きなデータベースを作ったので、 >> 遅ればせながら2GB超のインデックスを試してみました。 >> 予想に反して?インデックスが正常にできました。 >> >> 環境は:: >> >> OS:WindowsXP Professinal(32bit) >> PostgreSQL:8.2.4 >> Senna:1.0.8 >> Ludia:1.2.0 >> >> で、作成したインデックスのサイズは:: >> >> 844292.SEN 71434240 >> 844292.SEN.i 181338112 >> 844292.SEN.i.c 1073676288 >> 844292.SEN.i.c.001 1073741824 >> 844292.SEN.i.c.002 767819776 >> 844292.SEN.l 42074112 >> >> という感じです。 >> 同じ単語が500万回くらい出現するようにしてみてます。 >> >> 問題は >> >> http://support.microsoft.com/kb/830783/ja >> >> のあたりだったりするのでしょうか？ >> >> >> -- >> 岩崎 正剛 / IWASAKI Masatake >> mailto:iwasakims ＠ nttdata.co.jp >> >> >> -----Original Message----- >> From: ludia-users-bounces ＠ lists.sourceforge.jp >> [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of Shingo >> Kawamura >> Sent: Tuesday, August 07, 2007 5:22 PM >> To: ludia-users ＠ lists.sourceforge.jp >> Subject: [Ludia-users 73] Re:CreateIndexでエラー >> >> 河村です。 >> >> > Windows上でmmapに相当するAPIの調査を進めてきました。 >> > その結果、 >> > 論理空間を枯渇させないような実装の方向性が >> > ある程度分かってきました。 >> >> やはり、あの実装では問題がありそうですか…。 >> テストが足りないまま出してしまい申し訳ありませんでした。 >> >> > いまだ実験・実装等に着手できていないのですが、 >> > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように >> > 開発を続けております。 >> >> 期待しています！ >> >> 私の方でも、もう少し見てみたいと思っています。 >> >> ----- Original Message ----- >> From: "Tasuku SUENAGA" >> To: >> Sent: Monday, August 06, 2007 9:20 PM >> Subject: [Ludia-users 72] Re: CreateIndexでエラー >> >> >> > 末永です。 >> > >> > Windows上でmmapに相当するAPIの調査を進めてきました。 >> > その結果、 >> > 論理空間を枯渇させないような実装の方向性が >> > ある程度分かってきました。 >> > >> > いまだ実験・実装等に着手できていないのですが、 >> > 将来的にはi.c.xxxファイルが肥大しても大丈夫となるように >> > 開発を続けております。 >> > >> > Shingo Kawamura さんは書きました: >> >> ご無沙汰しています。河村です。 >> >> >> >> 「1プロセス内で2GB」なのか、「1インデックスで2GB」なのか >> >> を特定しようと思い、以下の調査を行いました。 >> >> >> >> CSV_ODD >> >> と >> >> CSV_EVEN >> >> 二つのテーブルを用意して、各インデックスが1.5GB弱で、 >> >> 合計が3GB以上になるようにデータ量を調節して、 >> >> 1プロセス内で各テーブルへのInsertを交互に行ってみたのですが >> >> 正常に動作完了しました。 >> >> #/3GBスイッチははずしています >> >> >> >> 各テーブルのインデックスサイズは以下の通りです。 >> >> ・CSV_ODD >> >> サイズ：260,880 KB >> >> --- >> >> .SEN 12,416 KB >> >> .SEN.i 84,160 KB >> >> .SEN.i.c 524,096 KB >> >> .SEN.i.c.001 523,264 KB >> >> .SEN.i.c.002 492,544 KB >> >> .SEN.i.c.003 145,408 KB >> >> .SEN.l 8,320 KB >> >> --- >> >> ・CSV_EVEN >> >> サイズ：260,880 KB >> >> --- >> >> .SEN 12,416 KB >> >> .SEN.i 84,160 KB >> >> .SEN.i.c 524,096 KB >> >> .SEN.i.c.001 522,496 KB >> >> .SEN.i.c.002 513,792 KB >> >> .SEN.i.c.003 144,896 KB >> >> .SEN.l 8,320 KB >> >> --- >> >> >> >> このテストでもエラーが起きるかな、と思ったのですが、 >> >> 正常終了してしまいました。^^; >> >> >> >> 最悪、このような方法で動作できそうなら、 >> >> 件数でテーブルを振り分けて、全テーブルをUNIONして使う、 >> >> という方法もありかなと思っています。 >> >> >> >> >> >> ----- Original Message ----- >> >> From: >> >> To: >> >> Sent: Thursday, July 12, 2007 2:11 PM >> >> Subject: [Ludia-users 70] Re:CreateIndexでエラー >> >> >> >> >> >>> 森です。お世話になっています。。 >> >>> >> >>>> パッチを当てて再度実行してみました。 >> >>>> --- >> >>>> 07/11:06:49:10.021|A| MapViewOfFile failed #8 <400293888> >> >>>> 07/11:06:49:10.071|A| io_win_map(8183, 287121676) failed!! >> >>> ありがとうございます。 >> >>> >> >>> ひょっとするとSennaロジックのレベルでちゃんとメモリを解放していないので >> >>> >> はないかと >> >>> 考えたのですが、お蔭様でその疑いは晴れました。 >> >>> >> >>> どうやらUnmapViewOfFile, CloseHandleという手順を踏んでも >> >>> 意図したように論理空間が解放できていないように見受けられます。 >> >>> >> >>> 一点、気にかかっているのは、WIN32_FMO_EACHの場合は、 >> >>> CreateFileMappingでoffset + length分のmappingを作成している点です。 >> >>> mmapと違ってファイルの途中から一部分だけmappingすることができないので、 >> >>> >> >>> このような手段を取っているのですが、そうすると論理空間を、 >> >>> length分ではなく、offset + length分消費してしまうのかも知れません。 >> >>> >> >>> また、WIN32_FMO_EACHでない場合は、UnmapViewOfFileの際にCloseHandleを発行 >> していないので、 >> >>> これも問題かも知れません >> >>> >> >>> 以上、すぐには着手できないのですが、私達の方でも検証してみたいと思いま >> >>> >> す。 >> >>> >> >>> >> >>> -- >> >>> mori >> > --- >> > Tasuku SUENAGA >> > >> > _______________________________________________ >> > Ludia-users mailing list >> > Ludia-users ＠ lists.sourceforge.jp >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > -- > mori > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From t_kawanishi ＠ hotmail.co.jp Tue Sep 25 08:43:51 2007 From: t_kawanishi ＠ hotmail.co.jp (=?iso-2022-jp?B?GyRCQG5APhsoQiAbJEJFLzF7GyhC?=) Date: Tue, 25 Sep 2007 08:43:51 +0900 Subject: [Ludia-users 93] =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQkRhsoQg==?= Message-ID: はじめまして。川西と申します。 リリース前のシステムでludiaを使用させていただいています。 sen_index_upd failedについて質問させてください。 環境は以下の通りです。 CentOS 5.0 PostgreSQL 8.2.3 ludia-1.1.0 senna-1.0.7 ※CEにて年単位でテーブル分割を行っています。 ※indexはngramを使用しています。 UPDATE、および、INSERT場合に、pgsenna2の"sen_index_upd failed"が出力され、 データの登録に失敗する状況が発生しました。 senna.logでは"loop found!!"、"invalid jump!"などが出力されています。 発生後、約25件程度"sen_index_upd failed"が現象が発生し、 この状態は約一日で治まりました。 エラーメッセージより、indexの更新に失敗していることは解るのですが、 具体的な原因やどのような状態になっているのかが解っていません。 また、末永さんのblogで、insert/updateのあとrollbackがかかった場合、 indexにゴミが混じることがあるとの記載がありますが、 現在の構成では、マスタテーブルと検索テーブルを分けるような構成に なっていません。またトランザクションも利用しています。 こちらが原因の可能性も高いでしょうか？ http://d.hatena.ne.jp/tasukuchan/20061129/1164778826 原因、および、対処法などお解かりでしたら、 お手数ですがご教示いただきたいと思います。 よろしくお願いいたします。 postgresのエラーの一部を抜粋します。 2007-09-20 14:10:54 postgres7 error: [-1: ERROR: pgsenna2: sen_index_upd failed while do_insert (2) senna.logの一部を抜粋します。 09/20:14:07:52.441131|n| RLIMIT_STACK is 10485760 (0) 09/20:14:07:52.441192|n| expanded RLIMIT_STACK to 268435456 09/20:14:07:52.441258|n| RLIMIT_STACK is 268435456 (0) 09/20:14:07:52.441457|n| index opened (0xa224f38:/var/lib/pgsql/data/base/1778234/1799079) flags=1f 09/20:14:07:52.541977|n| palloced when untoasted (0xa44b798) 09/20:14:07:52.542097|n| RLIMIT_STACK is 268435456 (0) 09/20:14:07:52.542330|n| index opened (0xa225360:/var/lib/pgsql/data/base/1778234/1799080) flags=1f 09/20:14:07:52.564553|n| RLIMIT_STACK is 268435456 (0) 09/20:14:07:52.564788|n| index opened (0xa225788:/var/lib/pgsql/data/base/1778234/1799081) flags=1f 09/20:14:07:52.613647|n| RLIMIT_STACK is 268435456 (0) 09/20:14:07:52.613893|n| index opened (0xa225bb0:/var/lib/pgsql/data/base/1778234/1799082) flags=1f 09/20:14:10:40.109939|n| RLIMIT_STACK is 10485760 (0) 09/20:14:10:40.460210|n| expanded RLIMIT_STACK to 268435456 09/20:14:10:40.488812|n| RLIMIT_STACK is 268435456 (0) 09/20:14:10:40.956380|n| index opened (0xa190778:/var/lib/pgsql/data/base/1778234/1799079) flags=1f 09/20:14:10:45.800961|E| loop found!!! (51212:1)->(0:0) 09/20:14:10:46.617661|E| loop found!!! (50504:1)->(3727:0) 09/20:14:10:47.485024|E| loop found!!! (51016:1)->(4:1013) 09/20:14:10:48.737117|C| invalid jump! 7865(0:7836)(52581:1)->7794(0:7796)(0:0) 09/20:14:10:50.804589|C| invalid jump! 31431(30567:31396)(52501:1)->29656(0:29669)(0:0) 09/20:14:10:52.564664|E| loop found!!! (50503:1)->(4:2607) 09/20:14:10:52.807168|E| loop found!!! (50028:1)->(0:0) 09/20:14:10:53.011988|E| loop found!!! (49811:1)->(767:0) 09/20:14:10:53.254620|E| loop found!!! (50242:1)->(6:490) 09/20:14:10:53.481105|E| loop found!!! (50513:1)->(4:8443) 09/20:14:10:53.738077|C| invalid jump! 10460(9053:9991)(52463:1)->7777(0:7793)(0:0) 09/20:14:10:53.774484|E| loop found!!! (50111:1)->(103:2022) 09/20:14:10:53.897157|E| loop found!!! (51016:1)->(5146:1035311) 09/20:14:10:54.032543|C| invalid jump! 29781(29718:29737)(52585:1)->29650(0:29656)(0:0) 09/20:14:10:54.054132|E| loop found!!! (50243:1)->(4:721) 09/20:14:10:54.221203|C| invalid jump! 45379(44884:45332)(52567:1)->44225(0:44259)(0:0) 09/20:14:10:54.331345|E| loop found!!! (50027:1)->(4:5459) 09/20:14:18:51.697934|n| RLIMIT_STACK is 10485760 (0) 09/20:14:18:51.697998|n| expanded RLIMIT_STACK to 268435456 09/20:14:18:51.698053|n| RLIMIT_STACK is 268435456 (0) 09/20:14:18:51.698347|n| index opened (0xa03f550:/var/lib/pgsql/data/base/1778234/1799079) flags=1f 09/20:14:18:51.698436|n| RLIMIT_STACK is 268435456 (0) 09/20:14:18:51.760899|n| index opened (0xa0f8318:/var/lib/pgsql/data/base/1778234/1799080) flags=1f 09/20:14:18:52.183709|n| RLIMIT_STACK is 268435456 (0) 09/20:14:18:52.224979|n| index opened (0xa0f8740:/var/lib/pgsql/data/base/1778234/1799081) flags=1f 09/20:14:18:53.008296|n| RLIMIT_STACK is 268435456 (0) 09/20:14:18:53.043750|n| index opened (0xa0f8b68:/var/lib/pgsql/data/base/1778234/1799082) flags=1f Tetsuo Kawanishi t_kawanishi ＠ hotmail.co.jp _________________________________________________________________ 広告表示なし。アカウント有効期限なし。Windows Live Hotmail Plusを使ってみ る？ http://get.live.com/mail/options From morita ＠ razil.jp Wed Sep 26 16:29:10 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 26 Sep 2007 16:29:10 +0900 Subject: [Ludia-users 94] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: References: Message-ID: <20070926072910.GA7843@epepe.com> こんにちは。森と申します。 エラーメッセージから判断すると、インデックスが破損しているようです。 以下の点について確認させて頂いてよろしいでしょうか? 1) 再現性について。 この事象には再現性はあるでしょうか? データベースが空っぽの状態、 あるいはインデックスをcreateした直後の状態からテストして、 必ず再現するか、あるいは不定期に低い頻度でしか再現しないか。 2) 検索/更新処理のシーケンス 同時にいくつ程度のセッションを張ることがあるでしょうか? 複数のセッションが同時に当該テーブルを更新するシーケンスも存在するでしょうか? 以上よろしくお願いいたします。 >>> 川西 哲央 さんは書きました： > はじめまして。川西と申します。 > > リリース前のシステムでludiaを使用させていただいています。 > sen_index_upd failedについて質問させてください。 > > 環境は以下の通りです。 > CentOS 5.0 > PostgreSQL 8.2.3 > ludia-1.1.0 > senna-1.0.7 > ※CEにて年単位でテーブル分割を行っています。 > ※indexはngramを使用しています。 > > UPDATE、および、INSERT場合に、pgsenna2の"sen_index_upd failed"が出力され、 > データの登録に失敗する状況が発生しました。 > senna.logでは"loop found!!"、"invalid jump!"などが出力されています。 > 発生後、約25件程度"sen_index_upd failed"が現象が発生し、 > この状態は約一日で治まりました。 > > エラーメッセージより、indexの更新に失敗していることは解るのですが、 > 具体的な原因やどのような状態になっているのかが解っていません。 > > また、末永さんのblogで、insert/updateのあとrollbackがかかった場合、 > indexにゴミが混じることがあるとの記載がありますが、 > 現在の構成では、マスタテーブルと検索テーブルを分けるような構成に > なっていません。またトランザクションも利用しています。 > こちらが原因の可能性も高いでしょうか？ > http://d.hatena.ne.jp/tasukuchan/20061129/1164778826 > > 原因、および、対処法などお解かりでしたら、 > お手数ですがご教示いただきたいと思います。 > > よろしくお願いいたします。 > > postgresのエラーの一部を抜粋します。 > 2007-09-20 14:10:54 postgres7 error: [-1: ERROR: pgsenna2: sen_index_upd > failed while do_insert (2) > > senna.logの一部を抜粋します。 > 09/20:14:07:52.441131|n| RLIMIT_STACK is 10485760 (0) > 09/20:14:07:52.441192|n| expanded RLIMIT_STACK to 268435456 > 09/20:14:07:52.441258|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:07:52.441457|n| index opened > (0xa224f38:/var/lib/pgsql/data/base/1778234/1799079) flags=1f > 09/20:14:07:52.541977|n| palloced when untoasted (0xa44b798) > 09/20:14:07:52.542097|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:07:52.542330|n| index opened > (0xa225360:/var/lib/pgsql/data/base/1778234/1799080) flags=1f > 09/20:14:07:52.564553|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:07:52.564788|n| index opened > (0xa225788:/var/lib/pgsql/data/base/1778234/1799081) flags=1f > 09/20:14:07:52.613647|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:07:52.613893|n| index opened > (0xa225bb0:/var/lib/pgsql/data/base/1778234/1799082) flags=1f > 09/20:14:10:40.109939|n| RLIMIT_STACK is 10485760 (0) > 09/20:14:10:40.460210|n| expanded RLIMIT_STACK to 268435456 > 09/20:14:10:40.488812|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:10:40.956380|n| index opened > (0xa190778:/var/lib/pgsql/data/base/1778234/1799079) flags=1f > 09/20:14:10:45.800961|E| loop found!!! (51212:1)->(0:0) > 09/20:14:10:46.617661|E| loop found!!! (50504:1)->(3727:0) > 09/20:14:10:47.485024|E| loop found!!! (51016:1)->(4:1013) > 09/20:14:10:48.737117|C| invalid jump! > 7865(0:7836)(52581:1)->7794(0:7796)(0:0) > 09/20:14:10:50.804589|C| invalid jump! > 31431(30567:31396)(52501:1)->29656(0:29669)(0:0) > 09/20:14:10:52.564664|E| loop found!!! (50503:1)->(4:2607) > 09/20:14:10:52.807168|E| loop found!!! (50028:1)->(0:0) > 09/20:14:10:53.011988|E| loop found!!! (49811:1)->(767:0) > 09/20:14:10:53.254620|E| loop found!!! (50242:1)->(6:490) > 09/20:14:10:53.481105|E| loop found!!! (50513:1)->(4:8443) > 09/20:14:10:53.738077|C| invalid jump! > 10460(9053:9991)(52463:1)->7777(0:7793)(0:0) > 09/20:14:10:53.774484|E| loop found!!! (50111:1)->(103:2022) > 09/20:14:10:53.897157|E| loop found!!! (51016:1)->(5146:1035311) > 09/20:14:10:54.032543|C| invalid jump! > 29781(29718:29737)(52585:1)->29650(0:29656)(0:0) > 09/20:14:10:54.054132|E| loop found!!! (50243:1)->(4:721) > 09/20:14:10:54.221203|C| invalid jump! > 45379(44884:45332)(52567:1)->44225(0:44259)(0:0) > 09/20:14:10:54.331345|E| loop found!!! (50027:1)->(4:5459) > 09/20:14:18:51.697934|n| RLIMIT_STACK is 10485760 (0) > 09/20:14:18:51.697998|n| expanded RLIMIT_STACK to 268435456 > 09/20:14:18:51.698053|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:18:51.698347|n| index opened > (0xa03f550:/var/lib/pgsql/data/base/1778234/1799079) flags=1f > 09/20:14:18:51.698436|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:18:51.760899|n| index opened > (0xa0f8318:/var/lib/pgsql/data/base/1778234/1799080) flags=1f > 09/20:14:18:52.183709|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:18:52.224979|n| index opened > (0xa0f8740:/var/lib/pgsql/data/base/1778234/1799081) flags=1f > 09/20:14:18:53.008296|n| RLIMIT_STACK is 268435456 (0) > 09/20:14:18:53.043750|n| index opened > (0xa0f8b68:/var/lib/pgsql/data/base/1778234/1799082) flags=1f > > Tetsuo Kawanishi > t_kawanishi ＠ hotmail.co.jp > > _________________________________________________________________ > 広告表示なし。アカウント有効期限なし。Windows Live Hotmail Plusを使ってみ > る？ http://get.live.com/mail/options > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > -- mori