randgen team mailing list archive

[Roel Van de Paar <roel.vandepaar@xxxxxxxxxxx>]

Hi John,

On Fri, Sep 27, 2013 at 5:47 PM, John Embretsen <johnemb@xxxxxxxxx> wrote:

> On 09/26/2013 03:13 AM, Roel Van de Paar wrote:
>
>> Just a quick note to let you know I am looking into patching RQG so that
>> runaway simplifications can no longer cause excessively long 'trials'/runs
>> (for example runall.pl <http://runall.pl> runs) - i.e. trials which
>>
>> disregard the --duration=x
>> setting completely.
>>
>> For example, in some recent runs where the trial duration was a maximum
>> of 5 minutes (--duration=300), the trial ended up lasting more than 5
>> hours
>> due to a simplification "ongoing" (RQG currently fails to check the
>> --duration
>> value when it's simplifying).
>>
>> A solid patch is now available. It will be well-tested and, if no
>> objections to
>> the contrary are received, implemented in the coming week.
>>
>
> Thanks for the heads up. What about:
>
>  - When will such duration checks occur?
>    Today it happens after each execution of "original"
>    statements from the grammar. One such execution includes any
>    validation, simplification, etc.
>    After each statement execution, regardless of source (grammar,
>    simplifier, validator, reporter)?
>    After each simplification round as well as after each
>    execution of "original" statements?
>
>  - Will it be a soft limit, like today (only take action after
>    the execution has finished), or do you plan to add a hard limit as
>    well (e.g. kill ongoing executions)?
>
>  - What about the data generation phase? That is not currently
>    included in the --duration timing. Do you plan to change that,
>    or add additional limits that include gendata? Or is this change
>    limited to simplifications only?
>
> Depending on what is planned users may need to take action, so a few more
> details may be good.


Thank you for your email

1- The checks are more frequent then a simplification round, but they
aren't after every statement execution, and the check after each
original statement has been kept.  In particular, the new checks occur in
Simplifier/Tables.pm and at the start of the query: loop in Mixer.pm.

2- I think it's fair to say that this is somewhere in between a soft and
hard limit, in the sense that no running queries are going to be
terminated by this check, but if the check gets triggered in either
place, the execution will end as quickly.

3- We don't have any plans to add anything like this for the data
generation phase (which has always been seperate from --duration
as you rightly say). This patch was really intended just to solve the
particular problem of runaway trials.

Thanks

-- 

Kind Regards,
God Bless,
-- 
Roel Van de Paar, CMDBA/CMDEV  Director of Development Services, Percona LLC
Tel: +61 2 8004 1288 (UTC+10)
Mob: +61 427 141 635 (UTC+10)
Skype: roel.mysql
http://www.percona.com/services.html
http://www.mysqlperformanceblog.com/