Re: Multiple cvs/git mirror tasks?

[Jim Meyering <jim@meyering.net>]

Jason Merrill wrote:

> On 07/13/2012 11:43 AM, Jim Meyering wrote:
>> Those jobs are supposed to be started by these crontab entries:
>>
>> 0-59/15 * * * * sh -c "nice $HOME/bin/mirror-sw lvm"
>> 20-59/30  * * * * sh -c "nice $HOME/bin/mirror-sw binutils"
>> 8-59/30   * * * * sh -c "nice $HOME/bin/mirror-sw gdb"
>> 14        * * * * sh -c "nice $HOME/bin/mirror-sw newlib"
>
> It seems that when the machine is heavily loaded one of these jobs can
> take more than the allotted time, which is why I was seeing three of
> them (including two for gdb) running at the same time; it would
> probably be good to use a mkdir mutex to make sure that you only have
> one running at a time.

Hi Jason,

It is not uncommon (particularly after a tagging) for a gdb or binutils
mirror-sw run to take much longer than the usual minute or two. When
that happens or when the system is overloaded, you may see concurrent
runs for two or more projects.  However, that is not the norm.

For example, I see that just as I started writing this, the gdb sync
started [btw, it completed in under a minute]:

    meyering  7750  0.0  0.0  2720  904 ?        SNs  15:38   0:00 /bin/sh
      /home/meyering/bin/mirror-sw gdb
    meyering  9407  0.0  0.0  2720  412 ?        SN   15:38   0:00 /bin/sh
      /home/meyering/bin/mirror-sw gdb
    meyering  9408  0.0  0.0  2720  512 ?        SN   15:38   0:00 /bin/sh
      /home/meyering/bin/mirror-sw gdb

At first glance, you may think there are three invocations of the script,
but as recently discussed here, that's merely due to a subshelled
pipeline in the script: each element of the pipeline ends up looking
(in ps output) like another invocation of the parent script.  It really
was invoked only once.

I'm leery about adding naive cross-project locks, because that could
let a busy project starve one that needs only a tiny update.

Using lockfile(1) and a timeout might help.

I could add a per-project locking mechanism to prevent e.g., two gdb
syncs from running in parallel when the first one takes more than the
30m between cron invocations.  That could save some system resources,
but would not improve correctness or integrity.

For starters, I've instrumented mirror-sw with code to record the
duration of each run from now on.  You can see some numbers already:

    sourceware$ tail ~meyering/log/*
    ==> /home/meyering/log/gdb <==
    2012-07-20-16:10:00 5

    ==> /home/meyering/log/lvm <==
    2012-07-20-16:15:17 16

    ==> /home/meyering/log/newlib <==
    2012-07-20-16:14:28 27

Let's see if/when things overlap.

Besides, I've heard there might be a hardware upgrade coming...
That might make performance-related tweaks premature.