kentoku
kento****@gmail*****
2013年 10月 1日 (火) 01:13:14 JST
斯波です。 > 前回のご報告以来、問題は発生していない状態です。 > > おそらくコネクションの長時間の維持が、ロックが解除されない状態の主な原因になっていたのではないかと思います。 > > 再現条件がはっきりせず、後味は悪いのですが、一般的な接続時間で利用している限りでは問題ないのかもしれません。 ご確認ありがとうございます。 ひとまずは問題がないとのことで、よかったです。 再発した際には、またご連絡ください。 どうぞ、よろしくお願いします。 2013年9月30日 7:47 <mail_babir****@yahoo*****>: > 田辺です。 > > ご連絡が遅れてしまい、申し訳有りません。 > > 前回のご報告以来、問題は発生していない状態です。 > > おそらくコネクションの長時間の維持が、ロックが解除されない状態の主な原因になっていたのではないかと思います。 > > 再現条件がはっきりせず、後味は悪いのですが、一般的な接続時間で利用している限りでは問題ないのかもしれません。 > > > 田辺公平 > > > --- On Mon, 2013/9/23, kentoku <kento****@gmail*****> wrote: > > > 斯波です。 > > > > この問題ですが、 > > そちらの環境ではまだ問題が発生する状態でしょうか？ > > > > お手数ではございますが、ご確認をお願いいたします。 > > > > > > > > 2013年8月6日 1:47 kentoku <kento****@gmail*****>: > > > > > 斯波です。 > > > > > > 追加情報ありがとうございます！ > > > こちらでも先週から再現を試みているのですが、再現していない状況でした。 > > > 頂いた情報をもとに、 > > > select→120秒待つ→insert > > > シンタックスエラーとなるselectの実行 > > > を再現用の負荷に追加してみます。 > > > > > > なお、こちらの問題は、以下のチケットで管理されております。 > > > http://redmine.groonga.org/issues/1879 > > > > > > どうぞ、よろしくお願いします。 > > > > > > > > > > > > > > > 2013年8月4日 19:37 <mail_babir****@yahoo*****>: > > > > > > 田辺です > > >> > > >> > > >> > > >> > デッドロックが発生する件、こちらでほぼ本番環境に近い状態を作ってテストを行いましたが、テスト環境では未だ再現ができておらず、お伝えしたインクリメント処理以外に問題点がある可能性が高いように感じました。 > > >> > > >> > > > > >> > インクリメント処理が原因のようだったので、実際のインクリメントはNoSQLなどで担当させ、mroongaテーブルへ定期的に反映させる形に変更したところ、再発しなくなりました。 > > >> > > >> こちら、この対応を行っても不具合が再現してしまうことを確認しました。 > > >> ただ、頻度自体はかなり稀になっているため、解決はしないものの、インクリメント処理の頻度に応じて再現率が変わっているようには感じます。 > > >> > > >> > > >> > > >> また、原因になりそうな点で認識できていなかった部分が見つかりましたので、お伝えしたいと思います。 > > >> > > >> > > >> > > >> まず前回のテーブルに追加して、以下のuserカラムに通常のインデックスが貼られた状態となっています。 > > >> `user` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, > > >> > > >> そこに、以下のようなselect文がまず発行されます。 > > >> select name from main where user='username' order by id desc limit 1 > > >> > > >> その後、最大２分間ほどのバッチ処理が行われ、その応答を待ちます。 > > >> (バッチ処理内ではSQL文は発行されていない) > > >> > > >> 応答が帰って来た段階で、 > > >> insert into main(name, tag, date, access) values('name', 'tag1 tag2 > > >> tag3', NOW(), 1); > > >> > > >> のようにinsertが実施されるようになっています。 > > >> > > >> > > >> > > >> > > >> > この操作は滅多に実行されないため、問題とならないと考えていますが、バッチ処理の間、mysqlへの接続が維持された状態となっており、コネクション数に影響があるかと考えました。 > > >> > > >> > そこで、バッチ処理前後で切断・再接続を行い、長期間接続が維持されないように調整を行ったところ、現時点では不具合は再発しない状態となっております。 > > >> > > >> ただ、こちらの処置も頻度の軽減にしかなっていない可能性はあるため、今後再現されるか注視していきたいと思います。 > > >> > > >> > > >> > > >> > テーブルロックが発生する処理としては、先にお伝えしたupdateによるインクリメント処理の他に、現時点では稀に実行される上記のinsertが考えられる状態となっています。 > > >> > > >> 不具合の際にSHOW PROCESSLISTにて確認できる内容には、上記のinsertがブロックされている内容はありませんでした。 > > >> > > >> ただ、デッドロックの引き金となっている処理自体は、SHOW > > >> > PROCESSLISTに上がって来ていない可能性があるので、その他ロックされる処理として先ほどのinsertがあるのではないかと考えています。 > > >> > > >> > > >> さらに、以下のシンタックスエラーがある程度頻繁に出てしまう状況となっていたところを、発生しないように今回調整を行いました。 > > >> failed to parse fulltext search keyword: <+*>: <Syntax error! (*)> > > >> > > >> > > >> こちらでも再現が難しいため、かなり対処が難しいとは思いますが、可能性として有りそうな点を引き続き調査して頂けますと幸いです。 > > >> > > >> > > >> > > >> 田辺公平 > > >> > > >> _______________________________________________ > > >> groonga-dev mailing list > > >> groon****@lists***** > > >> http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > > >> > > > > > > > > _______________________________________________ > > groonga-dev mailing list > > groon****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
