[pgpool-general-jp: 1218] Re: オンメモリクエリキャッシュ機能について
Tatsuo Ishii
ishii ＠ sraoss.co.jp
2013年 11月 6日 (水) 08:38:18 JST
佐藤様
石井です。
ご報告ありがとうございます。問題が解決して良かったです。
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> 石井様
>
> お世話になっております。エルテックスの佐藤です。
>
> 時間がたってしまい恐縮ですが、本件解決した旨、ご連絡致します。
> 3.2.5で問題事象が起きないことを確認いたしました。
> 以下に該当していたと考えております。
>
> リリースノート
> ---------------------------------------------------------------------------------------------------------------------
> オンメモリクエリキャッシュを有効にした時の拡張クエリの処理におけるメモリ割り当てロジックを修正しました。(Tatsuo Ishii)
> バインドパラメータ付きの拡張クエリで、1024 バイト以上の長いクエリ文字列が渡されたときに、 十分なメモリ割り当てができていませんでした。
> ---------------------------------------------------------------------------------------------------------------------
>
> よろしくお願いいたします。
>
> 2013年7月26日 13:31 佐藤慎 <s_sato ＠ eltex.co.jp>:
>
>> 石井様
>>
>> お世話になっております。エルテックスの佐藤です。
>>
>> ご回答ありがとうございます。
>> まずは、pgpool-II3.2.5で再現しないか確認させて頂きます。
>>
>> 3.2.5でも再現した場合は、再現プログラムを準備致しますので、
>> その際はよろしくお願いいたします。
>>
>> 2013年7月9日 15:10 Tatsuo Ishii <ishii ＠ sraoss.co.jp>:
>> > 石井と申します。
>> >
>> > pgpool-II3.2.4での既知のクエリキャッシュ周りの障害としては、以下があります。
>> >
>> >
>> http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=a6d91284223576d82f9eef689493c883d1efcc69
>> >
>> > これに該当してい場合には、当方で再現できる環境(再現プログラムなど)など
>> > をご提供頂ければ調査可能と思います。
>> > --
>> > Tatsuo Ishii
>> > SRA OSS, Inc. Japan
>> > English: http://www.sraoss.co.jp/index_en.php
>> > Japanese: http://www.sraoss.co.jp
>> >
>> >> お世話になっております。エルテックスの佐藤と申します。
>> >>
>> >> 前回、問い合わせさせて頂きました「[pgpool-general-jp: 1169] クエリキャッシュの不正」の継続した投稿になります。
>> >>
>> >> PostgreSQL 9.2.4 とpgpool-II 3.2.4 の環境で動作検証行っていますが、
>> >> 同じSELECTで常に同じ結果が返るはずのものが、SELECTする都度、SELECT結果が違ってしまう、という症状が発生します。
>> >> オンメモリクエリキャッシュ機能を有効にした場合のみ、発生します。
>> >> SELECT結果が違ってしまう場合、キャッシュからSELECT結果を返しているというpgpoolのログが出ております。
>> >>
>> >> DBは HS/SRクラスタで、pgpoolはmaster-slaveモードになります。
>> >>
>> >> [各種環境]
>> >> Apache Tomcat Version 7.0.29
>> >> コネクションプーリング tomcat-dbcp.jar(Apache Tomcat 付属)
>> >> JDBCドライバー postgresql-9.1-902.jdbc4.jar
>> >> PostgreSQL (9.2.4)
>> >> pgpool-II (3.2.4)
>> >> Java 1.7.0_05-b06
>> >> Webサーバー Apache 2.2.23
>> >>
>> >> [SQLの生成方法]
>> >> SQLは PreparedStatement を使って実行していますが、LIMIT句とOFFSET句は
>> >>
>> >> StringBuilder sb = new StringBuilder();
>> >> sb.append(original);
>> >> sb.append(apendOrderby(criteria));
>> >> sb.append(" LIMIT ");
>> >> sb.append(criteria.getCriteriaResult().getLimit());
>> >> sb.append(" OFFSET ");
>> >> sb.append(criteria.getCriteriaResult().getStart() - 1);
>> >>
>> >> のように、SQL中に直接埋め込んでいます。
>> >>
>> >> 個別の検索条件にはプレースホルダーを使用していますので、
>> >> 発行されるSQLのイメージとしては
>> >>
>> >> SELECT
>> >> employee_id
>> >> ,first_name
>> >> ,last_name
>> >> ,email
>> >> ,phone_numeric
>> >> ,hire_date
>> >> ,job_id
>> >> ,salary
>> >> ,commission_pct
>> >> ,manager_id
>> >> ,department_id
>> >> FROM
>> >> employee
>> >> WHERE
>> >> department_id = ?
>> >> ORDER BY
>> >> employee_id limit 10 offset 10;
>> >>
>> >> のようになります。実際のSQLはもっと長いです。
>> >>
>> >> コネクションはTomcatのコネクションプーリングを使用していて、
>> >> JNDIでルックアップして取得しています。
>> >>
>> >> 上記のSELECTをpsqlで単一のSQLとして、発行した場合は、問題事象は発生しませんが、アプリケーションから実行すると事象発生します。
>> >> オンメモリクエリキャッシュ機能を有効にした場合のみ再現し、オンメモリクエリキャッシュ機能を無効にすると問題事象は再現せずに、改善します。
>> >>
>> >> オンメモリクエリキャッシュ機能は共有メモリーを使用しています。
>> >> pgpoolのオンメモリクエリキャッシュ機能の設定としては、以下のとおりです。
>> >> memory_cache_enabled = on
>> >> memqcache_method = 'shmem'
>> >> memqcache_memcached_host = 'localhost'
>> >> memqcache_memcached_port = 11211
>> >> memqcache_total_size = 67108864
>> >> memqcache_max_num_cache = 1000000
>> >> memqcache_expire = 0
>> >> memqcache_auto_cache_invalidation = on
>> >> memqcache_maxcache = 409600
>> >>
>> >> 「SHOW pool_cache」コマンドからキャッシュストレージのエントリが一杯でないことは確認済みです。
>> >>
>> >> 質問事項
>> >>
>> -------------------------------------------------------------------------------------------------------------------------------
>> >> 1. マニュアルを見ると以下記述がございますが、オンメモリクエリキャッシュ機能ではSQLの長さに制限がありますでしょうか。
>> >>
>> >> 「オンメモリクエリキャッシュは、問い合わせのSELECT文(拡張問い合わせの場合は更にバインドパラメータ)と
>> >> 検索結果をペアで記録し、2回目以降に同じSELECT文が発行された場合に、キャッシュから結果を返します。」
>> >>
>> >> 2. 発行するSQLは上記のSQLのようなイメージですが、最後のoffset値だけが0、10、20というように変化します。
>> >> SQLが長すぎて、過去にキャッシュした似たSQLと同一とみなされて、キャッシュから結果を返しているということはありませんでしょうか？
>> >>
>> >> 3. 原因を特定するために、確認すべき項目がありましたら、教えて頂けないでしょうか？
>> >>
>> >>
>> ------------------------------------------------------------------------------------------------------------------------------
>> >>
>> >> ご回答は一部でもよく、何かヒントになるものでも構いませんので、よろしくお願いいたします。
>> >>
>> >> --
>> >> ―――――――――――――――――――――――――
>> >> 佐藤 慎
>> >> 株式会社エルテックス
>> >> システムマネージメントサービス部
>> >> 〒240-0005 横浜市保土ヶ谷区神戸町134
>> >> 横浜ビジネスパーク イーストタワー14階
>> >> 電話：045-332-7865 Fax：045-332-6644
>> >> URL ：http://www.eltex.co.jp/
>> >> facebook：http://www.facebook.com/ELTEXinc
>> >> ――――――――――――――――――(c)ELTEX, Inc.
>> >> _______________________________________________
>> >> pgpool-general-jp mailing list
>> >> pgpool-general-jp ＠ sraoss.jp
>> >> http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp
>>
>>
>>
>> --
>> ―――――――――――――――――――――――――
>> 佐藤 慎
>> 株式会社エルテックス
>> システムマネージメントサービス部
>> 〒240-0005 横浜市保土ヶ谷区神戸町134
>> 横浜ビジネスパーク イーストタワー14階
>> 電話：045-332-7865 Fax：045-332-6644
>> URL ：http://www.eltex.co.jp/
>> facebook：http://www.facebook.com/ELTEXinc
>> ――――――――――――――――――(c)ELTEX, Inc.
>>
>
>
>
> --
> ―――――――――――――――――――――――――
> 佐藤 慎
> 株式会社エルテックス
> システムマネージメントサービス部
> 〒240-0005 横浜市保土ヶ谷区神戸町134
> 横浜ビジネスパーク イーストタワー14階
> 電話：045-332-7865 Fax：045-332-6644
> URL ：http://www.eltex.co.jp/
> facebook：http://www.facebook.com/ELTEXinc
> ――――――――――――――――――(c)ELTEX, Inc.
pgpool-general-jp メーリングリストの案内