Description:
Result when running RQG tests with grammar performance_schema.yy
and moderate values for parameters
queries=10000
threads=16
mysqld=--log-output=none
vardir and tmpdir are on tmpfs (2 GB)
against mysql-trunk-bugfixing ~ July 2010:
RQG reports sooner or later a server crash (101) or
database corruption (105) because of known bugs.
I cannot remember that I have ever seen tmpfs full.
Result when running with the same conditions +
even drastic reduced values for performance_schema
related variables
Example:
performance_schema_events_waits_history_long_size=100
instead of 10000 (default)
on mysql-trunk revno: 3478 2011-01-10
RQG reports nearly all time database corruption (105).
The reason seems to be in most if not all cases
tmpfs full.
When using tmpdir and vardir on a sufficient big disk
based filesystem the maximum space consumption I
observed was > 2.4 GB.
We must know if the excessive space consumption
is caused by probably unknown server bugs.
If there are no unknown server bugs than the
grammar must somehow ensure that space consumption
stays in an acceptable range.
How to repeat:
I will add my script for bug hunting which
includes my settings soon.
nice -20 perl util/bughunt.pl --config=bughunt_trunk_1.cfg
Suggested fix:
The maximum space consumption should be <= 1.5 GB
so that the test can be used on average developer
boxes with tmpfs.
In order to reach this it needs to be figured out
why the space consumption is so dramatic.
Some hypothesis:
1. Defaults of performance_schema system variables were
raised or the system collects now more data from
whatever other good or bad reason.
It needs to be ensured that the test runs with
values of performance_schema related server
system variables which are clear below the defaults
but do not violate the purpose of the test.
Also the frequency of TRUNCATE <pfs table> might be
increased.
Maybe some part of the problem resides here.
2. Maybe we have a bug causing that the space for
temporary tables, intermediate results or similar
is never or far way too late freed.
3. Maybe the optimizer chooses unfortunate execution
paths which cause this excessive space consumption.
