[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Suddenly corrupted Subversion repository.

From: Natalya Pyalling <npyalling_at_valuecommerce.ne.jp>
Date: 2004-05-27 11:21:53 CEST

> -----Original Message-----
> From: John Szakmeister [mailto:john@szakmeister.net]
> Sent: Thursday, May 27, 2004 3:55 AM
> To: Garrett Rooney
> Cc: Natalya Pyalling; users@subversion.tigris.org
> Subject: Re: Suddenly corrupted Subversion repository.
>
> On Wednesday 26 May 2004 19:32, Garrett Rooney wrote:
> > John Szakmeister wrote:
> > > On Wednesday 26 May 2004 05:19, Natalya Pyalling wrote:
> > >>Additional info:
> > >>After issueing 'svnadmin verify' I have in /var/log/messages
> > >>
> > >>May 26 13:11:47 vcs kernel: Out of Memory: Killed process 11822
> > >>(svnadmin).
> > >>May 26 13:11:55 vcs kernel: Out of Memory: Killed process 11558
(sshd).
> > >>May 26 13:12:06 vcs su(pam_unix)[11602]: session closed for user
root
> > >
> > > Oof, that can't be good. Here's what's probably happening.
'svnadmin
> > > recover' grabs an exclusive lock on the repository (I can't
remember
> off
> > > hand if 'svnadmin verify' does the same). If svnadmin is dying
like
> > > this, the exclusive lock is never freed, and the apache ends up
> waiting
> > > for the repository to become free. It, of course, never does.
Hence,
> > > the reason you keep timing out.
> >
> > Umm, I believe that lock should actually be released when the
process
> > exits, we use apr_file_lock to manage the lock, and that just calls
> > flock under the hood, IIRC flock's locks only last until the process
> dies.
>
> It looks like your right... although, APR can use either fcntl() or
> flock()
> depending on the system. Either way, the lock should be released.
>
> Natalya, can you at least take a look at the memory consumption?
>
> -John

This is memory on our server.
[root@vcs root]# free -m
             total used free shared buffers
cached
Mem: 1008 992 15 0 128
558
-/+ buffers/cache: 305 702
Swap: 1027 0 1027

During the problem, I was monitoring the server. So all memory and
100%CPU were used by apache or svnadmin.

May be the problem is located in the size of our repository?
[root@vcs root]# du -sh /var/Repository/repos
2.9G /var/Repository/repos

Natalya.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 27 11:22:51 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.