高見 直輝
takam****@orega*****
2015年 8月 26日 (水) 16:43:27 JST
高見です。 > >> INSERT文ではデータを書き込むためにロックを獲得する必要があり > >> ます。ロックを獲得できない場合はロックを獲得できるまで（デフォ > >> ルトでは結構長い時間）がんばります。その間は処理が止まるので > >> いつまでも終了しません。 > > > > “デフォルトでは”ということは、設定の変更が可能なのでしょうか？ > > Groongaレベルでは変更が可能ですが、PGroongaレベルでは変更で > きません。 > > でしたが、さっきpgroonga.lock_timeout変数で変更できるように > しておきました。 ありがとうございます。 > タイムアウトするまでの時間の数え方が少し面倒なので説明します。 > > 多くの場合、タイムアウトというとタイムアウトするまでの時間を > 指定しますが、Groongaは何回チャレンジして獲得できなかったら > タイムアウトとするかという回数を指定します。 > > 1回のチャレンジ毎に1ミリ秒sleepするので、1秒でロックを獲得で > きなかったら諦めるようにするなら次のように1000を指定します。 > > SET pgroonga.lock_timeout = 1000; 実際の設定はリトライ回数ということですね。 > 少し頑張れば1回のチャレンジ毎にどのくらいsleepするかをカスタ > マイズすることもできるのですが、これまで需要がなかったのでカ > スタマイズできるようにはなっていません。おそらく、これからも > 需要はない気はしています。 私も全体設定があれば十分だと思います。 > > 当方としては、ある程度待って駄目ならPostgresのエラーとして検知できるのが望ましいのですが、 > > このような設定は可能でしょうか？ > > 前述の説明の通りなので、適切な値をpgroonga.lock_timeoutに設 > 定すると実現できます。 > > ロックを獲得できないエラーになったからといって書き込みできる > ようになるわけではないという点に注意してください。根本的な問 > 題はそこなので、そちらの解決をしないと一時しのぎになってしま > います。 > > もちろん、被害を抑えるという意味では効果はあるので、その観点 > での使用は効果的だと思います。 問題となっているのが“書き込み処理が停止しているのに気付けない”ことなので、 この点は大丈夫です。 そもそもの障害発生原因については、現在調査中です。 > > 検索処理ではロックを取得しない（エラーの発生原因にはならない）という認識で良いですか？ > > はい。 > > > 現在、対象のテーブルに対して実行している操作は、検索・追加以外では以下の3つのみです。 > > ・テーブルダンプ > > ・VACUUM（AUTOVACUUM） > > ・ANALYZE > > この中にロックを取得する処理は有りますでしょうか？ > > たぶん、VACUUMだけです。 > > テーブルダンプはpg_dumpのことですよね？ダンプの中には元デー > タとインデックス定義しか含まれないので、PGroongaに書き込み要 > 求はいかないはずです。 > > ANALYZEも読み込みだけで書き込みはないはずなのでロックも必要 > ないはずです。 ありがとうございます。 原因究明後、AUTOVACUUMを停止します。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
