Bug #49675 Metadata caching is not optimal
Submitted: 14 Dec 2009 14:39
Reporter: Philip Stoev Email Updates:
Status: Verified Impact on me:
Category:Tools: Random Query Generator Severity:S3 (Non-critical)
Version:2 OS:Any
Assigned to: Bernt Marius Johnsen CPU Architecture:Any

[14 Dec 2009 14:39] Philip Stoev
As discussed previously, proper metadata caching means that the I_S query is issued only once per test, and the resulting data is inherited by all RQG children.

The current implementation issues one I_S query per RQG process, meaning that higher values for --threads (say 100) incur a sufficient startup cost, up to the point that a fake server deadlock situation is reported.

How to repeat:
Run a test with --threads=100 . Observe how much time it takes for the actual test to begin. Observe SHOW PROCESSLIST.

Suggested fix:
Issue the I_S query and cache the result before the fork() so that each child will inherit the data.

In general, we should keep the RQG operational at higher thread counts, which means low CPU usage, as much memory sharing as possible and as fast thread startup times as possible.
[14 Dec 2009 14:44] Bernt Marius Johnsen
Agree. But a major restructuring is needed. I had hoped to do this AFTER new server objects have been implemented.