MongoDB's freelist algorithm separates deleted records by their size and adds them to corresponding linked lists. When searching for an appropriately sized free record, the algorithm scans a linked list for up to 30 elements, then skips to the next list with bigger elements.
Due to a logical bug in the freelist handling code, the linked list containing the largest blocks of space (>8MB) did not stop scanning after 30 elements and would continue scanning until the end of the list, which can have a negative impact on performance.
For users with very large documents (>8MB) and heavy insert/update/delete workloads, the excessive freelist scanning for the largest blocks of free space can impact performance.
All versions of MongoDB up to 2.6.1 are affected.
The fix is included in the 2.6.2 production release.
The MaxBucket is now included in the shortcut condition that moves to the next linked list.
The freelist search doesn't stop after 30 entries when searching the MaxBucket.
"b < MaxBucket" should be "b <= MaxBucket" (credit eliot)
- is related to
SERVER-14081 Freelist improvements