mail_babir****@yahoo*****
mail_babir****@yahoo*****
2013年 8月 4日 (日) 19:37:40 JST
田辺です
デッドロックが発生する件、こちらでほぼ本番環境に近い状態を作ってテストを行いましたが、テスト環境では未だ再現ができておらず、お伝えしたインクリメント処理以外に問題点がある可能性が高いように感じました。
> > インクリメント処理が原因のようだったので、実際のインクリメントは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! (*)>
こちらでも再現が難しいため、かなり対処が難しいとは思いますが、可能性として有りそうな点を引き続き調査して頂けますと幸いです。
田辺公平