[SERVER-38270] Weird behavior in caching collections with different average size documents in MongoDB Created: 27/Nov/18  Updated: 06/Dec/22  Resolved: 17/Apr/19

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: 4.0.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Moditha Assignee: Backlog - Storage Engines Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Attachments: PNG File image-2018-12-05-12-18-28-817.png    
Issue Links:
Duplicate
duplicates WT-4732 Remove the bias from the eviction pol... Closed
Assigned Teams:
Storage Engines
Operating System: ALL
Steps To Reproduce:
  • I have tested this in 4.0.2.
  • Create few large collections with different average document sizes (same number of documents)
  • do random acces with same frequency to them until the cache gets full and eviction takes place
  • check the stats of each of the collection (wiredTiger.cache.bytes currently in cache)
  • larger collections will have a smaller memory footprint
Participants:

 Description   

When collections with different average sized documents (x,2x,3x,4x,5x) but having same number of documents within them the cache is behaving differently than expected. Before the eviction takes into place the distribution of the cache for the data is as follows. ( The collections are accessed in the same frequency and the memory is smaller than the collections)

This is the expected behavior as bigger sized documents mean bigger memory footprint. But, after the cache eviction takes place the distribution of the cache is as follows.

This means the eviction policy is evicting more of the bigger collection and giving priority to smaller ones (the opposite trend)



 Comments   
Comment by Sulabh Mahajan [ 17/Apr/19 ]

I am closing this ticket because WT-4732 has been filed to address this issue. Addressing this issue will not require a server change, hence a WT ticket is more appropriate.

Comment by Moditha [ 18/Dec/18 ]

Just for future reference. It is not the creation time but rather the name of the collection. I guess the eviction takes place in some order (alphabatical) of the collections. Therefore somehow the latter collections gets evicted more. Maybe a random pick would be better if the collections are picked in an order

Comment by Moditha [ 05/Dec/18 ]

 
I tried with the same document size, count, and the frequency of access to 5 different collections and checked the cache usage at the end. It seems like the issue is there in the same manner. The collections are identical except for few seconds delay at the creation time. The creation time seems to have some effect on the cache proportion. Older collections get more cache than newer ones. But, this is just my idea
 

 

Generated at Thu Feb 08 04:48:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.