subversionとの連携について

[広瀬若葉]

広瀬ともうします。


RedmineとSubversionを連携させて利用していますが、以下の三点の動作の違いに疑問が出てきました。

尚、Subversionのアクセス制限としてBasic認証を利用していますが、mod_auth_mysqlを組み合わせ、
RedmineのSQLテーブルを参照し、ユーザーIDとパスワードのみ引っこ抜き、認証用のデータとさせています。

※RedmineはBitnamiのスタック版、1.0.1-0、Subversionはrpmforgeの1.6版を使用。
　 訳合って、Bitnamiスタック版内部のsubversionは利用していません。

※Redmine０．９．５＋Subversion1.4でも同様


★疑問点★
１．Redmine上から設定したリポジトリ内のファイルへのアクセスすると、表示されるまでに数十秒程度時間を要する
　→アクセス中にプロセスを監視すると、RemindeのMySQLが動作しているのが関係していると考えてますが、
　　 何をやっているのか不明。

２．TortoiseSVNやViewVCなどでの操作ではまったくストレスを感じない
　→Redmine上からとのアクセスには関係しない為だと推測しています。この間で利用されるのはBasic認証のみ
　　 なのは、プロセス動作状況やSQLのログなどから間違いは無い

３．EclipseからSVNへアクセスし、ファイルを参照するとRedmine上からアクセスするのと時間を要する。
　→Eclipseが特殊だからなのか、単にファイルを取得するだけならTortoiseSVNと大差は無いと思われるが、
　　 Redmine上からアクセスするのと同様にMySQLがワイワイ動いている状況が伺え、１と２の違いと食い違いが
　　 出てくるように思える。


１の動作については仕様（？）と言うべきなのか。また、SQLへのアクセスは認証以外に何を行っているのか？
３の場合、Eclipseはファイル取得以外に何か特殊な情報をRedmineのSQLへ掴みに行くのか？

この点について色々と調べているのですが、subversion、Eclipseについて知識が乏しく、解決に至っておりません。
何か有用な情報があれば、ご教授いただければ幸いです。

[乳牛]

乳牛と申します。

要するに「妙に遅い」ということでしょうか？
リポジトリは設定してから初回のリポジトリアクセス時ににコミットログをDBに
書き込むのでしばらくはMySQLアクセスがガンガン発生します。

ちょっと待ってからアクセスしてみても状況は変わらないでしょうか？

2010年8月31日13:35 広瀬若葉 <wak...@mail.lwtips.org>:

> --
> このメールは Google グループのグループ「Redmine Users (japanese)」の登録者に送られています。
> このグループに投稿するには、redmine-...@googlegroups.com にメールを送信してください。
> このグループから退会するには、redmine-users-...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/redmine-users-ja?hl=ja からこのグループにアクセスしてください。
>
>

[広瀬若葉]

ご返答ありがとうございます。

> 要するに「妙に遅い」ということでしょうか？
> リポジトリは設定してから初回のリポジトリアクセス時ににコミットログをDBに
> 書き込むのでしばらくはMySQLアクセスがガンガン発生します。
>
> ちょっと待ってからアクセスしてみても状況は変わらないでしょうか？

そうですね。端的に言えばRedmine上から、またはEclipse上からのアクセスに限って妙に遅いということです。
当然、リポジトリを設定し初回アクセス時は遅いというのは知っていますし、認識済みです。

Redmine.JPにある以下の設定を入れていますので
http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/
http://redmine.jp/faq/repository/subversion/

どちらかの設定を掛けているにも関わらずです。

※コミット頻度は高くありませんので、頻繁にSQL処理することは無い状態です（試験環境だからなんですけど）

あくまでも、参照時を前提としてお話とお考えいただければ幸いです。この場合、コミットログって関係するのでしょうか？

[乳牛]

乳牛です。

> Redmine.JPにある以下の設定を入れていますので
> http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/
> http://redmine.jp/faq/repository/subversion/

この部分は私が前回書いた、

>> リポジトリは設定してから初回のリポジトリアクセス時ににコミットログをDBに
>> 書き込むのでしばらくはMySQLアクセスがガンガン発生します。

とは違う話ですね。
上記の話は、設定後初回にの話なので。

初回のDBへのコミットログ取り込みが処理が終わっているのにもかかわらず遅い！
ということであれば、別問題でしょう。

[広瀬若葉]

広瀬です。

> 初回のDBへのコミットログ取り込みが処理が終わっているのにもかかわらず遅い！
> ということであれば、別問題でしょう。

そうなるでしょうね・・・（＾＾；

先ほど気づいたのですが、Redmine上からのアクセスでも一点不思議なところがあり、
リビジョン番号からの選択の場合は非常にスムーズで済みます。逆に、ツリーからシーケンシャルで追いかけると、
最後に目的のファイルを開くと時間が掛かるという状況です。

ツリーから追いかけてファイルを開くという段階でSQLが動作する理由が上記の動作ともマッチしないので、理解に
苦しんでるところです。

また何かありましたらお願いいたします。

[Toshi MARUYAMA]

まるやまです。

ここは、cat/diff/blameに相当するところかと思います。
abstract_adapter.rb の entry()というメソッドが呼ばれていて、
この中でentries()が呼ばれており、svn list が呼ばれているので
時間がかかっているのです。

http://www.redmine.org/projects/redmine/repository/entry/tags/1.0.1/lib/redmine/scm/adapters/abstract_adapter.rb#L84

>
> また何かありましたらお願いいたします。

[広瀬若葉]

広瀬です。

ご返答ありがとうございます。

> ここは、cat/diff/blameに相当するところかと思います。
> abstract_adapter.rb の entry()というメソッドが呼ばれていて、
> この中でentries()が呼ばれており、svn list が呼ばれているので
> 時間がかかっているのです。
>

> http://www.redmine.org/projects/redmine/repository/entry/tags/1.0.1/l...

rubyについては知識が無いので何とも言えませんが、Redmine上からのアクセスの仕方に
違いがあり、その影響なのだろうと推測しますが、合ってます？

Redmine上からはともかくとして、TortoiseSVNの機能の一部(リポジトリブラウザでCtrl+F5とか)、
Eclipseでのファイルオープンをする度にSQLに負荷が掛かる理由とどう関係してくるのか、未だ
謎です。

[Toshi MARUYAMA]

まるやまです。

RedmineでVCSに関連するテーブルとしてchangesetsとchangesというテーブルがあります。
Redmineでリビジョンを表示させる画面では、changesテーブルを表示させるだけですので、
SVNにはアクセスしていません。
http://www.redmine.org/projects/redmine/repository/revisions/4066
その先の画面で現在の実装ではsvnコマンドを叩いています。
http://www.redmine.org/projects/redmine/repository/revisions/4066/entry/trunk/app/controllers/users_controller.rb

TortoiseSVNとEclipseでは直接的にはRedmineを経由していないと思います。
SVNリポジトリとそれらの環境のどこかにボトルネックがあるかと思います。

Redmineに限れば、Redmineが動いているマシンのローカルにsvnsyncでリポジトリを
同期させればRedmineのパフォーマンスは解決するかと思います。

[広瀬若葉]

広瀬です。

ご返答ありがとうございます。

> TortoiseSVNとEclipseでは直接的にはRedmineを経由していないと思います。
> SVNリポジトリとそれらの環境のどこかにボトルネックがあるかと思います。

Subversion自体、動作が重いということは多々情報があるのは承知していますし、別の問題の
可能性も別に模索しています。また、直接的に経由はしないということも理解はできます。
しかし、本来はSQLを利用するはずの無い、SVNクライアントからSubversionへアクセスすると
Redmine内部のSQLを引っかき回している事実がある以上、何らかの関連性は否定出来ない
のではないかとおもいますが、この認識間違っていますでしょうか？


> Redmineに限れば、Redmineが動いているマシンのローカルにsvnsyncでリポジトリを
> 同期させればRedmineのパフォーマンスは解決するかと思います。

ちなみにRedmineとSubversionは同一マシン上で動作していますので、ここでsvnsyncを
動作させる意味はありますでしょうか？＜個人的には薄い気がしますけど・・・

[Toshi MARUYAMA]

まるやまです。

On 9月7日, 午後4:07, 広瀬若葉 <wak...@mail.lwtips.org> wrote:
> 広瀬です。
>
> ご返答ありがとうございます。
>
> > TortoiseSVNとEclipseでは直接的にはRedmineを経由していないと思います。
> > SVNリポジトリとそれらの環境のどこかにボトルネックがあるかと思います。
>
> Subversion自体、動作が重いということは多々情報があるのは承知していますし、別の問題の
> 可能性も別に模索しています。また、直接的に経由はしないということも理解はできます。
> しかし、本来はSQLを利用するはずの無い、SVNクライアントからSubversionへアクセスすると
> Redmine内部のSQLを引っかき回している事実がある以上、何らかの関連性は否定出来ない
> のではないかとおもいますが、この認識間違っていますでしょうか？

SVNへコミットのhookとしてRedmineのfetch changesetsをしていますか？
RedmineはDB上にないSVNのコミットをDBに書き込みます。

>
> > Redmineに限れば、Redmineが動いているマシンのローカルにsvnsyncでリポジトリを
> > 同期させればRedmineのパフォーマンスは解決するかと思います。
>
> ちなみにRedmineとSubversionは同一マシン上で動作していますので、ここでsvnsyncを
> 動作させる意味はありますでしょうか？＜個人的には薄い気がしますけど・・・

同じマシン上ではsvnsyncをする必要は無いと思います。
Redmine上でのSVNリポジトリの指定をfile://とすればパフォーマンスは改善するかと思います。

[広瀬若葉]

広瀬です。

素早いご返信ありがとうございます。

> SVNへコミットのhookとしてRedmineのfetch changesetsをしていますか？
> RedmineはDB上にないSVNのコミットをDBに書き込みます。

http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/

上記URL先にある通り、Redmine.jpのブログに掲載されている、0.9以降で利用できる
方法を利用はしています。
当然上記の方法を利用する限り、コミット時にDBに書き込みに行くことは十分承知して
います。私的な推測で申し訳ないですが、fetch changesetsはコミット時に発動するも
のであり、チェックアウト(要するに読込み)時には全く関係は無いのではと思います。

当方の環境で、重くなる現象が発動するのはコミット時ではなく、チェックアウト時に多発
してしまいます。
SVNクライアント(この場合TortoiseSVNやEclipse関係なく)でRedmineと連動している
Subversionリポジトリへ"チェックアウト"する際に、何らかのログ(コミットやhistoryなど)を
読みに行くはずですが、このログとRedmine(正確にはSQL)は関係はありますでしょうか？
もし関係するならば、そこら辺が怪しいと見ているのですが、いかがでしょうか？


> 同じマシン上ではsvnsyncをする必要は無いと思います。
> Redmine上でのSVNリポジトリの指定をfile://とすればパフォーマンスは改善するかと思います。

え～と、すいません。Linux上に立ち上げている場合、file:///指定は出来ましたっけ？

[乳牛]

Redmineを停止した状態でのsvn応答速度はどうですか？

2010/09/07 18:27 "広瀬若葉" <wak...@mail.lwtips.org>:

--
このメールは Google グループのグループ「Redmine Users (japanese)」の登録者に送られています。

このグループに投稿するには、redmine-users-ja@g...

[Toshi MARUYAMA]

まるやまです。

On 9月7日, 午後6:27, 広瀬若葉 <wak...@mail.lwtips.org> wrote:
> 広瀬です。
>
> 素早いご返信ありがとうございます。
>
> > SVNへコミットのhookとしてRedmineのfetch changesetsをしていますか？
> > RedmineはDB上にないSVNのコミットをDBに書き込みます。
>
> http://blog.redmine.jp/articles/redmine-0_9-url-to-fetch-changesets/
>
> 上記URL先にある通り、Redmine.jpのブログに掲載されている、0.9以降で利用できる
> 方法を利用はしています。
> 当然上記の方法を利用する限り、コミット時にDBに書き込みに行くことは十分承知して
> います。私的な推測で申し訳ないですが、fetch changesetsはコミット時に発動するも
> のであり、チェックアウト(要するに読込み)時には全く関係は無いのではと思います。
>
> 当方の環境で、重くなる現象が発動するのはコミット時ではなく、チェックアウト時に多発
> してしまいます。
> SVNクライアント(この場合TortoiseSVNやEclipse関係なく)でRedmineと連動している
> Subversionリポジトリへ"チェックアウト"する際に、何らかのログ(コミットやhistoryなど)を
> 読みに行くはずですが、このログとRedmine(正確にはSQL)は関係はありますでしょうか？
> もし関係するならば、そこら辺が怪しいと見ているのですが、いかがでしょうか？

Redmineとは関係無いです。

>
> > 同じマシン上ではsvnsyncをする必要は無いと思います。
> > Redmine上でのSVNリポジトリの指定をfile://とすればパフォーマンスは改善するかと思います。
>
> え～と、すいません。Linux上に立ち上げている場合、file:///指定は出来ましたっけ？

出来ます。

[広瀬若葉]

広瀬です。

> Redmineを停止した状態でのsvn応答速度はどうですか？

最初に書いた通り、SubversionへのアクセスはApache+mod_dav_svnを利用しており、
認証にはBasic認証なのですが、confファイルを編集し、RedmineのSQLへアクセスし、
認証データとしているため、停止が出来ない状態です。

確かにRedmineを停止した状態での状況は未だ確認をしていないので、する必要が
あるとは思っていますが、現行運用中のためおいそれと停止出来ないのが実情です。

※単にRedmineとなんら連携していないSVNを立ち上げて、アクセスした場合には、
　 チェックアウトは非常にスムーズでした。

以上です。よろしくお願いいたします。

[乳牛]

問題を切り分ける必要があると思います。
認証はmysql が動作していればいいわけで、Redmineは無関係かと思いますが。

2010/09/07 19:04 "広瀬若葉" <wak...@mail.lwtips.org>:

--
このメールは Google グループのグループ「Redmine Users (japanese)」の登録者に送られています。

このグループに投稿するには、redmine-...@googlegroups.com にメールを送信してください。
このグループから退会するには、redmine-users-ja+unsub...

[広瀬若葉]

広瀬です

> Redmineとは関係無いです。

そのようですね。どうやら解決の糸口を見つけられたようです。
Basic認証のセッションがSQLまで連動していないのが原因なようです(401ステータス率が多すぎる理由)
別DBにコピーしたものを利用すると重さが無くなりました。

> 出来ます。

すいません、出来ました。


お手数お掛けいたしました。ありがとうございます。