GNOME Bugzilla – Bug 384372
Subversion commits getting slower
Last modified: 2011-03-22 10:03:36 UTC
On Tue, 3 Oct 2006, Tim Janik wrote: > hey Ross. > > SVN committs have been getting slower and slower over time. > at this point, even committing a small fix takes several minutes > to complete. > > on the client side, it looks like this: > > File svn-commit.tmp saved. > Sending sfi/ChangeLog > Sending sfi/Makefile.am > Deleting sfi/testcxx.cc > Sending sfi/tests/Makefile.am > Adding sfi/tests/testcxx.cc > Transmitting file data .... > [hangs for multiple minutes] > > watching the server via top and pstree reveals that the actual commit > is handled in an ok time, svn then just hangs in python for several minutes: > +--sshd(26060)-----sshd(26062)---svnserve(26064)---post-commit(26085)---common-post-com(26086)---python(26101) > the python processs just sitts there, blocking/idling for several minutes: > > 26101 timj 25 0 3408 3404 1948 S 0.0 0.0 0:00 0 python > > (btw, pstree on container sucks since it doesn't honour stdout being > a pipe or react to TERM=dumb, it still sends terminal escapes) > > then, several minutes later (maybe due to a timeout): > > Transmitting file data .... > [hangs for multiple minutes] > Committed revision 3929. > > Olav says that upgrading svn might help since newer versions could > be faster, and he also mentioned that the SVN we're using might be > incompatible with python <2.4, and thus could be causing the hangs... one thing i have to add is, messages on #commits also appear very late. maybe 30 or so minutes after the actual commit finished. just a week or so ago, this happened instantly (much to my surprise actually which is why i remember so well). so it's probably not just package versioning, but might be some change that happened to container in the meantime.
this is apparently not always reproducable. since the initial report of this issue, i have encountered more instant commits and more commits that took several dozens of seconds, sometimes minutes. i've meanwhile confirmed what's described above only implicitely, i.e. the actual server side svn commit handling is always pretty fast, it's just some python post-commit script that keeps hanging for sometimes very long times. i.e. client side, cancelling commits that last much too long may work as a workaround, because server side, cancelled commits only ever cancel the slow post commit scripts *after* the commits have been properly applied to the repositories.
About a week ago, I added a '&' to the end of the ciabot_svn.py line in the post-commit script, so it should no longer be hanging at this point. Have you noticed any particularly slow commits in the last week?
(In reply to comment #2) > Have you noticed any particularly slow commits in the last week? no. i have seen occasional lag in commit notifies getting delivered on #commits, but not really slow commits. so far, it seems like only ciabot_svn.py has caused any lag. sometimes the commit messages on #commits were delivered really late though (30+ minutes?), so debugging the fishiness of that script at some point would still be good ;)
This bug was filed when svn was running on container, machine on which everything is ancient. After the move to socket, I haven't seen slowdowns, not even for commit messages to show up on #commits. Can this be closed?
(In reply to comment #4) > This bug was filed when svn was running on container, machine on which > everything is ancient. the machine hardware was definitely not the problem, the machine was idling while the processing of the commit script was stuck. > After the move to socket, I haven't seen slowdowns, not > even for commit messages to show up on #commits. > > Can this be closed? i haven't seen this since the whole GNOME repo moved to SVN, and we can always reopen the bug if the delays can be reproduced, so closing for the moment.