On Thu, Jan 10, 2013 at 12:21 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 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...)alright, worth a shot (but not now immediately). Update: I see the slowness-issue happening now with only 1 core enabled, too... sigh :) Michai _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
