Bug #59484 RQG: performance_schema.yy too big space consumption
Submitted: 13 Jan 2011 20:15 Modified: 13 Jan 2011 20:15
Reporter: Matthias Leich Email Updates:
Status: Analyzing Impact on me:
Category:Tests: Server Severity:S7 (Test Cases)
Version:5.6.2-m5-debug-log OS:Any
Assigned to: Bernt Marius Johnsen CPU Architecture:Any

[13 Jan 2011 20:15] Matthias Leich
Result when running RQG tests with grammar performance_schema.yy
and moderate values for parameters
   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
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
   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.
[13 Jan 2011 20:20] Matthias Leich
configuration for bug hunt

Attachment: bughunt_trunk_1.cfg (application/octet-stream, text), 8.48 KiB.