TeamCity polling for changes makes SVN server unresponsive

2
votes

We have 4 projects in teamcity which are pointing to the same SVN server (CollabNet). Teamcity is set to poll every 60 seconds for changes. It is only bringing down differences when detected and the amount of changes per checkin are pretty small (several files at a time). After several hours of polling, CPU levels are cranked on the SVN server (all related to the process httpd.exe process) and SVN becomes unresponsive. Restarting the SVN service resolves the problem temporarily.

The folks managing SVN insist that TeamCity is causing the issue because of the constant polling. In cooperation, I reduced the polling frequency down to 600 seconds, which has made the issue subside. I feel like there is another problem at hand and TeamCity is merely aggravating the it. I'm not happy with the 10 minute polling cycle because it delays the feedback to the development team. They have already started to go to lunch, rather than wait for the build to begin / complete :(

I could not find anything on the Collabnet forums to examine or address the issue. Does anyone have thoughts on how to find the root cause or suggestions on a resolution? It seems like SVN ought to be able to handle frequent gets.

1
svnteamcity

1 Answers

1
votes

Time to move to GIT.

But yeah SVN tends to have this sort of problems. An alternate option could be to write a SVN post commit hook which will trigger Teamcity builds using Teamcity REST or VCS Update teamcity plugin. And then you can have your polling interval as large as you want as it won't matter. Because post-commit hook will trigger the build as soon as commit happens.