On Thu, Jan 10, 2013 at 12:32 PM, Michai Ramakers <m.ramak...@gmail.com>wrote:
> ah yes... forgot that :) It does not help. Note that taking 1 cpu core
> offline ('cpuctl offline 1' here) makes it fly
>
This is just pure speculation, but ... perhaps there is a problem in BSD
multi-core cases, such that the various requests made by fossil for cloning
do not get closed/killed immediately, and each request is locking the db
for longer than it should because its process it not being killed in a
timely manner? It would be interesting to see if, when you see the
hang-ups, if the child process forked for handling a request is still alive
(on the other CPU) for a while after the subsequent request has already
started.
i.e... clone request 1 comes in and completes, but its process (or flock)
is not closed/released in a timely manner. Then comes clone request #2,
which is waiting on an flock which is still held by request 1. Ad nauseum
for requests #3 to #N. The output of "lsof the_repo_file" might be useful
here.
(Again, purely speculation...)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
