I don't want to make a hard claim here, but the past three of these
annoying Berkeley DB_INCOMPLETE errorful states or our repository that
I have actually taken the time to investigate have all shows signs of
failing during the handling of a REPORT request when more than
checkout/update/status/REPORT-y-thing was happening simultaneously. I
am very concerned that our repository can't handle much more than (if
even) two simultaneous HTTP checkouts.
Tonight, I had a commit fail because the repos was jammed up again. I
brought down httpd, made sure no processes were running, removed
Berkeley 4.1 from the system entirely (even though it wasn't supposed
to have been being used at all), and did a "distclean" build of
Subversion on that box. After installing and recovering the
repository, I restarted Apache. Checking the logs showed that, again,
something went wrong when two folk were hard fetching lotsa files from
the repository, then one one of their REPORTs failed, and the other
failed soon after.
So, on my laptop at home, I started two simultaneous checkouts of the
root of our tree, just to see if I could get the sucker to hang again.
Sure enough, it hung not too terribly far into the checkouts. It
wasn't a pure test because someone else happened to send a few
requests into the server during my checkouts. So, I dunno if the
problem was with the checkouts, the "other stuff", or the combination
of it all.
Then I put a copy of the Subversion repository on my laptop, exposed
via HTTP (same version of httpd and Berkeley DB as svn.collab.net),
and did two simulaneous checkouts on another box from my laptop's
server. These didn't seem to have a problem. I even browsed this
copy of the repos in ViewCVS (which is rumored to be such a problem, I
hear), intentionally throwing every type of Exception I know how to in
that tool -- and my checkouts still kept on going!
Oh! Wait! They both just died! (I though my hard disk sounded kinda
quiet...). Ran out of locks two checkouts!
Folks, this is utter badness.
I'm not going to be hacking for the next week or so -- Ben or Karl
will have to be your repository saviours during that time period.
Until we figure out how to fix this problem ... um ... don't checkout
anything. :-)
(Seriously, I would really like someone to start spending some real time
trying to diagnose and fix this problem -- in my opinion, this is a
higher priority than any other currently known perf/scalability bug).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 29 06:38:22 2003