From kiyotakex ＠ gmail.com Mon Oct 1 15:34:37 2007 From: kiyotakex ＠ gmail.com (=?ISO-2022-JP?B?GyRCTFoyPBsoQg==?=) Date: Mon, 1 Oct 2007 15:34:37 +0900 Subject: [Ludia-users 95] =?iso-2022-jp?b?cG9zdGdyZXNxbC5jb25mGyRCJE5AX0RqJCxIPzFHJDUbKEI=?= =?iso-2022-jp?b?GyRCJGwkXiQ7JHMbKEI=?= Message-ID: はじめまして。木下と申します。 よろしくお願いします。 Ludiaを使用するため、PostgreSQLとLudiaをインストールしました。 使用環境は以下の通りです。 RedHatEL3 PostgreSQL-8.2.3 senna-1.0.8 Ludia-1.3.0 Ludiaインストール後、 postgresql.confにLudiaの設定を追加し、PostgreSQLを再起動すると、 unrecognized configuration parameter "ludia.max_n_sort_result" のようなエラーが出てしまい、 PostgreSQLが起動せず、悩んでおります。 もしお分かりになられる方がございましたら、お教えいただければ幸いです。 postgresql.confに加えたLudiaのパラメータは以下の通りです。 custom_variable_classes = 'Ludia' ludia.max_n_sort_result = 10000 ludia.enable_seqscan = on ludia.sen_index_flags = 31 ludia.max_n_index_cache = 15 ludia.initial_n_segments = 512 インストールの手順は以下の通りです。 PostgreSQL →./configureオプションなし Mecab →./configure --with-charset=utf8 mecab-ipadic →./configure --with-charset=utf8 senna →./configureオプションなし Ludia →./configure \ --with-pg-config=/usr/local/pgsql/bin/pg_config \ --with-senna-cfg=/usr/local/bin/senna-cfg また、Ludiaの設定を全て外した場合は、PostgreSQLが通常通り起動しますが、 show ludia.max_n_sort_result; と入力すると、 unrecognized configuration parameter "ludia.max_n_sort_result" というエラーが出てしまい、やはりLudiaの設定が反映されていないようです。 なお、pgsenna2.sqlを実行してもエラーはなく、 select pgs2version();では、正しくLudia1.3.0と表示されています。 以上、記載しました情報に不足があるとは思いますが、 誤りをチェックする方法や、対処法などご存知の方おられましたら、 何卒ご教示くださいますよう、よろしくお願い申し上げます。 kinoshita -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/ludia-users/attachments/20071001/1dc2576e/attachment.htm From iwasakims ＠ nttdata.co.jp Mon Oct 1 15:41:43 2007 From: iwasakims ＠ nttdata.co.jp (iwasakims ＠ nttdata.co.jp) Date: Mon, 1 Oct 2007 15:41:43 +0900 Subject: [Ludia-users 96] Re: =?iso-2022-jp?b?cG9zdGdyZXNxbC5jb25mGyRCJE5AX0RqJCxIPzFHGyhC?= =?iso-2022-jp?b?GyRCJDUkbCReJDskcxsoQg==?= References: Message-ID: 岩崎です。こんにちは。 > postgresql.confにLudiaの設定を追加し、PostgreSQLを再起動すると、 > 　unrecognized configuration parameter "ludia.max_n_sort_result" > のようなエラーが出てしまい、 追加した設定が custom_variable_classes = 'Ludia' となっていますが、 custom_variable_classes = 'ludia' に直してみてください。 (大文字ではなく小文字のエルです。) ________________________________ From: ludia-users-bounces ＠ lists.sourceforge.jp [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of 木下 Sent: Monday, October 01, 2007 3:35 PM To: ludia-users ＠ lists.sourceforge.jp Subject: [Ludia-users 95]postgresql.confの設定が反映されません はじめまして。木下と申します。 よろしくお願いします。 Ludiaを使用するため、PostgreSQLとLudiaをインストールしました。 使用環境は以下の通りです。 　RedHatEL3 　PostgreSQL-8.2.3 　senna-1.0.8 　Ludia-1.3.0 Ludiaインストール後、 postgresql.confにLudiaの設定を追加し、PostgreSQLを再起動すると、 　unrecognized configuration parameter "ludia.max_n_sort_result" のようなエラーが出てしまい、 PostgreSQLが起動せず、悩んでおります。 もしお分かりになられる方がございましたら、お教えいただければ幸いです。 postgresql.confに加えたLudiaのパラメータは以下の通りです。 　custom_variable_classes = 'Ludia' 　ludia.max_n_sort_result = 10000 　ludia.enable_seqscan = on 　ludia.sen_index_flags = 31 　ludia.max_n_index_cache = 15 　ludia.initial_n_segments = 512 インストールの手順は以下の通りです。 　PostgreSQL　　→./configureオプションなし 　Mecab 　　　　→./configure --with-charset=utf8 　mecab-ipadic　→./configure --with-charset=utf8 　senna 　　　　→./configureオプションなし 　Ludia 　　　　→./configure \ 　　　　　　　　　--with-pg-config=/usr/local/pgsql/bin/pg_config \ 　　　　　　　　　--with-senna-cfg=/usr/local/bin/senna-cfg また、Ludiaの設定を全て外した場合は、PostgreSQLが通常通り起動しますが、 　show ludia.max_n_sort_result; と入力すると、 　unrecognized configuration parameter " ludia.max_n_sort_result" というエラーが出てしまい、やはりLudiaの設定が反映されていないようです。 なお、pgsenna2.sqlを実行してもエラーはなく、 select pgs2version();では、正しくLudia1.3.0と表示されています。 以上、記載しました情報に不足があるとは思いますが、 誤りをチェックする方法や、対処法などご存知の方おられましたら、 何卒ご教示くださいますよう、よろしくお願い申し上げます。 kinoshita From kiyotakex ＠ gmail.com Mon Oct 1 16:05:37 2007 From: kiyotakex ＠ gmail.com (=?ISO-2022-JP?B?GyRCTFoyPBsoQg==?=) Date: Mon, 1 Oct 2007 16:05:37 +0900 Subject: [Ludia-users 97] Re: =?iso-2022-jp?b?cG9zdGdyZXNxbC5jb25mGyRCJE5AX0RqJCxIPzFHGyhC?= =?iso-2022-jp?b?GyRCJDUkbCReJDskcxsoQg==?= In-Reply-To: References: Message-ID: 岩崎 様 木下です。こんにちは。 追加した設定が > > custom_variable_classes = 'Ludia' > > となっていますが、 > > custom_variable_classes = 'ludia' > > に直してみてください。 > (大文字ではなく小文字のエルです。) > ご指摘の通りで、なんなく解消いたしました。 本当に助かりました。ありがとうございました。 早速、Ludiaの機能（特にマルチインデックス）を試してみます。 -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/ludia-users/attachments/20071001/5c4e2e60/attachment.htm From kousakadi ＠ nttdata.co.jp Tue Oct 2 13:25:49 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Tue, 2 Oct 2007 13:25:49 +0900 Subject: [Ludia-users 98] =?iso-2022-jp?b?d2luZG93cyAbJEIlJCVzJTklSCE8JWkhPCRyJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkkNyReJDckPyEjGyhC?= Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C15@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 windows用のインストーラをリリースしました。 インストーラを用いると、Ludia, Sennaのコンパイルをせずに、 windowsでLudiaを試すことができます。 ぜひ試してみてください。 このインストーラーにより、 - LudiaのDLL (Ludia 1.3.0) - SennaのDLL (Senna 1.0.9) - MeCabのDLL (MeCab 0.96) - MeCab辞書 (エンコーディングはutf-8) がインストールされます。 不具合等があれば、ご報告いただければと思います。 https://sourceforge.jp/projects/ludia From sakamoto-t ＠ ma.dnes.nec.co.jp Thu Oct 4 19:38:47 2007 From: sakamoto-t ＠ ma.dnes.nec.co.jp (sakamoto) Date: Thu, 4 Oct 2007 19:38:47 +0900 Subject: [Ludia-users 99] =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= Message-ID: <00f601c80672$be8932c0$ae49440a@DNESsakata1> こんにちは、坂本といいます。 Windows環境にて、Ludia1.2+senna1.0.8　で利用させていただいています。 この中で、次のような現象が発生しています。 ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 原因や改善策などご教授いただければと思います。 ・初回から高速で検索できる方法 ・途中で遅くならない方法 Windows特有の現象でしょうか。 Ludia1.3+senna1.0.9　で改善される内容でしょうか。 よろしくお願いいたします。 From kanout ＠ nttdata.co.jp Thu Oct 4 21:16:40 2007 From: kanout ＠ nttdata.co.jp (kanout ＠ nttdata.co.jp) Date: Thu, 4 Oct 2007 21:16:40 +0900 Subject: [Ludia-users 100] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <00f601c80672$be8932c0$ae49440a@DNESsakata1> Message-ID: こんばんは　加納です。 > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその 構成は？この時間は単独で実行時でしょうか？ どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り 立ちます。 　１ランダムIOに8msecとする。 　ヒット件数は1万件 　→IO時間は80000msec＝80sec 　母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ 　ては大きな時間が要することは想定されます。 > 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ に乗っている可能性がありますので、その場合は当然早くなります。 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 しているものと思います。 > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ きます。 > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 これも同様に共有バッファからフラッシュされてしまったので、再度実IO が発生したと思われます。 このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる と思います。 http://www.postgresql.jp/document/pg824doc/html/monitoring-stats.html#MONITO RING-STATS-VIEWS From tanakasns ＠ nttdata.co.jp Tue Oct 9 09:52:18 2007 From: tanakasns ＠ nttdata.co.jp (Shunsuke Tanaka) Date: Tue, 09 Oct 2007 09:52:18 +0900 (LDT) Subject: [Ludia-users 101] =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= Message-ID: <20071009.095218.01366134.tanakasns@nttdata.co.jp> 田中と申します。 初めて投稿します。よろしくお願いします。 形態素インデックスでデータを連続して投入していたら、3万件くらい投入した ところから1件投入するのに1秒以上かかるようになり、処理がほとんど進まなく なってしまい困っております。 行った作業の順番は以下の通りです。 テーブルを作成 形態素インデックスを作成 データを1件ずつINSERT文で投入 テーブルには列が4つありますが、1つの列だけに形態素インデックスを作成しま した。 形態素インデックスを作成した列のデータは、可変長で、小さいものは数十Kバ イト、大きい物では数Mバイトで、たいていは100Kバイト程度です。 PostgreSQLのログに以下の出力が大量に出ているのが少し気になります。 LOG: pgsenna2: |w| invalid euc-jp string end on sen_str_charlen なお、同じデータを2-gramインデックスで投入したときは上記のログは出力されません。 使用したソフトウェアは以下の通りです。 Ludia 1.3.0 Senna 1.0.9 mecab 0.96 mecab-ipadic 2.7.0 20070801 PostgreSQL 8.2.4 Linux ( Fedora Core 2 (32bit版) (Kernel 2.6.5) ) 使用したハードウェアは以下の通りです。 Dell Precision 470 CPU: Xeon 2.8GHz × 2 Memory: 2Gbyte HDD: SATA 400Gbyte 7200rpm よろしくお願いします。 From a ＠ razil.jp Tue Oct 9 18:28:34 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Tue, 09 Oct 2007 18:28:34 +0900 Subject: [Ludia-users 102] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: <20071009.095218.01366134.tanakasns@nttdata.co.jp> References: <20071009.095218.01366134.tanakasns@nttdata.co.jp> Message-ID: <470B49C2.6080205@razil.jp> 末永と申します。 MeCabの辞書の文字コードは何になっていますでしょうか？ シェルで「mecab -D」を実行した結果を教えていただけると 切り分けに役立ちます。 Shunsuke Tanaka さんは書きました: > 田中と申します。 > > 初めて投稿します。よろしくお願いします。 > > 形態素インデックスでデータを連続して投入していたら、3万件くらい投入した > ところから1件投入するのに1秒以上かかるようになり、処理がほとんど進まなく > なってしまい困っております。 > > 行った作業の順番は以下の通りです。 > テーブルを作成 > 形態素インデックスを作成 > データを1件ずつINSERT文で投入 > > テーブルには列が4つありますが、1つの列だけに形態素インデックスを作成しま > した。 > 形態素インデックスを作成した列のデータは、可変長で、小さいものは数十Kバ > イト、大きい物では数Mバイトで、たいていは100Kバイト程度です。 > > PostgreSQLのログに以下の出力が大量に出ているのが少し気になります。 > LOG: pgsenna2: |w| invalid euc-jp string end on sen_str_charlen > > なお、同じデータを2-gramインデックスで投入したときは上記のログは出力されません。 > > 使用したソフトウェアは以下の通りです。 > Ludia 1.3.0 > Senna 1.0.9 > mecab 0.96 > mecab-ipadic 2.7.0 20070801 > PostgreSQL 8.2.4 > Linux ( Fedora Core 2 (32bit版) (Kernel 2.6.5) ) > > 使用したハードウェアは以下の通りです。 > Dell Precision 470 > CPU: Xeon 2.8GHz × 2 > Memory: 2Gbyte > HDD: SATA 400Gbyte 7200rpm > > よろしくお願いします。 --- Tasuku SUENAGA From t_kawanishi ＠ hotmail.co.jp Wed Oct 10 00:00:38 2007 From: t_kawanishi ＠ hotmail.co.jp (=?iso-2022-jp?B?GyRCQG5APhsoQiAbJEJFLzF7GyhC?=) Date: Wed, 10 Oct 2007 00:00:38 +0900 Subject: [Ludia-users 103] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= Message-ID: こんばんは。川西です。 森さん、ご返答いただきありがとうございます。 また、こちらの返信が遅くなってしまい、申し訳ありません。 以前、質問させていただいた「loop found!!」、「invalid jump! 」が 発生し、「sen_index_upd failed」となってしまう件ですが、 調査を進めたところ、この現象が発生する直前にマシンの電源が 突然切れるトラブル（電源ケーブルを抜くことと等価）が発生し、 現象発生の大きな要因となっていることが判明しました。 電源断の試験を行ったところ似たような現象は発生しました。 また、電源断以外に「sen_index_upd failed」となってしまう現象について 質問させてください。 大量にINSERT処理を行ったところ、postgreSQLのログで「sen_index_upd failed」と 出力され、INSERTできない状態になってしまいました。 sennaのログでは以下にある内容のエラーが発生しています。 上記と同じ現象と思われるものは、以前に2回ほど発生しており、 再現方法も概ね見当がついてきている状況です。 sennaのバージョンが1.0.7ですので、1.0.9へのアップグレードで解決となれば良い のですが、 何が原因となっているのかがわからない状況です。 何かお解りでしたら、ご教示くださいますよう、よろしくお願いします。 ●環境は以下の通りです。(本番機なので以前のものと多少構成が異なります) Redhat EL5 PostgreSQL 8.2.4 ludia-1.1.0 senna-1.0.7 ※CEにて年単位でテーブル分割を行っています。 ※indexはngramを使用しています。 ■postgreSQLログ pg_execute(): Query failed: ERROR: pgsenna2: sen_index_upd failed while do_insert (1) ■sennaログ 10/09:23:00:35.287498|A| io_win_map(11, 262144) failed!! 10/09:23:00:35.288274|A| mmap(%,262144,101)=U( %> 10/09:23:00:35.288291|A| io_win_map(11, 262144) failed!! 10/09:23:00:35.378396|A| mmap(%,262144,100)= <%> 10/09:23:04:57.911809|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:09:20.416216|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:13:42.860616|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:18:07.129766|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:22:31.194267|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:26:53.742684|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:31:16.039069|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) 10/09:23:35:40.783815|C| deadlock detected!! in sen_io_seg_ref(0x9bf66b8, 1028) Tetsuo Kawanishi t_kawanishi ＠ hotmail.co.jp >こんにちは。森と申します。 > >エラーメッセージから判断すると、インデックスが破損しているようです。 > >以下の点について確認させて頂いてよろしいでしょうか? > >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 > >_______________________________________________ >Ludia-users mailing list >Ludia-users ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/ludia-users _________________________________________________________________ Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウンロード http://promotion.msn.co.jp/ie7/ From masatake ＠ cj9.so-net.ne.jp Wed Oct 10 00:33:06 2007 From: masatake ＠ cj9.so-net.ne.jp (Masatake Iwasaki) Date: Wed, 10 Oct 2007 00:33:06 +0900 Subject: [Ludia-users 104] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: <20071009.095218.01366134.tanakasns@nttdata.co.jp> References: <20071009.095218.01366134.tanakasns@nttdata.co.jp> Message-ID: 岩崎と申します。 > 形態素インデックスでデータを連続して投入していたら、3万件くらい投入した > ところから1件投入するのに1秒以上かかるようになり、処理がほとんど進まなく > なってしまい困っております。 に関してですが、 > 形態素インデックスを作成した列のデータは、可変長で、小さいものは数十Kバ > イト、大きい物では数Mバイトで、たいていは100Kバイト程度です。 このインデックス対象となるテキストデータの総サイズはどのくらいでしょうか。 10GBを超えるような場合だと、 initial_n_segmentsというオプションの設定値を増やす必要があるかもしれません。 From tanakasns ＠ nttdata.co.jp Wed Oct 10 09:23:51 2007 From: tanakasns ＠ nttdata.co.jp (Shunsuke Tanaka) Date: Wed, 10 Oct 2007 09:23:51 +0900 (LDT) Subject: [Ludia-users 105] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: <470B49C2.6080205@razil.jp> References: <20071009.095218.01366134.tanakasns@nttdata.co.jp> <470B49C2.6080205@razil.jp> Message-ID: <20071010.092351.01365976.tanakasns@nttdata.co.jp> 田中です。 返信ありがとうございます。 mecab -D の実行結果は以下の通りです。 filename: /usr/local/lib/mecab/dic/ipadic/sys.dic version: 102 charset: utf8 type: 0 size: 392126 left size: 1316 right size: 1316 文字コードはutf8になっています。 インストールマニュアルの通りにインストールして、 utf8と設定した記憶もあります。 投入したデータはEUC_JPです。 PostgreSQLの方はinitdb実行時に --encoding=EUC_JP --no-locale オプション を付けています。 Sennaの方は /var/senna/senna.conf に DEFAULT_ENCODING utf8 と設定しています。 (前にLudia 1.0.0をインストールしたときに設定してそのままになってました。) utf8とEUC_JPが混在していて良くない感じですね。 データはEUC_JPのままで使いたいので、全てをEUC_JPに統一して、 もう一度やってみたいと思います。 それから、 インデックス対象のテキストデータの総サイズは3万件程度では10GBは超えないと思います。 10万件くらいになると10GBは超える可能性があるので、 データ投入がスムーズにできるようになり、10万件くらい投入できて、 それっぽいエラーが出るようならば、initial_n_segmentsを変えて試してみたいと思います。 > 末永と申します。 > > MeCabの辞書の文字コードは何になっていますでしょうか？ > シェルで「mecab -D」を実行した結果を教えていただけると > 切り分けに役立ちます。 > > Shunsuke Tanaka さんは書きました: > > 田中と申します。 > > > > 初めて投稿します。よろしくお願いします。 > > > > 形態素インデックスでデータを連続して投入していたら、3万件くらい投入した > > ところから1件投入するのに1秒以上かかるようになり、処理がほとんど進まなく > > なってしまい困っております。 > > > > 行った作業の順番は以下の通りです。 > > テーブルを作成 > > 形態素インデックスを作成 > > データを1件ずつINSERT文で投入 > > > > テーブルには列が4つありますが、1つの列だけに形態素インデックスを作成しま > > した。 > > 形態素インデックスを作成した列のデータは、可変長で、小さいものは数十Kバ > > イト、大きい物では数Mバイトで、たいていは100Kバイト程度です。 > > > > PostgreSQLのログに以下の出力が大量に出ているのが少し気になります。 > > LOG: pgsenna2: |w| invalid euc-jp string end on sen_str_charlen > > > > なお、同じデータを2-gramインデックスで投入したときは上記のログは出力されません。 > > > > 使用したソフトウェアは以下の通りです。 > > Ludia 1.3.0 > > Senna 1.0.9 > > mecab 0.96 > > mecab-ipadic 2.7.0 20070801 > > PostgreSQL 8.2.4 > > Linux ( Fedora Core 2 (32bit版) (Kernel 2.6.5) ) > > > > 使用したハードウェアは以下の通りです。 > > Dell Precision 470 > > CPU: Xeon 2.8GHz × 2 > > Memory: 2Gbyte > > HDD: SATA 400Gbyte 7200rpm > > > > よろしくお願いします。 > --- > Tasuku SUENAGA > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From morita ＠ razil.jp Wed Oct 10 15:55:02 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 10 Oct 2007 15:55:02 +0900 Subject: [Ludia-users 106] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: References: Message-ID: <20071010065502.GA3268@epepe.com> こんにちは。森です。 >>> 川西 哲央 さんは書きました： > こんばんは。川西です。 > > 森さん、ご返答いただきありがとうございます。 > また、こちらの返信が遅くなってしまい、申し訳ありません。 いえいえ。詳細な障害報告ありがとうございます。大変助かります。 > 以前、質問させていただいた「loop found!!」、「invalid jump! 」が > 発生し、「sen_index_upd failed」となってしまう件ですが、 > 調査を進めたところ、この現象が発生する直前にマシンの電源が > 突然切れるトラブル（電源ケーブルを抜くことと等価）が発生し、 > 現象発生の大きな要因となっていることが判明しました。 > 電源断の試験を行ったところ似たような現象は発生しました。 たしかに、正常にshutdownせずに電源を切るとこのような形でインデックスが 破損する可能性があります。 > また、電源断以外に「sen_index_upd failed」となってしまう現象について > 質問させてください。 > 大量にINSERT処理を行ったところ、postgreSQLのログで「sen_index_upd failed」と > > 出力され、INSERTできない状態になってしまいました。 > sennaのログでは以下にある内容のエラーが発生しています。 > > 上記と同じ現象と思われるものは、以前に2回ほど発生しており、 > 再現方法も概ね見当がついてきている状況です。 > > sennaのバージョンが1.0.7ですので、1.0.9へのアップグレードで解決となれば良い > のですが、 > 何が原因となっているのかがわからない状況です。 > 何かお解りでしたら、ご教示くださいますよう、よろしくお願いします。 1.0.7では、mmapに失敗した場合にdeadlockに陥り、 以降、更新処理が一切行えなくなる障害がありました。 これは1.0.9で解消している可能性が高いと思います。 ただし、mmapの失敗そのものが解消するわけではありません。 mmapが失敗するのは、論理メモリ空間やファイルデスクリプタ等の資源が枯渇している ことが原因である可能性が高いと思いますが、未知のSennaのバグである可能性もあると 思います。 この事象が発生した時点でのpostgresqlプロセスの資源消費状況を教えていただけると 判断できると思います。具体的には以下の実行結果がいただけると助かります。 cat /proc/pid/status cat /proc/pid/maps ls -l /proc/pid/fd/ ls -lL /proc/pid/fd/ 以上よろしくお願いいたします。 -- mori From t_kawanishi ＠ hotmail.co.jp Wed Oct 10 18:23:32 2007 From: t_kawanishi ＠ hotmail.co.jp (Kawanishi Tetsuo) Date: Wed, 10 Oct 2007 18:23:32 +0900 Subject: [Ludia-users 107] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <20071010065502.GA3268@epepe.com> Message-ID: こんにちは。川西です。 ご回答いただき、ありがとうございます。 >1.0.7では、mmapに失敗した場合にdeadlockに陥り、 >以降、更新処理が一切行えなくなる障害がありました。 >これは1.0.9で解消している可能性が高いと思います。 deadlockの問題は解消している可能性が高いのですね。 1.0.9でも試してみたいと思います。 >ただし、mmapの失敗そのものが解消するわけではありません。 > >mmapが失敗するのは、論理メモリ空間やファイルデスクリプタ等の資源が枯渇して いる >ことが原因である可能性が高いと思いますが、未知のSennaのバグである可能性もあ ると >思います。 > >この事象が発生した時点でのpostgresqlプロセスの資源消費状況を教えていただけ ると >判断できると思います。具体的には以下の実行結果がいただけると助かります。 mmapに関しては、Linuxカーネルの問題などもあるようで、原因の特定が難しいと思 いますので、 postgresqlプロセスの資源消費状況を見ていただけると大変助かります。 「/proc/pid/maps」については、かなりボリュームがありますので、添付は控えてお きます。 以前FTPでPUTするようなやり取りがあったと思うのですが、そういったことは可能で しょうか？ そのほかの情報は下記の通りです。 > cat /proc/pid/status Name: postmaster State: S (sleeping) SleepAVG: 98% Tgid: 3839 Pid: 3839 PPid: 4180 TracerPid: 0 Uid: 26 26 26 26 Gid: 26 26 26 26 FDSize: 256 Groups: 26 VmPeak: 3144368 kB VmSize: 3144368 kB VmLck: 0 kB VmHWM: 1968204 kB VmRSS: 490748 kB VmData: 28896 kB VmStk: 88 kB VmExe: 3072 kB VmLib: 5420 kB VmPTE: 5996 kB StaBrk: 08394000 kB Brk: 09e66000 kB StaStk: bf8ecc80 kB Threads: 1 SigQ: 0/180352 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000001301000 SigCgt: 0000000000006a87 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 Cpus_allowed: ffffffff Mems_allowed: 1 >/proc/pid/fd/ 4008526.SEN.l 8462336 4008526.SEN.i 258674688 4008526.SEN.i.c 266240 4008528.SEN 8462336 4008528.SEN.l 8462336 4008528.SEN.i 269422592 4008528.SEN.i.c 1052672 4008538.SEN 8462336 4008538.SEN.l 8462336 4008538.SEN.i 266014720 4008538.SEN.i.c 266240 4008539.SEN 8462336 4008539.SEN.l 8462336 4008539.SEN.i 252907520 4008539.SEN.i.c 266240 4008511.SEN 8462336 4008511.SEN.l 8462336 4008511.SEN.i 268898304 4008511.SEN.i.c 266240 4008513.SEN 8462336 4008513.SEN.l 12656640 4008513.SEN.i 271519744 4008513.SEN.i.c 334761984 4008523.SEN 8462336 4008523.SEN.l 8462336 4008523.SEN.i 268898304 4008523.SEN.i.c 266240 4008524.SEN 8462336 4008524.SEN.l 8462336 4008524.SEN.i 268898304 4008524.SEN.i.c 266240 4008526.SEN 8462336 以上、よろしくお願いいたします。 Tetsuo Kawanishi _________________________________________________________________ Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウンロード http://promotion.msn.co.jp/ie7/ From tanakasns ＠ nttdata.co.jp Thu Oct 11 10:20:41 2007 From: tanakasns ＠ nttdata.co.jp (Shunsuke Tanaka) Date: Thu, 11 Oct 2007 10:20:41 +0900 (LDT) Subject: [Ludia-users 108] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: <20071010.092351.01365976.tanakasns@nttdata.co.jp> References: <20071009.095218.01366134.tanakasns@nttdata.co.jp> <470B49C2.6080205@razil.jp> <20071010.092351.01365976.tanakasns@nttdata.co.jp> Message-ID: <20071011.102041.01366533.tanakasns@nttdata.co.jp> 田中です。 > utf8とEUC_JPが混在していて良くない感じですね。 > データはEUC_JPのままで使いたいので、全てをEUC_JPに統一して、 > もう一度やってみたいと思います。 mecab、mecabの辞書、senna、PostgreSQL、データを全てEUC_JPに統一したところ、 10万件以上スムーズに(1件の投入時間が1秒未満で)投入できるようになりました。 > それから、 > インデックス対象のテキストデータの総サイズは3万件程度では10GBは超えないと思います。 > 10万件くらいになると10GBは超える可能性があるので、 > データ投入がスムーズにできるようになり、10万件くらい投入できて、 > それっぽいエラーが出るようならば、initial_n_segmentsを変えて試してみたいと思います。 デフォルト設定(initial_n_segments=512)で実施したところ、15万件ほど投入し たところで下記のエラーが出ました。 LOG: pgsenna2: |A| malloc fail (132633168)=(nil) (inv.c:934) <605> ERROR: pgsenna2: sen_index_update failed そこで、initial_n_segments=2048、max_n_index_cache=64に設定して、 もう一度行ったところ、15万件ほど投入したところで、 突然、ルートファイルシステムが読み取り専用になってしまい、 投入するプロセスが異常終了するという結果になりました。 ログにはエラーは出ていませんでした。 使用したハードウェアは以下の通りなのですが、 メモリは2Gでは足らないのでしょうか？ > > > Dell Precision 470 > > > CPU: Xeon 2.8GHz × 2 > > > Memory: 2Gbyte > > > HDD: SATA 400Gbyte 7200rpm よろしくお願いします。 From sakamoto-t ＠ ma.dnes.nec.co.jp Thu Oct 11 19:04:44 2007 From: sakamoto-t ＠ ma.dnes.nec.co.jp (sakamoto) Date: Thu, 11 Oct 2007 19:04:44 +0900 Subject: [Ludia-users 109] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <00f601c80672$be8932c0$ae49440a@DNESsakata1> Message-ID: <018001c80bee$26160b40$ae49440a@DNESsakata1> こんにちは、坂本です。 加納さん、ありがとうございます。 > こんばんは　加納です。 > > > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 > > マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった > ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと > 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその > 構成は？この時間は単独で実行時でしょうか？ まず、マシン起動後の初回クエリが遅いです。 ヒット件数は、20万件です。（全体でも20万件ほどです） マシンの構成は、 OS：WindowsXP 　　　CPU：Core2 DUO 1.066GHz 　　　メモリ：1.5GB 　　　HDD：80GB 　　　ノートPCなのでHDDの回転数は遅いと思います。 　　　5400rpm or 4200rpm 単独実行です。 > > どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り > 立ちます。 > 　１ランダムIOに8msecとする。 > 　ヒット件数は1万件 > 　→IO時間は80000msec＝80sec > 　母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ > 　ては大きな時間が要することは想定されます。 > > > 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 > > 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ > に乗っている可能性がありますので、その場合は当然早くなります。 > 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい > るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 > しているものと思います。 sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ PostgreSQLを再起動後（マシン再起動ではない）も速いので、 PostgreSQLの共有バッファは関係ない？　とすればsennaかな？ とも思っています。その場合は、仮想メモリ？ 実際に運用する場面では、マシン起動後に、一度クエリを投げておく などで回避しなければならないのかと考えていますが、その場合、 どのようなクエリが効果的かなどと考えています。 また、フラッシュされない方法があるのなら、その方法も ご教授いただければと思います。 > > > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 > > これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ > きます。 > > > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 > > これも同様に共有バッファからフラッシュされてしまったので、再度実IO > が発生したと思われます。 > > このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる > と思います。 > http://www.postgresql.jp/document/pg824doc/html/monitoring-stats.html#MONITO > RING-STATS-VIEWS > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From morita ＠ razil.jp Fri Oct 12 03:14:16 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Fri, 12 Oct 2007 03:14:16 +0900 Subject: [Ludia-users 110] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: References: <20071010065502.GA3268@epepe.com> Message-ID: <20071011181416.GA2640@epepe.com> こんばんは。もりです。 > 以前FTPでPUTするようなやり取りがあったと思うのですが、そういったことは可能で > しょうか？ はい。現在も利用可能です。しかし‥ インデックスのうちファイルにマップされるはずである領域が2.2GB程度に達していますので、 未知の問題というわけではなく、実際に資源が足りなくなっている可能性が高いと思います。 (今回はmapsファイルを頂いてもあまり新しい知見は得られない気がします) /proc/pid/fdによると、8個のインデックスが同時に開かれているようですが、 実際に同時に使用する必要があるインデックスの数がこれより少ないようでしたら、 Ludia側の作りでもっとこまめにクローズして論理資源を節約できる可能性があるかもです。 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludiaな方々。 > > cat /proc/pid/status > Name: postmaster > State: S (sleeping) > SleepAVG: 98% > Tgid: 3839 > Pid: 3839 > PPid: 4180 > TracerPid: 0 > Uid: 26 26 26 26 > Gid: 26 26 26 26 > FDSize: 256 > Groups: 26 > VmPeak: 3144368 kB > VmSize: 3144368 kB > VmLck: 0 kB > VmHWM: 1968204 kB > VmRSS: 490748 kB > VmData: 28896 kB > VmStk: 88 kB > VmExe: 3072 kB > VmLib: 5420 kB > VmPTE: 5996 kB > StaBrk: 08394000 kB > Brk: 09e66000 kB > StaStk: bf8ecc80 kB > Threads: 1 > SigQ: 0/180352 > SigPnd: 0000000000000000 > ShdPnd: 0000000000000000 > SigBlk: 0000000000000000 > SigIgn: 0000000001301000 > SigCgt: 0000000000006a87 > CapInh: 0000000000000000 > CapPrm: 0000000000000000 > CapEff: 0000000000000000 > Cpus_allowed: ffffffff > Mems_allowed: 1 > > >/proc/pid/fd/ > 4008526.SEN.l 8462336 > 4008526.SEN.i 258674688 > 4008526.SEN.i.c 266240 > 4008528.SEN 8462336 > 4008528.SEN.l 8462336 > 4008528.SEN.i 269422592 > 4008528.SEN.i.c 1052672 > 4008538.SEN 8462336 > 4008538.SEN.l 8462336 > 4008538.SEN.i 266014720 > 4008538.SEN.i.c 266240 > 4008539.SEN 8462336 > 4008539.SEN.l 8462336 > 4008539.SEN.i 252907520 > 4008539.SEN.i.c 266240 > 4008511.SEN 8462336 > 4008511.SEN.l 8462336 > 4008511.SEN.i 268898304 > 4008511.SEN.i.c 266240 > 4008513.SEN 8462336 > 4008513.SEN.l 12656640 > 4008513.SEN.i 271519744 > 4008513.SEN.i.c 334761984 > 4008523.SEN 8462336 > 4008523.SEN.l 8462336 > 4008523.SEN.i 268898304 > 4008523.SEN.i.c 266240 > 4008524.SEN 8462336 > 4008524.SEN.l 8462336 > 4008524.SEN.i 268898304 > 4008524.SEN.i.c 266240 > 4008526.SEN 8462336 > > 以上、よろしくお願いいたします。 > > Tetsuo Kawanishi > > _________________________________________________________________ > Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウンロード > http://promotion.msn.co.jp/ie7/ > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > -- mori From kousakadi ＠ nttdata.co.jp Fri Oct 12 09:01:59 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Fri, 12 Oct 2007 09:01:59 +0900 Subject: [Ludia-users 111] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= References: <20071010065502.GA3268@epepe.com> <20071011181416.GA2640@epepe.com> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C38@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 確かにマップされている領域が過剰ですね。 > 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludiaな 方々。 max_n_index_cacheより多くのインデックスを開こうとすると、 LRU方式で最も使われていないインデックスを閉じる仕様となっています。 max_n_index_cacheのデフォルトは16です。 もしくは、initial_n_segmentsを小さくすると、 インデックスのマップされる領域が変更できます。 initial_n_segmentsの値はインデックスごとに設定できます。 initial_n_segmentsのデフォルトは512です。 *.SEN.l, *.SEN.i, *.SENの合計値が小さくなるように max_n_index_cacheとinitial_n_segmentsを調整してみてください。 (postgresql.confで変更できます。詳しくはREADME。) 以上です。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of morita ＠ razil.jp > Sent: Friday, October 12, 2007 3:14 AM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 110] Re:sen_index_upd failedについて > > こんばんは。もりです。 > > > 以前FTPでPUTするようなやり取りがあったと思うのですが、そういったことは可 能で > > しょうか？ > > はい。現在も利用可能です。しかし‥ > インデックスのうちファイルにマップされるはずである領域が2.2GB程度に達して いますので、 > 未知の問題というわけではなく、実際に資源が足りなくなっている可能性が高いと 思います。 > (今回はmapsファイルを頂いてもあまり新しい知見は得られない気がします) > > /proc/pid/fdによると、8個のインデックスが同時に開かれているようですが、 > 実際に同時に使用する必要があるインデックスの数がこれより少ないようでした ら、 > Ludia側の作りでもっとこまめにクローズして論理資源を節約できる可能性がある かもです。 > > 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludiaな 方々。 > > > > cat /proc/pid/status > > Name: postmaster > > State: S (sleeping) > > SleepAVG: 98% > > Tgid: 3839 > > Pid: 3839 > > PPid: 4180 > > TracerPid: 0 > > Uid: 26 26 26 26 > > Gid: 26 26 26 26 > > FDSize: 256 > > Groups: 26 > > VmPeak: 3144368 kB > > VmSize: 3144368 kB > > VmLck: 0 kB > > VmHWM: 1968204 kB > > VmRSS: 490748 kB > > VmData: 28896 kB > > VmStk: 88 kB > > VmExe: 3072 kB > > VmLib: 5420 kB > > VmPTE: 5996 kB > > StaBrk: 08394000 kB > > Brk: 09e66000 kB > > StaStk: bf8ecc80 kB > > Threads: 1 > > SigQ: 0/180352 > > SigPnd: 0000000000000000 > > ShdPnd: 0000000000000000 > > SigBlk: 0000000000000000 > > SigIgn: 0000000001301000 > > SigCgt: 0000000000006a87 > > CapInh: 0000000000000000 > > CapPrm: 0000000000000000 > > CapEff: 0000000000000000 > > Cpus_allowed: ffffffff > > Mems_allowed: 1 > > > > >/proc/pid/fd/ > > 4008526.SEN.l 8462336 > > 4008526.SEN.i 258674688 > > 4008526.SEN.i.c 266240 > > 4008528.SEN 8462336 > > 4008528.SEN.l 8462336 > > 4008528.SEN.i 269422592 > > 4008528.SEN.i.c 1052672 > > 4008538.SEN 8462336 > > 4008538.SEN.l 8462336 > > 4008538.SEN.i 266014720 > > 4008538.SEN.i.c 266240 > > 4008539.SEN 8462336 > > 4008539.SEN.l 8462336 > > 4008539.SEN.i 252907520 > > 4008539.SEN.i.c 266240 > > 4008511.SEN 8462336 > > 4008511.SEN.l 8462336 > > 4008511.SEN.i 268898304 > > 4008511.SEN.i.c 266240 > > 4008513.SEN 8462336 > > 4008513.SEN.l 12656640 > > 4008513.SEN.i 271519744 > > 4008513.SEN.i.c 334761984 > > 4008523.SEN 8462336 > > 4008523.SEN.l 8462336 > > 4008523.SEN.i 268898304 > > 4008523.SEN.i.c 266240 > > 4008524.SEN 8462336 > > 4008524.SEN.l 8462336 > > 4008524.SEN.i 268898304 > > 4008524.SEN.i.c 266240 > > 4008526.SEN 8462336 > > > > 以上、よろしくお願いいたします。 > > > > Tetsuo Kawanishi > > > > _________________________________________________________________ > > Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウン ロード > > http://promotion.msn.co.jp/ie7/ > > > > _______________________________________________ > > 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 kousakadi ＠ nttdata.co.jp Fri Oct 12 09:38:54 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Fri, 12 Oct 2007 09:38:54 +0900 Subject: [Ludia-users 112] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <018001c80bee$26160b40$ae49440a@DNESsakata1> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C39@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > まず、マシン起動後の初回クエリが遅いです。 > ヒット件数は、20万件です。（全体でも20万件ほどです） つまり、全件ヒットですね。 SELECT COUNT(*) FROM tab; と SELECT COUNT(*) FROM tab WHERE col @@ '??????'; が同じぐらいの時間でしたら、PostgreSQLが律速段階ですね。 Ludia, Sennaは関係ありません。 postgresql.confのshared_buffersなどを変更したり、 初回起動時にSELECT COUNT(*) FROM tab;でDBのデータを キャッシュに置けば解決できると思います。 後者が格段に遅いようでしたら、Ludia周りが原因です。 cat *.SEN.* > /dev/null などを初回起動前に実行しておけば、SennaのインデックスがOSの キャッシュに乗るので、高速になる可能性があります。 （上記のコマンドはLinuxの場合。Winではtype *.SEN.* > nul かな。） > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ PostgreSQLの共有バッファとは別です。 まずは、PostgreSQLとLudiaのどちらが原因なのか 問題の切り分けをする必要がありますね。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of sakamoto > Sent: Thursday, October 11, 2007 7:05 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 109] Re:一回目の検索が遅い件 > > こんにちは、坂本です。 > > 加納さん、ありがとうございます。 > > > こんばんは　加納です。 > > > > > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 > > > > マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった > > ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと > > 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその > > 構成は？この時間は単独で実行時でしょうか？ > > まず、マシン起動後の初回クエリが遅いです。 > ヒット件数は、20万件です。（全体でも20万件ほどです） > > マシンの構成は、 > OS：WindowsXP > 　　　CPU：Core2 DUO 1.066GHz > 　　　メモリ：1.5GB > 　　　HDD：80GB > 　　　ノートPCなのでHDDの回転数は遅いと思います。 > 　　　5400rpm or 4200rpm > > 単独実行です。 > > > > > どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り > > 立ちます。 > > 　１ランダムIOに8msecとする。 > > 　ヒット件数は1万件 > > 　→IO時間は80000msec＝80sec > > 　母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ > > 　ては大きな時間が要することは想定されます。 > > > > > 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 > > > > 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ > > に乗っている可能性がありますので、その場合は当然早くなります。 > > 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい > > るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 > > しているものと思います。 > > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ > PostgreSQLを再起動後（マシン再起動ではない）も速いので、 > PostgreSQLの共有バッファは関係ない？　とすればsennaかな？ > とも思っています。その場合は、仮想メモリ？ > > 実際に運用する場面では、マシン起動後に、一度クエリを投げておく > などで回避しなければならないのかと考えていますが、その場合、 > どのようなクエリが効果的かなどと考えています。 > > また、フラッシュされない方法があるのなら、その方法も > ご教授いただければと思います。 > > > > > > > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 > > > > これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ > > きます。 > > > > > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 > > > > これも同様に共有バッファからフラッシュされてしまったので、再度実IO > > が発生したと思われます。 > > > > このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる > > と思います。 > > > http://www.postgresql.jp/document/pg824doc/html/monitoring-sta > ts.html#MONITO > > RING-STATS-VIEWS > > > > _______________________________________________ > > 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 > From sakamoto-t ＠ ma.dnes.nec.co.jp Fri Oct 12 12:46:00 2007 From: sakamoto-t ＠ ma.dnes.nec.co.jp (sakamoto) Date: Fri, 12 Oct 2007 12:46:00 +0900 Subject: [Ludia-users 113] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <018001c80bee$26160b40$ae49440a@DNESsakata1> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C39@MAILSV11.msg.nttdata.co.jp> Message-ID: <044201c80c82$680a33c0$ae49440a@DNESsakata1> こんにちは、坂本です。 幸坂さん、ありがとうございます。 簡単に確認しましたので、ご報告します。 > 幸坂です。こんにちは。 > > > まず、マシン起動後の初回クエリが遅いです。 > > ヒット件数は、20万件です。（全体でも20万件ほどです） > つまり、全件ヒットですね。 > SELECT COUNT(*) FROM tab; →（SQL1)とします > と > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; →（SQL2)とします [ケース１] マシン起動→SQL1→SQL2 SQL1,SQL2共に遅い。 [ケース２] マシン起動→SQL2→SQL1 SQL2は遅いが、SQL1は速い SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 とすれば、PostgreSQLもsennaもどちらも影響の原因になると いうことでしょうか。 > が同じぐらいの時間でしたら、PostgreSQLが律速段階ですね。 > Ludia, Sennaは関係ありません。 > postgresql.confのshared_buffersなどを変更したり、 > 初回起動時にSELECT COUNT(*) FROM tab;でDBのデータを > キャッシュに置けば解決できると思います。 > > 後者が格段に遅いようでしたら、Ludia周りが原因です。 > cat *.SEN.* > /dev/null > などを初回起動前に実行しておけば、SennaのインデックスがOSの > キャッシュに乗るので、高速になる可能性があります。 > （上記のコマンドはLinuxの場合。Winではtype *.SEN.* > nul かな。） type *.SEN.* > nul を実行しても、結果的には変わりませんでした。 うまくOSのキャッシュに乗らないのか、乗ってもそれを使ってくれないのか？ > > > > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ > PostgreSQLの共有バッファとは別です。 > まずは、PostgreSQLとLudiaのどちらが原因なのか > 問題の切り分けをする必要がありますね。 > > > -----Original Message----- > > From: ludia-users-bounces ＠ lists.sourceforge.jp > > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > > Of sakamoto > > Sent: Thursday, October 11, 2007 7:05 PM > > To: ludia-users ＠ lists.sourceforge.jp > > Subject: [Ludia-users 109] Re:一回目の検索が遅い件 > > > > こんにちは、坂本です。 > > > > 加納さん、ありがとうございます。 > > > > > こんばんは　加納です。 > > > > > > > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 > > > > > > マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった > > > ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと > > > 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその > > > 構成は？この時間は単独で実行時でしょうか？ > > > > まず、マシン起動後の初回クエリが遅いです。 > > ヒット件数は、20万件です。（全体でも20万件ほどです） > > > > マシンの構成は、 > > OS：WindowsXP > > 　　　CPU：Core2 DUO 1.066GHz > > 　　　メモリ：1.5GB > > 　　　HDD：80GB > > 　　　ノートPCなのでHDDの回転数は遅いと思います。 > > 　　　5400rpm or 4200rpm > > > > 単独実行です。 > > > > > > > > どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り > > > 立ちます。 > > > 　１ランダムIOに8msecとする。 > > > 　ヒット件数は1万件 > > > 　→IO時間は80000msec＝80sec > > > 　母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ > > > 　ては大きな時間が要することは想定されます。 > > > > > > > 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 > > > > > > 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ > > > に乗っている可能性がありますので、その場合は当然早くなります。 > > > 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい > > > るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 > > > しているものと思います。 > > > > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ > > PostgreSQLを再起動後（マシン再起動ではない）も速いので、 > > PostgreSQLの共有バッファは関係ない？　とすればsennaかな？ > > とも思っています。その場合は、仮想メモリ？ > > > > 実際に運用する場面では、マシン起動後に、一度クエリを投げておく > > などで回避しなければならないのかと考えていますが、その場合、 > > どのようなクエリが効果的かなどと考えています。 > > > > また、フラッシュされない方法があるのなら、その方法も > > ご教授いただければと思います。 > > > > > > > > > > > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 > > > > > > これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ > > > きます。 > > > > > > > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 > > > > > > これも同様に共有バッファからフラッシュされてしまったので、再度実IO > > > が発生したと思われます。 > > > > > > このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる > > > と思います。 > > > > > http://www.postgresql.jp/document/pg824doc/html/monitoring-sta > > ts.html#MONITO > > > RING-STATS-VIEWS > > > > > > _______________________________________________ > > > 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 From kousakadi ＠ nttdata.co.jp Fri Oct 12 15:46:52 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Fri, 12 Oct 2007 15:46:52 +0900 Subject: [Ludia-users 114] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <018001c80bee$26160b40$ae49440a@DNESsakata1><178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C39@MAILSV11.msg.nttdata.co.jp> <044201c80c82$680a33c0$ae49440a@DNESsakata1> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C3C@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > いうことでしょうか。 そうですね。 > type *.SEN.* > nul > を実行しても、結果的には変わりませんでした。 > うまくOSのキャッシュに乗らないのか、乗ってもそれを使ってくれないのか？ Sennaのインデックスファイルの容量はどのぐらいですか？ 合計でOSのキャッシュを超えていませんか？ *.SEN.i.cはキャッシュに乗せてもあまり効果がありません。 それ以外をキャッシュに乗せると効果が出ます。 こちらの環境では、*.SEN.i.c以外をキャッシュに乗せ、 さらにSELECT COUNT(*) FROM tab;を実施しておけば、 初回検索時であっても、十分高速な検索になりました。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of sakamoto > Sent: Friday, October 12, 2007 12:46 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 113] Re:一回目の検索が遅い件 > > こんにちは、坂本です。 > > 幸坂さん、ありがとうございます。 > > 簡単に確認しましたので、ご報告します。 > > > 幸坂です。こんにちは。 > > > > > まず、マシン起動後の初回クエリが遅いです。 > > > ヒット件数は、20万件です。（全体でも20万件ほどです） > > つまり、全件ヒットですね。 > > SELECT COUNT(*) FROM tab; > →（SQL1)とします > > > と > > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; > →（SQL2)とします > > [ケース１] マシン起動→SQL1→SQL2 > SQL1,SQL2共に遅い。 > > [ケース２] マシン起動→SQL2→SQL1 > SQL2は遅いが、SQL1は速い > > SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > いうことでしょうか。 > > > が同じぐらいの時間でしたら、PostgreSQLが律速段階ですね。 > > Ludia, Sennaは関係ありません。 > > postgresql.confのshared_buffersなどを変更したり、 > > 初回起動時にSELECT COUNT(*) FROM tab;でDBのデータを > > キャッシュに置けば解決できると思います。 > > > > 後者が格段に遅いようでしたら、Ludia周りが原因です。 > > cat *.SEN.* > /dev/null > > などを初回起動前に実行しておけば、SennaのインデックスがOSの > > キャッシュに乗るので、高速になる可能性があります。 > > （上記のコマンドはLinuxの場合。Winではtype *.SEN.* > nul かな。） > > type *.SEN.* > nul > を実行しても、結果的には変わりませんでした。 > うまくOSのキャッシュに乗らないのか、乗ってもそれを使ってくれないのか？ > > > > > > > > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ > > PostgreSQLの共有バッファとは別です。 > > まずは、PostgreSQLとLudiaのどちらが原因なのか > > 問題の切り分けをする必要がありますね。 > > > > > -----Original Message----- > > > From: ludia-users-bounces ＠ lists.sourceforge.jp > > > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > > > Of sakamoto > > > Sent: Thursday, October 11, 2007 7:05 PM > > > To: ludia-users ＠ lists.sourceforge.jp > > > Subject: [Ludia-users 109] Re:一回目の検索が遅い件 > > > > > > こんにちは、坂本です。 > > > > > > 加納さん、ありがとうございます。 > > > > > > > こんばんは　加納です。 > > > > > > > > > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 > > > > > > > > マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった > > > > ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと > > > > 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその > > > > 構成は？この時間は単独で実行時でしょうか？ > > > > > > まず、マシン起動後の初回クエリが遅いです。 > > > ヒット件数は、20万件です。（全体でも20万件ほどです） > > > > > > マシンの構成は、 > > > OS：WindowsXP > > > 　　　CPU：Core2 DUO 1.066GHz > > > 　　　メモリ：1.5GB > > > 　　　HDD：80GB > > > 　　　ノートPCなのでHDDの回転数は遅いと思います。 > > > 　　　5400rpm or 4200rpm > > > > > > 単独実行です。 > > > > > > > > > > > どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り > > > > 立ちます。 > > > > 　１ランダムIOに8msecとする。 > > > > 　ヒット件数は1万件 > > > > 　→IO時間は80000msec＝80sec > > > > 　母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ > > > > 　ては大きな時間が要することは想定されます。 > > > > > > > > > 　二回目以降の検索は、9秒程度と一回目が極端に遅い。 > > > > > > > > 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ > > > > に乗っている可能性がありますので、その場合は当然早くなります。 > > > > 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい > > > > るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 > > > > しているものと思います。 > > > > > > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ > > > PostgreSQLを再起動後（マシン再起動ではない）も速いので、 > > > PostgreSQLの共有バッファは関係ない？　とすればsennaかな？ > > > とも思っています。その場合は、仮想メモリ？ > > > > > > 実際に運用する場面では、マシン起動後に、一度クエリを投げておく > > > などで回避しなければならないのかと考えていますが、その場合、 > > > どのようなクエリが効果的かなどと考えています。 > > > > > > また、フラッシュされない方法があるのなら、その方法も > > > ご教授いただければと思います。 > > > > > > > > > > > > > > > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 > > > > > > > > これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ > > > > きます。 > > > > > > > > > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 > > > > > > > > これも同様に共有バッファからフラッシュされてしまったので、再度実IO > > > > が発生したと思われます。 > > > > > > > > このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる > > > > と思います。 > > > > > > > http://www.postgresql.jp/document/pg824doc/html/monitoring-sta > > > ts.html#MONITO > > > > RING-STATS-VIEWS > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From t_kawanishi ＠ hotmail.co.jp Sun Oct 14 20:56:32 2007 From: t_kawanishi ＠ hotmail.co.jp (Kawanishi Tetsuo) Date: Sun, 14 Oct 2007 20:56:32 +0900 Subject: [Ludia-users 115] =?iso-2022-jp?b?IFJFOiAgUmU6CXNlbl9pbmRleF91cGQgZmFpbGVk?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C38@MAILSV11.msg.nttdata.co.jp> References: <20071010065502.GA3268@epepe.com> <20071011181416.GA2640@epepe.com> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C38@MAILSV11.msg.nttdata.co.jp> Message-ID: 川西です。こんばんは。 ご解説、ありがとうございます。 過去に何度か出ていた内容だったようで申し訳ありません。 sennaを1.0.9にバージョンアップしたところmmapのエラーが出た後も、 deadlock状態に陥らないようになりました。 initial_n_segmentsを1024に設定していたことで、 インデックスのサイズが肥大化していたようです。 initial_n_segmentsの値を512に戻したところ、 INSERTできる件数も増え、だいぶ改善してきました。 max_n_index_cacheの値がデフォルトの16なので、 この値を多少減らせば解決となりそうです。 > initial_n_segmentsの値はインデックスごとに設定できます。 > initial_n_segmentsのデフォルトは512です。 インデックスごとにinitial_n_segmentsの値を設定する場合は、 postgres.confの設定値を書き換えてからインデックスを作成するという 手順でしょうか？他にもっと簡単な方法があるのでしょうか？ > *.SEN.l, *.SEN.i, *.SENの合計値が小さくなるように > max_n_index_cacheとinitial_n_segmentsを調整してみてください。 *.SEN.l, *.SEN.i, *.SENの合計値が論理メモリにマップされ、 *.SEN.i についてはデフォルト130MB程度確保され、 登録する文書量によって肥大化していく、といった認識で 間違っていませんでしょうか？ 資源不足に陥らないよう、少し余裕を持った設定値にした方が 良さそうですね。 以上、よろしくお願いいたします。 Tetsuo Kawanishi > Date: Fri, 12 Oct 2007 09:01:59 +0900 > From: kousakadi ＠ nttdata.co.jp > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 111] Re: sen_index_upd failedについて > > 幸坂です。こんにちは。 > > 確かにマップされている領域が過剰ですね。 > >> 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludiaな > 方々。 > max_n_index_cacheより多くのインデックスを開こうとすると、 > LRU方式で最も使われていないインデックスを閉じる仕様となっています。 > max_n_index_cacheのデフォルトは16です。 > > もしくは、initial_n_segmentsを小さくすると、 > インデックスのマップされる領域が変更できます。 > initial_n_segmentsの値はインデックスごとに設定できます。 > initial_n_segmentsのデフォルトは512です。 > > *.SEN.l, *.SEN.i, *.SENの合計値が小さくなるように > max_n_index_cacheとinitial_n_segmentsを調整してみてください。 > (postgresql.confで変更できます。詳しくはREADME。) > > 以上です。 > >> -----Original Message----- >> From: ludia-users-bounces ＠ lists.sourceforge.jp >> [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf >> Of morita ＠ razil.jp >> Sent: Friday, October 12, 2007 3:14 AM >> To: ludia-users ＠ lists.sourceforge.jp >> Subject: [Ludia-users 110] Re:sen_index_upd failedについて >> >> こんばんは。もりです。 >> >>> 以前FTPでPUTするようなやり取りがあったと思うのですが、そういったことは可 > 能で >>> しょうか？ >> >> はい。現在も利用可能です。しかし‥ >> インデックスのうちファイルにマップされるはずである領域が2.2GB程度に達して > いますので、 >> 未知の問題というわけではなく、実際に資源が足りなくなっている可能性が高いと > 思います。 >> (今回はmapsファイルを頂いてもあまり新しい知見は得られない気がします) >> >> /proc/pid/fdによると、8個のインデックスが同時に開かれているようですが、 >> 実際に同時に使用する必要があるインデックスの数がこれより少ないようでした > ら、 >> Ludia側の作りでもっとこまめにクローズして論理資源を節約できる可能性がある > かもです。 >> >> 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludiaな > 方々。 >> >>>> cat /proc/pid/status >>> Name: postmaster >>> State: S (sleeping) >>> SleepAVG: 98% >>> Tgid: 3839 >>> Pid: 3839 >>> PPid: 4180 >>> TracerPid: 0 >>> Uid: 26 26 26 26 >>> Gid: 26 26 26 26 >>> FDSize: 256 >>> Groups: 26 >>> VmPeak: 3144368 kB >>> VmSize: 3144368 kB >>> VmLck: 0 kB >>> VmHWM: 1968204 kB >>> VmRSS: 490748 kB >>> VmData: 28896 kB >>> VmStk: 88 kB >>> VmExe: 3072 kB >>> VmLib: 5420 kB >>> VmPTE: 5996 kB >>> StaBrk: 08394000 kB >>> Brk: 09e66000 kB >>> StaStk: bf8ecc80 kB >>> Threads: 1 >>> SigQ: 0/180352 >>> SigPnd: 0000000000000000 >>> ShdPnd: 0000000000000000 >>> SigBlk: 0000000000000000 >>> SigIgn: 0000000001301000 >>> SigCgt: 0000000000006a87 >>> CapInh: 0000000000000000 >>> CapPrm: 0000000000000000 >>> CapEff: 0000000000000000 >>> Cpus_allowed: ffffffff >>> Mems_allowed: 1 >>> >>>>/proc/pid/fd/ >>> 4008526.SEN.l 8462336 >>> 4008526.SEN.i 258674688 >>> 4008526.SEN.i.c 266240 >>> 4008528.SEN 8462336 >>> 4008528.SEN.l 8462336 >>> 4008528.SEN.i 269422592 >>> 4008528.SEN.i.c 1052672 >>> 4008538.SEN 8462336 >>> 4008538.SEN.l 8462336 >>> 4008538.SEN.i 266014720 >>> 4008538.SEN.i.c 266240 >>> 4008539.SEN 8462336 >>> 4008539.SEN.l 8462336 >>> 4008539.SEN.i 252907520 >>> 4008539.SEN.i.c 266240 >>> 4008511.SEN 8462336 >>> 4008511.SEN.l 8462336 >>> 4008511.SEN.i 268898304 >>> 4008511.SEN.i.c 266240 >>> 4008513.SEN 8462336 >>> 4008513.SEN.l 12656640 >>> 4008513.SEN.i 271519744 >>> 4008513.SEN.i.c 334761984 >>> 4008523.SEN 8462336 >>> 4008523.SEN.l 8462336 >>> 4008523.SEN.i 268898304 >>> 4008523.SEN.i.c 266240 >>> 4008524.SEN 8462336 >>> 4008524.SEN.l 8462336 >>> 4008524.SEN.i 268898304 >>> 4008524.SEN.i.c 266240 >>> 4008526.SEN 8462336 >>> >>> 以上、よろしくお願いいたします。 >>> >>> Tetsuo Kawanishi >>> >>> _________________________________________________________________ >>> Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウン > ロード >>> http://promotion.msn.co.jp/ie7/ >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users _________________________________________________________________ 【MSNビデオ】超貴重！驚きの大物対談が実現。作家 村上龍が話題のあの人に迫る http://video.msn.co.jp/rvr/default.htm From kousakadi ＠ nttdata.co.jp Mon Oct 15 17:15:43 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Mon, 15 Oct 2007 17:15:43 +0900 Subject: [Ludia-users 116] Re: =?iso-2022-jp?b?c2VuX2luZGV4X3VwZCBmYWlsZWQbJEIkSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= References: <20071010065502.GA3268@epepe.com><20071011181416.GA2640@epepe.com> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C38@MAILSV11.msg.nttdata.co.jp> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C48@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > 手順でしょうか？他にもっと簡単な方法があるのでしょうか？ SET ludia.initial_n_segments TO 512; このように、セッションごとに設定できます。 詳細はREADMEをお読みください。 http://ludia.sourceforge.jp/cgi-bin/moin.cgi/LudiaReadme http://ludia.sourceforge.jp/cgi-bin/moin.cgi/LudiaReadmeAdvanced > 登録する文書量によって肥大化していく、といった認識で > 間違っていませんでしょうか？ *.SEN.i はある程度以上、肥大化しません。 上限はinitial_n_segmentsによって決定されます。 *.SEN.i に入りきらない肥大化部分は *.SEN.i.c に格納されます。 *.SEN と *.SEN.l は少しずつ肥大化し続けます。 ちなみに、Linux版の*.SEN.i のデフォルト値（初期値）は、 Windows版と比較して２桁ぐらい小さいです。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of Kawanishi Tetsuo > Sent: Sunday, October 14, 2007 8:57 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 115] RE: Re: sen_index_upd failedについて > > > 川西です。こんばんは。 > > ご解説、ありがとうございます。 > 過去に何度か出ていた内容だったようで申し訳ありません。 > > sennaを1.0.9にバージョンアップしたところmmapのエラーが出た後も、 > deadlock状態に陥らないようになりました。 > > initial_n_segmentsを1024に設定していたことで、 > インデックスのサイズが肥大化していたようです。 > initial_n_segmentsの値を512に戻したところ、 > INSERTできる件数も増え、だいぶ改善してきました。 > max_n_index_cacheの値がデフォルトの16なので、 > この値を多少減らせば解決となりそうです。 > > > initial_n_segmentsの値はインデックスごとに設定できます。 > > initial_n_segmentsのデフォルトは512です。 > > インデックスごとにinitial_n_segmentsの値を設定する場合は、 > postgres.confの設定値を書き換えてからインデックスを作成するという > 手順でしょうか？他にもっと簡単な方法があるのでしょうか？ > > > *.SEN.l, *.SEN.i, *.SENの合計値が小さくなるように > > max_n_index_cacheとinitial_n_segmentsを調整してみてください。 > > *.SEN.l, *.SEN.i, *.SENの合計値が論理メモリにマップされ、 > *.SEN.i についてはデフォルト130MB程度確保され、 > 登録する文書量によって肥大化していく、といった認識で > 間違っていませんでしょうか？ > > 資源不足に陥らないよう、少し余裕を持った設定値にした方が > 良さそうですね。 > > 以上、よろしくお願いいたします。 > > Tetsuo Kawanishi > > > Date: Fri, 12 Oct 2007 09:01:59 +0900 > > From: kousakadi ＠ nttdata.co.jp > > To: ludia-users ＠ lists.sourceforge.jp > > Subject: [Ludia-users 111] Re: sen_index_upd failedについて > > > > 幸坂です。こんにちは。 > > > > 確かにマップされている領域が過剰ですね。 > > > >> 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludia な > > 方々。 > > max_n_index_cacheより多くのインデックスを開こうとすると、 > > LRU方式で最も使われていないインデックスを閉じる仕様となっています。 > > max_n_index_cacheのデフォルトは16です。 > > > > もしくは、initial_n_segmentsを小さくすると、 > > インデックスのマップされる領域が変更できます。 > > initial_n_segmentsの値はインデックスごとに設定できます。 > > initial_n_segmentsのデフォルトは512です。 > > > > *.SEN.l, *.SEN.i, *.SENの合計値が小さくなるように > > max_n_index_cacheとinitial_n_segmentsを調整してみてください。 > > (postgresql.confで変更できます。詳しくはREADME。) > > > > 以上です。 > > > >> -----Original Message----- > >> From: ludia-users-bounces ＠ lists.sourceforge.jp > >> [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > >> Of morita ＠ razil.jp > >> Sent: Friday, October 12, 2007 3:14 AM > >> To: ludia-users ＠ lists.sourceforge.jp > >> Subject: [Ludia-users 110] Re:sen_index_upd failedについて > >> > >> こんばんは。もりです。 > >> > >>> 以前FTPでPUTするようなやり取りがあったと思うのですが、そういったことは 可 > > 能で > >>> しょうか？ > >> > >> はい。現在も利用可能です。しかし‥ > >> インデックスのうちファイルにマップされるはずである領域が2.2GB程度に達し て > > いますので、 > >> 未知の問題というわけではなく、実際に資源が足りなくなっている可能性が高 いと > > 思います。 > >> (今回はmapsファイルを頂いてもあまり新しい知見は得られない気がします) > >> > >> /proc/pid/fdによると、8個のインデックスが同時に開かれているようですが、 > >> 実際に同時に使用する必要があるインデックスの数がこれより少ないようでし た > > ら、 > >> Ludia側の作りでもっとこまめにクローズして論理資源を節約できる可能性があ る > > かもです。 > >> > >> 最近のLudiaはindex_cacheの挙動ってどうなっているのでしたっけ? → Ludia な > > 方々。 > >> > >>>> cat /proc/pid/status > >>> Name: postmaster > >>> State: S (sleeping) > >>> SleepAVG: 98% > >>> Tgid: 3839 > >>> Pid: 3839 > >>> PPid: 4180 > >>> TracerPid: 0 > >>> Uid: 26 26 26 26 > >>> Gid: 26 26 26 26 > >>> FDSize: 256 > >>> Groups: 26 > >>> VmPeak: 3144368 kB > >>> VmSize: 3144368 kB > >>> VmLck: 0 kB > >>> VmHWM: 1968204 kB > >>> VmRSS: 490748 kB > >>> VmData: 28896 kB > >>> VmStk: 88 kB > >>> VmExe: 3072 kB > >>> VmLib: 5420 kB > >>> VmPTE: 5996 kB > >>> StaBrk: 08394000 kB > >>> Brk: 09e66000 kB > >>> StaStk: bf8ecc80 kB > >>> Threads: 1 > >>> SigQ: 0/180352 > >>> SigPnd: 0000000000000000 > >>> ShdPnd: 0000000000000000 > >>> SigBlk: 0000000000000000 > >>> SigIgn: 0000000001301000 > >>> SigCgt: 0000000000006a87 > >>> CapInh: 0000000000000000 > >>> CapPrm: 0000000000000000 > >>> CapEff: 0000000000000000 > >>> Cpus_allowed: ffffffff > >>> Mems_allowed: 1 > >>> > >>>>/proc/pid/fd/ > >>> 4008526.SEN.l 8462336 > >>> 4008526.SEN.i 258674688 > >>> 4008526.SEN.i.c 266240 > >>> 4008528.SEN 8462336 > >>> 4008528.SEN.l 8462336 > >>> 4008528.SEN.i 269422592 > >>> 4008528.SEN.i.c 1052672 > >>> 4008538.SEN 8462336 > >>> 4008538.SEN.l 8462336 > >>> 4008538.SEN.i 266014720 > >>> 4008538.SEN.i.c 266240 > >>> 4008539.SEN 8462336 > >>> 4008539.SEN.l 8462336 > >>> 4008539.SEN.i 252907520 > >>> 4008539.SEN.i.c 266240 > >>> 4008511.SEN 8462336 > >>> 4008511.SEN.l 8462336 > >>> 4008511.SEN.i 268898304 > >>> 4008511.SEN.i.c 266240 > >>> 4008513.SEN 8462336 > >>> 4008513.SEN.l 12656640 > >>> 4008513.SEN.i 271519744 > >>> 4008513.SEN.i.c 334761984 > >>> 4008523.SEN 8462336 > >>> 4008523.SEN.l 8462336 > >>> 4008523.SEN.i 268898304 > >>> 4008523.SEN.i.c 266240 > >>> 4008524.SEN 8462336 > >>> 4008524.SEN.l 8462336 > >>> 4008524.SEN.i 268898304 > >>> 4008524.SEN.i.c 266240 > >>> 4008526.SEN 8462336 > >>> > >>> 以上、よろしくお願いいたします。 > >>> > >>> Tetsuo Kawanishi > >>> > >>> _________________________________________________________________ > >>> Webページを見ながらスムーズ検索「サーチペイン」搭載のMSN版IE7をダウン > > ロード > >>> http://promotion.msn.co.jp/ie7/ > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _________________________________________________________________ > 【MSNビデオ】超貴重！驚きの大物対談が実現。作家 村上龍が話題のあの人に迫る > http://video.msn.co.jp/rvr/default.htm > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From kanout ＠ nttdata.co.jp Mon Oct 15 17:57:30 2007 From: kanout ＠ nttdata.co.jp (Toshihiro Kano) Date: Mon, 15 Oct 2007 17:57:30 +0900 Subject: [Ludia-users 117] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= In-Reply-To: <044201c80c82$680a33c0$ae49440a@DNESsakata1> References: <018001c80bee$26160b40$ae49440a@DNESsakata1> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C39@MAILSV11.msg.nttdata.co.jp> <044201c80c82$680a33c0$ae49440a@DNESsakata1> Message-ID: <47132B7A.8020705@nttdata.co.jp> こんばんは、加納です。 幸坂からの回答とは別に・・・ > > SELECT COUNT(*) FROM tab; > →（SQL1)とします > > > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; > →（SQL2)とします > > [ケース１] マシン起動→SQL1→SQL2 > SQL1,SQL2共に遅い。 > > [ケース２] マシン起動→SQL2→SQL1 > SQL2は遅いが、SQL1は速い > > SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > いうことでしょうか。 SQL1のパターンも、PostgreSQLのテーブル部を参照します。 もし、COUNT(*)はインデックススキャンだという認識でのお 話であれば、それはPostgreSQLには当てはまりません。 PostgreSQLはインデックスも追記型のため、データ部を参照 しないと確実にその行が生きていることを保証できないため です。（インデックスに無効フラグはあるが、無効フラグが オフだからといって、有効とは限らない） SQL1では、プランを確認しないとなんともいえませんが、 テーブルスキャンの可能性があります。その場合、シーケン シャルアクセスです。 SQL2では、インデックス経由のアクセスですので、テーブル はランダムアクセスです。SQL1<470B49C2.6080205@razil.jp><20071010.092351.01365976.tanakasns@nttdata.co.jp> <20071011.102041.01366533.tanakasns@nttdata.co.jp> Message-ID: 岩崎です。 > デフォルト設定(initial_n_segments=512)で実施したところ、15万件ほど投入し > たところで下記のエラーが出ました。 > > LOG: pgsenna2: |A| malloc fail (132633168)=(nil) (inv.c:934) <605> > ERROR: pgsenna2: sen_index_update failed 返信が遅くなってすみません。 もしかすると、 バージョン1.3のマルチカラムインデックス対応で改変した部分が 関係しているかもしれません。 可能であれば、 一度ludia-1.2.0を使って試してみていただけないでしょうか。 > そこで、initial_n_segments=2048、max_n_index_cache=64に設定して、 > もう一度行ったところ、15万件ほど投入したところで、 > 突然、ルートファイルシステムが読み取り専用になってしまい、 > 投入するプロセスが異常終了するという結果になりました。 もしテストする過程で不要になったインデックスファイルが ディスクにたまってしまっている場合、 psql等で不要なインデックスをDROPしたあと、 以下の要領でクリーンアップしてみてください。 # SELECT pgs2destroy(); よろしくおねがいします。 -----Original Message----- From: ludia-users-bounces ＠ lists.sourceforge.jp [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of Shunsuke Tanaka Sent: Thursday, October 11, 2007 10:21 AM To: ludia-users ＠ lists.sourceforge.jp Subject: [Ludia-users 108] Re: 形態素インデックスで投入に1秒以上かかります 田中です。 > utf8とEUC_JPが混在していて良くない感じですね。 > データはEUC_JPのままで使いたいので、全てをEUC_JPに統一して、 > もう一度やってみたいと思います。 mecab、mecabの辞書、senna、PostgreSQL、データを全てEUC_JPに統一したところ、 10万件以上スムーズに(1件の投入時間が1秒未満で)投入できるようになりました。 > それから、 > インデックス対象のテキストデータの総サイズは3万件程度では10GBは超えないと 思います。 > 10万件くらいになると10GBは超える可能性があるので、 > データ投入がスムーズにできるようになり、10万件くらい投入できて、 > それっぽいエラーが出るようならば、initial_n_segmentsを変えて試してみたいと 思います。 デフォルト設定(initial_n_segments=512)で実施したところ、15万件ほど投入し たところで下記のエラーが出ました。 LOG: pgsenna2: |A| malloc fail (132633168)=(nil) (inv.c:934) <605> ERROR: pgsenna2: sen_index_update failed そこで、initial_n_segments=2048、max_n_index_cache=64に設定して、 もう一度行ったところ、15万件ほど投入したところで、 突然、ルートファイルシステムが読み取り専用になってしまい、 投入するプロセスが異常終了するという結果になりました。 ログにはエラーは出ていませんでした。 使用したハードウェアは以下の通りなのですが、 メモリは2Gでは足らないのでしょうか？ > > > Dell Precision 470 > > > CPU: Xeon 2.8GHz × 2 > > > Memory: 2Gbyte > > > HDD: SATA 400Gbyte 7200rpm よろしくお願いします。 _______________________________________________ Ludia-users mailing list Ludia-users ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/ludia-users From tanakasns ＠ nttdata.co.jp Thu Oct 18 14:36:05 2007 From: tanakasns ＠ nttdata.co.jp (Shunsuke Tanaka) Date: Thu, 18 Oct 2007 14:36:05 +0900 (LDT) Subject: [Ludia-users 119] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: References: <20071010.092351.01365976.tanakasns@nttdata.co.jp> <20071011.102041.01366533.tanakasns@nttdata.co.jp> Message-ID: <20071018.143605.01365955.tanakasns@nttdata.co.jp> 田中です。 返信ありがとうございます。 > > デフォルト設定(initial_n_segments=512)で実施したところ、15万件ほど投入し > > たところで下記のエラーが出ました。 > > > > LOG: pgsenna2: |A| malloc fail (132633168)=(nil) (inv.c:934) <605> > > ERROR: pgsenna2: sen_index_update failed > > 返信が遅くなってすみません。 > もしかすると、 > バージョン1.3のマルチカラムインデックス対応で改変した部分が > 関係しているかもしれません。 > > 可能であれば、 > 一度ludia-1.2.0を使って試してみていただけないでしょうか。 ludia-1.2.0で試してみましたが、同じように、15万件ほど投入したところで 下記のエラーが出て投入ができなくなりました。 ※エラーが出て投入できなくなった件数は完全に同じではなく、 数千件程度の差があります。 LOG: pgsenna2: |A| malloc fail (139096976)=(nil) (inv.c:934) <12770> ERROR: pgsenna2: sen_index_upd failed while do_insert (1) なお、他のソフトウェアのバージョンは以下の通りです。 Senna 1.0.9 mecab 0.96 mecab-ipadic 2.7.0 20070801 PostgreSQL 8.2.4 > > そこで、initial_n_segments=2048、max_n_index_cache=64に設定して、 > > もう一度行ったところ、15万件ほど投入したところで、 > > 突然、ルートファイルシステムが読み取り専用になってしまい、 > > 投入するプロセスが異常終了するという結果になりました。 > > もしテストする過程で不要になったインデックスファイルが > ディスクにたまってしまっている場合、 > psql等で不要なインデックスをDROPしたあと、 > 以下の要領でクリーンアップしてみてください。 > > # SELECT pgs2destroy(); 1つのテストを終えたら、データベースクラスタを破棄して、 次のテストではデータベースクラスタを新しく作り直して行っています。 テスト時に不要になったインデックスファイルはないと思いますので、 クリーンアップの必要もないと思いますが。 PostgreSQLのデータベースクラスタの領域以外にファイルが作られることは あるのでしょうか？ よろしくお願いします。 From t_kawanishi ＠ hotmail.co.jp Tue Oct 23 11:06:24 2007 From: t_kawanishi ＠ hotmail.co.jp (Kawanishi Tetsuo) Date: Tue, 23 Oct 2007 11:06:24 +0900 Subject: [Ludia-users 120] =?iso-2022-jp?b?IBskQkZDRGokTj5yN28kRxsoQkRCGyRCQFxCMyQsNi8bKEI=?= =?iso-2022-jp?b?GyRCQCk9Kk47JDUkbCRGJDckXiQkJF4kORsoQg==?= Message-ID: こんにちは。川西です。 年ごとに分割したテーブルと、senna/ludiaを組み合わせを、 下記のようなテーブル構成で利用しています。 dataという親テーブルを継承した、 子テーブル(data_2006, data_2007, ..)があります。 data(親) - ・ - data_2005(子) - data_2006(子) - data_2007(子) - ・ - ・ 日付（分割のルールとなっている条件)を指定せず検索した場合、 DBとの接続が切れるのですが、日付を指定した場合にも 全文検索を行うと接続が切れることがありました。 sennaのインデックスを持つカラムは3つあり、いずれかのカラムに対して、 全文検索を行った場合、DBとの接続が強制終了されていました。 ※ 3つのカラムはfulltext1,fulltext2,fulltext3とします。 ●現象の発生条件 　以下の3つをすべて満たす場合です。 　A. Senna/Ludiaの全文検索を使用する場合 　B. 分割テーブルの親テーブルより検索(SELECT * FROM data) 　C. WHERE句にて日付の条件を全文検索の条件より後につけた場合 ●具体的なクエリの例 1. DB接続が切れてしまうクエリの例 SELECT * FROM data WHERE fulltext1 @@ '*D+ "テスト"' AND date between '2006-09-01' AND '2007-09-01'; 2. 正常に結果が得られるクエリの例 A. WHEREにて日付を全文検索の条件より前につける SELECT * FROM data WHERE date between '2006-09-01' AND '2007-09-01' AND fulltext1 @@ '*D+ "テスト"'; B. 分割テーブルの子テーブル(data_2007)を指定 SELECT * FROM data_2007 as r WHERE fulltext1 @@ '*D+ "テスト"' AND date between '2006-09-01' AND '2007-09-01'; C. Senna/Ludiaの全文検索ではなく"LIKE"を使用 SELECT * FROM data WHERE fulltext1 LIKE '%テスト%' AND date between '2006-09-01' AND '2007-09-01'; ●DB接続が切れてしまった際のメッセージ WARNING: terminating connection because of crash of another server process ●対応策として試してみたこと 1. Ludia 1.3.0へのバージョンアップ 試してみたところ、fulltext1,fulltext2の全文検索は正常に行えました。 fulltext3の全文検索を行ったところ、下記のエラーが出力されました。 "ERROR: pgsenna2: sen_query_scan failed (1)" このエラーメッセージから、以下のblog記事に辿り着きました。 http://mt.endeworks.jp/d-6/2007/10/ludia-130sen_query_scan.html 同じ現象かどうかは判断がつきません。 ●推測される原因 分割テーブル、Ludiaの全文検索を併用した場合、インデックスの状態によっては、 オプティマイザなどが正しく動作せず、検索のプロセスが強制終了されることが あるのではないかと、推測しています。 ●環境について PostgreSQL 8.2.5 ludia-1.1.0(ludia-1.3.0も試用) senna-1.0.9 ※CEにて年単位でテーブル分割を行っています。 ※indexはngramを使用しています。 何かお解りでしたら、ご教示くださいますよう、お願い致します。 Tetsuo Kawanishi t_kawanishi ＠ hotmail.co.jp _________________________________________________________________ 【MSNビデオ】超貴重！驚きの大物対談が実現。作家 村上龍が話題のあの人に迫る http://video.msn.co.jp/rvr/default.htm -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/ludia-users/attachments/20071023/40f5ec60/attachment.htm From kousakadi ＠ nttdata.co.jp Tue Oct 23 14:00:15 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Tue, 23 Oct 2007 14:00:15 +0900 Subject: [Ludia-users 121] =?iso-2022-jp?b?THVkaWExLjMuMRskQiRyJWolaiE8JTkkNyReJDckPxsoQg==?= Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C67@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 Ludia1.3.1をリリースしました。 Ludia1.3.0を使用している方は、1.3.1への乗り換えをお勧めします。 変更内容は以下となります。 (1)メモリリークの修正 　大規模なインデックスを作成する際のメモリリークを修正しました。 (2)シーケンシャルスキャン改善 　空文字のシーケンシャルスキャン時に、 　"ERROR: pgsenna2: sen_query_scan failed (1)" 　を返す問題を修正しました。 (3)postgresql.conf 　postgresql.confを変更せずに使用できるようになりました。 　変更しない場合はデフォルト値が適用されます。 不具合、バグなどがありましたら、ご報告よろしくお願いします。 From kousakadi ＠ nttdata.co.jp Tue Oct 23 14:14:08 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Tue, 23 Oct 2007 14:14:08 +0900 Subject: [Ludia-users 122] Re: =?iso-2022-jp?b?GyRCRkNEaiROPnI3byRHGyhCREIbJEJAXEIzJCwbKEI=?= =?iso-2022-jp?b?GyRCNi9AKT0qTjskNSRsJEYkNyReJCQkXiQ5GyhC?= References: Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C68@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > 1. DB接続が切れてしまうクエリの例 > > SELECT * FROM data > WHERE fulltext1 @@ '*D+ "テスト"' > AND date between '2006-09-01' AND '2007-09-01'; > > 2. 正常に結果が得られるクエリの例 > > A. WHEREにて日付を全文検索の条件より前につける > SELECT * FROM data > WHERE date between '2006-09-01' AND '2007-09-01' > AND fulltext1 @@ '*D+ "テスト"'; この二種類のクエリのexplainを送っていただけないでしょうか？ （先ほどリリースしたLudia1.3.1を使用して頂けると助かります。） また、テーブルのサイズも教えていただけると原因解明に役立ちます。 > "ERROR: pgsenna2: sen_query_scan failed (1)" これは、@@で全文検索を行ったが、インデックススキャンが選択されず、 シーケンシャルスキャンが選択された場合で、 さらにカラムに空文字列が含まれている場合に発生します。 先ほどリリースしたLudia1.3.1では改修されています。 最後に、全ての子テーブルにインデックスが張ってあるか確認してもらえますか？ （分割テーブルの場合、親テーブルにインデックスを張っても意味がありません。） インデックスが張っていないカラムを@@で検索した場合は、 必ずシーケンシャルスキャンが選択されます。 以上、よろしくお願いします。 ________________________________ From: ludia-users-bounces ＠ lists.sourceforge.jp [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf Of Kawanishi Tetsuo Sent: Tuesday, October 23, 2007 11:06 AM To: ludia-users ＠ lists.sourceforge.jp Subject: [Ludia-users 120] 特定の条件でDB接続が強制終了されてしまい ます こんにちは。川西です。 年ごとに分割したテーブルと、senna/ludiaを組み合わせを、 下記のようなテーブル構成で利用しています。 dataという親テーブルを継承した、 子テーブル(data_2006, data_2007, ..)があります。 data(親) - ・ - data_2005(子) - data_2006(子) - data_2007(子) - ・ - ・ 日付（分割のルールとなっている条件)を指定せず検索した場合、 DBとの接続が切れるのですが、日付を指定した場合にも 全文検索を行うと接続が切れることがありました。 sennaのインデックスを持つカラムは3つあり、いずれかのカラムに対して、 全文検索を行った場合、DBとの接続が強制終了されていました。 ※ 3つのカラムはfulltext1,fulltext2,fulltext3とします。 ●現象の発生条件 　以下の3つをすべて満たす場合です。 　A. Senna/Ludiaの全文検索を使 MQ$9$k>l9g 　B. 分割テーブルの親テーブルより検索(SELECT * FROM data) 　C. WHERE句にて日付の条件を全文検索の条件より後につけた場合 ●具体的なクエリの例 1. DB接続が切れてしまうクエリの例 SELECT * FROM data WHERE fulltext1 @@ '*D+ "テスト"' AND date between '2006-09-01' AND '2007-09-01'; 2. 正常に結果が得られるクエリの例 A. WHEREにて日付を全文検索の条件より前につける SELECT * FROM data WHERE date between '2006-09-01' AND '2007-09-01' AND fulltext1 @@ '*D+ "テスト"'; B. 分割テーブルの子テーブル(data_2007)を指定 SELECT * FROM data_2007 as r WHERE fulltext1 @@ '*D+ "テスト"' AND date between '2006-09-01' AND '2007-09-01'; C. Senna/Ludiaの全文検索ではなく"LIKE"を使用 SELECT * FROM data WHERE fulltext1 LIKE '%テスト%' AND date between '2006-09-01' AND '2007-09-0! 1'; ●DB接続が切れてしまった際のメッセージ &nbs p; WARNING: terminating connection because of crash of another server process ●対応策として試してみたこと 1. Ludia 1.3.0へのバージョンアップ 試してみたところ、fulltext1,fulltext2の全文検索は正常に行えまし た。 fulltext3の全文検索を行ったところ、下記のエラーが出力されました。 "ERROR: pgsenna2: sen_query_scan failed (1)" このエラーメッセージから、以下のblog記事に辿り着きました。 http://mt.endeworks.jp/d-6/2007/10/ludia-130sen_query_scan.html 同じ現象かどうかは判断がつきません。 ●推測される原因 分割テーブル、Ludiaの全文検索を併用した場合、インデックスの状態に よっては、 オプティマイザなどが正しく動作せず、検索のプロセスが強制終了され ることが あるのではないかと、推測しています。 ●環境について Postgre! SQL 8.2.5 ludia-1.1.0(ludia-1.3.0も試用) senna-1.0.9 ※CEにて年単位でテーブル分割を行っています。 ※indexはngramを使用しています。 何かお解りでしたら、ご教示くださいますよう、お願い致します。 Tetsuo Kawanishi t_kawanishi ＠ hotmail.co.jp -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/ludia-users/attachments/20071023/cb61bdd8/attachment.htm From t_kawanishi ＠ hotmail.co.jp Fri Oct 26 23:42:45 2007 From: t_kawanishi ＠ hotmail.co.jp (Kawanishi Tetsuo) Date: Fri, 26 Oct 2007 23:42:45 +0900 Subject: [Ludia-users 123] =?iso-2022-jp?b?IFJFOiAgUmU6IBskQkZDRGokTj5yN28kRxsoQkRC?= =?iso-2022-jp?b?GyRCQFxCMyQsNi9AKT0qTjskNSRsJEYkNyReJCQkXiQ5GyhC?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C68@MAILSV11.msg.nttdata.co.jp> References: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C68@MAILSV11.msg.nttdata.co.jp> Message-ID: 幸坂さん こんばんは。川西です。 ご解答いただきましてありがとうございます。 Ludia1.3.1を使用したところ、エラーがでることなく正常に動作しました。 検索対象のカラムには148件ほど、空文字列のデータが含まれていました。 また、VACUUM、および、ANALYZEをしていなかったことも原因だったのかもしれません。 > この二種類のクエリのexplainを送っていただけないでしょうか？ > （先ほどリリースしたLudia1.3.1を使用して頂けると助かります。） Ludia1.3.1で、VACUUM ANALYZE済みの状態でEXPLAINしたところ、 下記ようなクエリプランになり、dateとfulltext3の順序以外は差異の無い状態でした。 Aggregate (cost=100000000.67..100000000.69 rows=1 width=0) -> Append (cost=100000000.00..100000000.55 rows=50 width=0) -> Seq Scan on data (cost=100000000.00..100000000.52 rows=1 width=0) Filter: ((date>= '2006-09-01'::date) AND (date <= '2007-09-01'::date) AND (fulltext3 @@ '*D+ "テスト"'::text)) -> Index Scan using idx_data_2006_fulltext3 on data_2006 data (cost=0.00..0.02 rows=25 width=0) Index Cond: (fulltext3 @@ '*D+ "テスト"'::text) Filter: ((date>= '2006-09-01'::date) AND (date <= '2007-09-01'::date)) -> Index Scan using idx_data_2007_fulltext3 on data_2007 data (cost=0.00..0.02 rows=24 width=0) Index Cond: (fulltext3 @@ '*D+ "テスト"'::text) Filter: ((date>= '2006-09-01'::date) AND (date <= '2007-09-01'::date)) (10 rows) > また、テーブルのサイズも教えていただけると原因解明に役立ちます。 pg_relation_size / pg_total_relation_sizeは下記の通りです。 data_2006 : 212MB / 451MB data_2007 : 206MB / 441MB また、インデックスは全ての子テーブルに張っている状態でした。 Ludiaのバージョンアップ後に、VACUUMをかけたところ、VACUUM実行中に 以下のメッセージが出力されるようになってしまいました。 "pgsenna2: |A| sen_nstr_open failed at sen_lex_open" 上記のDBより、データ量が多いDBで行った際に発生しましたが、 環境の変化も多少あったため、問題の切り分けができていません。 また、検索したころ、下記のMLの記事を見つけました。 http://lists.sourceforge.jp/mailman/archives/senna-dev/2007-July/000645.html 何かお解りでしたら、ご教示くださいますよう、お願いいたします。 Tetsuo Kawanishi t_kawanishi ＠ hotmail.co.jp _________________________________________________________________ 今話題になってる出来事や有名人をランキングで毎週発表「MSN 気になる言葉」 http://keyword.jp.msn.com/default.aspx From kousakadi ＠ nttdata.co.jp Mon Oct 29 08:52:35 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Mon, 29 Oct 2007 08:52:35 +0900 Subject: [Ludia-users 124] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= References: <20071010.092351.01365976.tanakasns@nttdata.co.jp><20071011.102041.01366533.tanakasns@nttdata.co.jp> <20071018.143605.01365955.tanakasns@nttdata.co.jp> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C76@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 こちらでも、 > ludia 1.2.0 > Senna 1.0.9 > mecab 0.96 > mecab-ipadic 2.7.0 20070801 EUC-JP ludia.initial_n_segments = 2048 shared_buffers = 512MB 200Kbyte 10万レコード のインデックス構築(copyした後、create index)を行ってみましたが、 状況は再現できませんでした。 ludia1.3.1も同様でした。 > LOG: pgsenna2: |A| malloc fail (139096976)=(nil) (inv.c:934) <12770> > ERROR: pgsenna2: sen_index_upd failed while do_insert (1) エラー内容はmallocに失敗しましたというものです。 原因として、１プロセスの使用メモリの制限(32bitマシンの場合2Gbyte)を 超えてmallocを試みたという事が考えられます。 インデックス構築中のメモリ使用量はどのようになっていますか？ また、postgresql.confのshared_buffersの値はいくつにしていますか？ この値とSennaのメモリ使用量の合計が2Gを超えると、 上記のエラーが出る可能性があります。 > PostgreSQLのデータベースクラスタの領域以外にファイルが作られることは > あるのでしょうか？ テーブルスペースをデータベースクラスタ以外の場所に作成した場合を除いて、 データベースクラスタの領域以外にファイルが作られることはありません。 インデックスサイズが非常に大きい場合(数GByte)は、 パーティショニングを行うと、インデックス構築の時間短縮になります。 http://www.postgresql.jp/document/pg825doc/html/ddl-partitioning.html この方法も試してみたらいかがでしょうか。 以上です。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of Shunsuke Tanaka > Sent: Thursday, October 18, 2007 2:36 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 119] Re: 形態素インデックスで投入に1秒以上かかります > > 田中です。 > > 返信ありがとうございます。 > > > > デフォルト設定(initial_n_segments=512)で実施したところ、15万件ほど投入 し > > > たところで下記のエラーが出ました。 > > > > > > LOG: pgsenna2: |A| malloc fail (132633168)=(nil) > (inv.c:934) <605> > > > ERROR: pgsenna2: sen_index_update failed > > > > 返信が遅くなってすみません。 > > もしかすると、 > > バージョン1.3のマルチカラムインデックス対応で改変した部分が > > 関係しているかもしれません。 > > > > 可能であれば、 > > 一度ludia-1.2.0を使って試してみていただけないでしょうか。 > > ludia-1.2.0で試してみましたが、同じように、15万件ほど投入したところで > 下記のエラーが出て投入ができなくなりました。 > ※エラーが出て投入できなくなった件数は完全に同じではなく、 > 数千件程度の差があります。 > > LOG: pgsenna2: |A| malloc fail (139096976)=(nil) (inv.c:934) <12770> > ERROR: pgsenna2: sen_index_upd failed while do_insert (1) > > なお、他のソフトウェアのバージョンは以下の通りです。 > Senna 1.0.9 > mecab 0.96 > mecab-ipadic 2.7.0 20070801 > PostgreSQL 8.2.4 > > > > そこで、initial_n_segments=2048、max_n_index_cache=64に設定して、 > > > もう一度行ったところ、15万件ほど投入したところで、 > > > 突然、ルートファイルシステムが読み取り専用になってしまい、 > > > 投入するプロセスが異常終了するという結果になりました。 > > > > もしテストする過程で不要になったインデックスファイルが > > ディスクにたまってしまっている場合、 > > psql等で不要なインデックスをDROPしたあと、 > > 以下の要領でクリーンアップしてみてください。 > > > > # SELECT pgs2destroy(); > > 1つのテストを終えたら、データベースクラスタを破棄して、 > 次のテストではデータベースクラスタを新しく作り直して行っています。 > テスト時に不要になったインデックスファイルはないと思いますので、 > クリーンアップの必要もないと思いますが。 > PostgreSQLのデータベースクラスタの領域以外にファイルが作られることは > あるのでしょうか？ > > よろしくお願いします。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From tanakasns ＠ nttdata.co.jp Mon Oct 29 15:24:51 2007 From: tanakasns ＠ nttdata.co.jp (Shunsuke Tanaka) Date: Mon, 29 Oct 2007 15:24:51 +0900 (LMT) Subject: [Ludia-users 125] Re: =?iso-2022-jp?b?GyRCN0FCVkFHJSQlcyVHJUMlLyU5JEdFakZ+JEsbKEIx?= =?iso-2022-jp?b?GyRCSUMwSj5lJCskKyRqJF4kORsoQg==?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C76@MAILSV11.msg.nttdata.co.jp> References: <20071018.143605.01365955.tanakasns@nttdata.co.jp> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C76@MAILSV11.msg.nttdata.co.jp> Message-ID: <20071029.152451.60853603.tanakasns@nttdata.co.jp> 田中です。 > こちらでも、 > > ludia 1.2.0 > > Senna 1.0.9 > > mecab 0.96 > > mecab-ipadic 2.7.0 20070801 > EUC-JP > ludia.initial_n_segments = 2048 > shared_buffers = 512MB > 200Kbyte 10万レコード > のインデックス構築(copyした後、create index)を行ってみましたが、 > 状況は再現できませんでした。 > ludia1.3.1も同様でした。 試してみてくださり、誠にありがとうございます。 shared_buffers = 512MB にしてみるのと、Linuxカーネルを新しいものにしてみ るのを、トライしてみたいと思います。 > > LOG: pgsenna2: |A| malloc fail (139096976)=(nil) (inv.c:934) <12770> > > ERROR: pgsenna2: sen_index_upd failed while do_insert (1) > エラー内容はmallocに失敗しましたというものです。 > 原因として、１プロセスの使用メモリの制限(32bitマシンの場合2Gbyte)を > 超えてmallocを試みたという事が考えられます。 > インデックス構築中のメモリ使用量はどのようになっていますか？ 一番多くメモリを使っているプロセスは、 postgres: postgres ludiatestdb [local] INSERT というプロセスで、900Mbyteくらい使っています (psコマンドの出力のVSZが900MbyteくらでRSSも900Mbyteくらいでした)。 2Gbyteまでは行っていません。 > また、postgresql.confのshared_buffersの値はいくつにしていますか？ > この値とSennaのメモリ使用量の合計が2Gを超えると、 > 上記のエラーが出る可能性があります。 postgresql.confのshared_buffersは、デフォルトのままで、24MBです。 一番多くメモリを使っているプロセスのメモリ使用量と足しても2Gは超えません。 > インデックスサイズが非常に大きい場合(数GByte)は、 > パーティショニングを行うと、インデックス構築の時間短縮になります。 > http://www.postgresql.jp/document/pg825doc/html/ddl-partitioning.html > この方法も試してみたらいかがでしょうか。 情報提供ありがとうございます。 1つのテーブルではどうやっても無理という結果になりましたら、 パーティショニングを試してみたいと思います。 From kousakadi ＠ nttdata.co.jp Tue Oct 30 08:59:28 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Tue, 30 Oct 2007 08:59:28 +0900 Subject: [Ludia-users 126] Re: =?iso-2022-jp?b?GyRCRkNEaiROPnI3byRHGyhCREIbJEJAXEIzJCwbKEI=?= =?iso-2022-jp?b?GyRCNi9AKT0qTjskNSRsJEYkNyReJCQkXiQ5GyhC?= References: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C68@MAILSV11.msg.nttdata.co.jp> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C7D@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > Ludiaのバージョンアップ後に、VACUUMをかけたところ、VACUUM実行中に > 以下のメッセージが出力されるようになってしまいました。 > "pgsenna2: |A| sen_nstr_open failed at sen_lex_open" メッセージが出力されますが、動作上問題ありません。 また、Sennaの開発版では、sen_nstr_openの挙動が若干変わっています。 次のバージョンのSennaを利用すれば上記のメッセージは消えるはずです。 以上です。 > -----Original Message----- > From: ludia-users-bounces ＠ lists.sourceforge.jp > [mailto:ludia-users-bounces ＠ lists.sourceforge.jp] On Behalf > Of Kawanishi Tetsuo > Sent: Friday, October 26, 2007 11:43 PM > To: ludia-users ＠ lists.sourceforge.jp > Subject: [Ludia-users 123] RE: Re: 特定の条件でDB接続が強制終了されてしま います > > > 幸坂さん > > こんばんは。川西です。 > > ご解答いただきましてありがとうございます。 > > Ludia1.3.1を使用したところ、エラーがでることなく正常に動作しました。 > 検索対象のカラムには148件ほど、空文字列のデータが含まれていました。 > また、VACUUM、および、ANALYZEをしていなかったことも原因だったのかもしれま せん。 > > > この二種類のクエリのexplainを送っていただけないでしょうか？ > > （先ほどリリースしたLudia1.3.1を使用して頂けると助かります。） > > Ludia1.3.1で、VACUUM ANALYZE済みの状態でEXPLAINしたところ、 > 下記ようなクエリプランになり、dateとfulltext3の順序以外は差異の無い状態で した。 > > Aggregate (cost=100000000.67..100000000.69 rows=1 width=0) > -> Append (cost=100000000.00..100000000.55 rows=50 width=0) > -> Seq Scan on data > (cost=100000000.00..100000000.52 rows=1 width=0) > Filter: ((date>= '2006-09-01'::date) AND (date > <= '2007-09-01'::date) AND (fulltext3 @@ '*D+ "テスト"'::text)) > -> Index Scan using idx_data_2006_fulltext3 on > data_2006 data (cost=0.00..0.02 rows=25 width=0) > Index Cond: (fulltext3 @@ '*D+ "テスト"'::text) > Filter: ((date>= '2006-09-01'::date) AND (date > <= '2007-09-01'::date)) > -> Index Scan using idx_data_2007_fulltext3 on > data_2007 data (cost=0.00..0.02 rows=24 width=0) > Index Cond: (fulltext3 @@ '*D+ "テスト"'::text) > Filter: ((date>= '2006-09-01'::date) AND (date > <= '2007-09-01'::date)) > (10 rows) > > > また、テーブルのサイズも教えていただけると原因解明に役立ちます。 > > pg_relation_size / pg_total_relation_sizeは下記の通りです。 > data_2006 : 212MB / 451MB > data_2007 : 206MB / 441MB > > また、インデックスは全ての子テーブルに張っている状態でした。 > > > Ludiaのバージョンアップ後に、VACUUMをかけたところ、VACUUM実行中に > 以下のメッセージが出力されるようになってしまいました。 > "pgsenna2: |A| sen_nstr_open failed at sen_lex_open" > > 上記のDBより、データ量が多いDBで行った際に発生しましたが、 > 環境の変化も多少あったため、問題の切り分けができていません。 > > また、検索したころ、下記のMLの記事を見つけました。 > http://lists.sourceforge.jp/mailman/archives/senna-dev/2007-Ju > ly/000645.html > > 何かお解りでしたら、ご教示くださいますよう、お願いいたします。 > > Tetsuo Kawanishi > t_kawanishi ＠ hotmail.co.jp > _________________________________________________________________ > 今話題になってる出来事や有名人をランキングで毎週発表「MSN 気になる言葉」 > http://keyword.jp.msn.com/default.aspx > > _______________________________________________ > Ludia-users mailing list > Ludia-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From kousakadi ＠ nttdata.co.jp Wed Oct 31 10:59:57 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Wed, 31 Oct 2007 10:59:57 +0900 Subject: [Ludia-users 127] Ludia1.3.1windows Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C87@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 Ludia1.3.1 windows版をリリースしました。 変更内容はLudia1.3.1 Linux版と同じです。 http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000120 .html 以下、インストールの諸注意です。 Ludia1.3.0winからバージョンアップする場合： インストーラ(ludia1.3.1_UTF_PG82.msi) を実行してください。 インデックスの再構築やpostgresql.confの再設定の必要はありません。 新規に利用する場合： デフォルトで使用する場合、postgresql.conf 設定の必要がなくなりました。 今までよりも、お手軽に利用する事ができます。 以上です。