latest status

The Karl/Mike fix for svndiff stream parsing seemed to have done the trick.
While they reported "it didn't", my testing has shown that it *did*. The
repro script that I posted a little while ago now succeeds.

Given that, I began running the mass-commit script again. We still have the
two remaining problems:

* WC locks bugging up the commits
* the DB_INCOMPLETE thang

The latter is actually posing a significant problem now. I kept running out
of disk space on my box (meager disk for the moment). So I went and started
tossing the DB logs while the script was running. But it didn't seem to
help...

I also noticed the Apache memory slowly increasing. Dunno if it was simply
representing the high-water mark of memory usage, or if there is an actual
problem in there, but it was there.

That led me to investigate Apache's memory usage a bit. I figured maybe it
was opening some anonymous memory maps, thus consuming disk space, and also
reflecting in the memory page. Well... a simple "ls -l /proc/PID#/fd" ought
to show me the mmaps.

Oops! What I found instead was a number of file descriptors pointing to the
DB files. These leaked file descriptors also referenced the log files which
I was trying to delete... Of course, the system still referred to them, so
they were still using disk space.

[ the neat part is that I "gracefully" restarted Apache in the middle of the
  mass-commit. it tossed all those file descriptors and the mass-commit
  didn't even flinch while Apache was restarting (actually, clients never
  see apache go down when it does a graceful restart, so I wasn't
  surprised... but cool nonetheless) ]

After the graceful restart, the logs went "poof" and the disk space was back
to normal.

I am now suspecting the leaked descriptors are because we bail out during
the DB->close routines. When one of them returns DB_INCOMPLETE, I think the
logic just bails out (gotta go look).

Regardless of what is happening, we have to get those descriptors closed. We
can't be leaking descriptors on the server like that. So... that is my
current task.

Does anybody have any particular information on receiving DB_INCOMPLETE from
a db->close operation? When we get that from txn_checkpoint(), we sleep for
a second and then try again. Should we do the same for a close? Should we
simply ignore it and move along?

I'll be trying some of these things, but hints from other people would give
me a nice head start.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org