Bug #40342 | Falcon; big idle spike when running sysbench with 50 million table size | ||
---|---|---|---|
Submitted: | 27 Oct 2008 9:26 | Modified: | 15 May 2009 12:56 |
Reporter: | Xiang Fang | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S5 (Performance) |
Version: | 6.0-falcon | OS: | Linux (RHEL 5.2 x64) |
Assigned to: | Kevin Lewis | CPU Architecture: | Any |
Tags: | F_SCAVENGER, idle spike |
[27 Oct 2008 9:26]
Xiang Fang
[27 Oct 2008 16:26]
Kevin Lewis
I verified this with my own testing a couple weeks ago. If the system if very busy with a lot of threads and one of them calls forceRecordScavenge it cannot get done fast enough to prevent the other threads from doing the same. A forced record scavenge cycle is too long. The forced scavenge needs to be redesigned so that it signals the scavenger thread to start scavenging and then it should loop until it can get the memory it needs. It should not do the scavenge itself. See the ideas in Worklogs 4606, 4477 & 4478 for some other improvements to scavenging.
[7 Jan 2009 7:32]
Kevin Lewis
These idle spikes are caused by all the foreground threads waiting on one foreground thread to do a complete scavenge. The new scavenger will fix this. Each foreground thread that needs record cache memory will signal the background scavenger thread, sleep for 10 miliseconds, and then try again to get memory. It will repeat this 5 times before giving up and returning an out-of-memory error. The background scavenger will prune records if it can and retire records down to the scavenge floor.
[7 Jan 2009 15:45]
Kevin Lewis
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/62571 2958 Kevin Lewis 2009-01-07 Bug#34893, Bug#36700, Bug#40342, Bug#40801 New scavenger code, See WL#4606, WL#4477 & WL#4478 for more info. This is the second full patch of the new scavenger. 1) Separate the two tasks involved in scavenging into A. Pruning old invisible record versions. 1. As part of this task, a survey is taken of records in age groups so that the next step can be done in one pass B. Retiring least-recently-used records from the record cache 2) Watch how much record space is added to the record cache and start a new age group at regular intervals. 3) Put the scavenger into a separate thread that can be signaled when needed. This patch contains many improvements over the last patch including; 1) forcedRecordScavenge is now signalScavenge and the loop is increased to 5 times attempting to get memory from the record cache. 2) Unused code is deleted 3) Integrated with new dependency manager code so that it now uses Transaction::commitId to determine if a record is old enough to be scavenged.
[13 Feb 2009 7:23]
Bugs System
Pushed into 6.0.10-alpha (revid:alik@sun.com-20090211182317-uagkyj01fk30p1f8) (version source revid:olav@sun.com-20090113103017-41jbad7qlvlwpwxh) (merge vers: 6.0.10-alpha) (pib:6)
[15 May 2009 12:56]
MC Brown
An entry has been added to the 6.0.10 changelog: The Falcon storage engine has been updated to incorporate new code for the built-in scavenger service, which handles the caching of records in memory. This fixes a number of different issues related to the visibility of different records during certain operations and improves the memory usage.