Re: svn.collab.net repos failures.

"Sander Striker" <striker@apache.org> writes:

> I'll give the subversion dataset a go to see if that makes a difference.

Sander and I have been testing this morning, and I'm able to reproduce
the repsitory 'hang' very, very easily. Here's my recipe:

* I'm running httpd-2.0.47 on http://localhost, and I'm exporting a
  personal copy of svn's own repository at /svn/bigrepos.

* I start three svn clients, have them each checkout
  http://localhost/svn/bigrepos/trunk simultaneously.

* After about a minute, all clients hang indefinitel. The apache
  access_log's last entry is

   127.0.0.1 - - [29/Aug/2003:08:56:15 -0500] "GET
           /svn/bigrepos/!svn/ver/6741/trunk/notes/fs_dumprestore.txt
           HTTP/1.1" 500 308

  And the last error_log entry is

   [Fri Aug 29 08:56:15 2003] [error] [client 127.0.0.1] (2)No such
     file or directory: Berkeley DB error while reading representation
     for filesystem /usr/local/svn/bigrepos/db:
    Cannot allocate memory [500, #160029]

* Interestingly, the repos doesn't seem wedged. While the three
  clients are "frozen", I'm still able to do an 'svn ls' on the
  repository over both ra_local and ra_dav. And after the three
  clients time out, my 'ls' commands still work as well.

* In a repeat of the experiment, I sent a SIGTERM to the clients after
  they were frozen. This *did* cause my repository to require
  recovery. Not sure why.

According to sander, the memory error indicates we're running out of
locks. My DB_CONFIG file has the default number of locks:

         set_lk_max_locks 2000
         set_lk_max_lockers 2000
         set_lk_max_objects 2000

This looks like a major scalability bug -- a big regression.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 29 16:14:09 2003