[pgpool-general-jp: 1183] Re: オンメモリクエリキャッシュ機能について
佐藤慎
s_sato ＠ eltex.co.jp
2013年 7月 26日 (金) 13:31:24 JST
石井様
お世話になっております。エルテックスの佐藤です。
ご回答ありがとうございます。
まずは、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.
pgpool-general-jp メーリングリストの案内