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