Project

General

Profile

Forums » Help »

fetch_changesets with gitosis is too slow under 1.2.1

Added by Jonas Juselius over 13 years ago

Until yesterday we were running redmine 1.1.3. It worked, but git(osis) repository browsing was a bit slowish. Then we upgraded to 1.2.1, and while everything else works, repository browsing is totally crippled. First I had to disable autofetching, since it was seemingly hanging. Then I tried to run Repository.fetch_changesets by hand. It seemed to work and spewed out git messages for a few hours(!) until it was done. The next time I ran it, it "only" ran for 3-4 minutes. The problem is that it seems it has missed some commits, since they don't show up in the repository browser(s). I also added a fetch_changesets script to cron, and ran it every 15 minutes. After a few hours there were many unfinished fetches stuck on the server. In the end I had to kill redmine, all the ruby and git processes in order to get things to normalize. Then I tried to run fetch_changesets by hand again, and it has now been chewing on the days commits for one and a half hours, and it's not finished yet... The thing is, we are not even running a big site. We have approximately 50 small projects, and a few bigger ones with 200 000+ lines of code, with some years worth of commit logs. We normally receive < 100 commits/day in total. It should be peanuts. We really like Redmine, but this is really totally useless, and we will have to revert to the old version.

Best regards, Jonas Juselius


Replies (6)

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Jonas Juselius over 13 years ago

Oh, and I should mention that I am aware of (at least some of) the existing bug/defect reports related to this issue. What worries me is that nobody seems to be doing anything about it...

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Reinis Veips about 13 years ago

I was bitten by this issue as well. I upgraded from 1.1.1 to latest development release this morning.
It seems to hang on the repository parsing, as I am using local copies of repositories that are updated before running:

ruby script/runner "Repository.fetch_changesets" -e production

Is anyone aware, which is the most recent version that does not have this problem, so I can downgrade to that one.

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Jonas Juselius about 13 years ago

I solved the problem by migrating from gitosis to gitolite and changing from redmine_gitosis to redmine_git_hosting. Works like a charm, and it's really fast and responsive. gitolite is far, far superior to gitosis. The major issue is that the existing SSH keys are difficult to migrate automatically. We had to ask our users to re-register their keys after the upgrade.

Beware if you switch: It's not entirely trivial, and there are some bugs which can bite you. I had to do some sql editing by hand to get everything in place. The bugs have been reported, and will hopefully be fixed soon.

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Reinis Veips about 13 years ago

Thanks for your reply. I manage gitosis instance myself, so I'm now not so sure if my problem is related to your one. As I mentioned, the repositories redmine scans for commits are local- so I doubt that this is issue with gitosis or any other git hosting tools.

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Nicholas Kulikov about 13 years ago

Jonas Juselius wrote:

Beware if you switch: It's not entirely trivial, and there are some bugs which can bite you. I had to do some sql editing by hand to get everything in place. The bugs have been reported, and will hopefully be fixed soon.

Thanks for you feedback! We also thinking about migration from redmine_gitosis (very slow in our environment) to redmine_git_hosting. You information is valuable!

RE: fetch_changesets with gitosis is too slow under 1.2.1 - Added by Jonas Juselius about 13 years ago

The migration is a bit painful currently, but 100% worth it. If you run into problems, please let me know, and I'll try to help to the best of my abilities. If you have a busy production environment with lots of users, I recommend cloning your environment on a virtual machine and test things out first. Good luck!

    (1-6/6)