On Thu, 10 Jan 2013 13:21:50 +0100 Stephan Beal <[email protected]> wrote:
> On Thu, Jan 10, 2013 at 12:32 PM, Michai Ramakers <[email protected]>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...) If he tries in shell 1 fossil open repository fossil server and in shell 2 fossil clone http://localhost:8080/ copy.fossil should workaround it, the repository is opened only once > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal --- --- Eduardo Morras <[email protected]> _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
