[SERVER-66] do memcmp before memcpy for update? Created: 21/May/09  Updated: 19/May/14  Resolved: 22/May/09

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

Type: Improvement Priority: Minor - P4
Reporter: Eliot Horowitz (Inactive) Assignee: Dwight Merriman
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

should we compare the old and new objects an update before writing?

what i'm thinking is that if we're writing the same object out - it may incur a dirty bit set on the page when it doesn't need to be.
which could lead to more disk activity.

we'll already have to read the page in - so its just the comparison that we add. and we only have to do it if they are exactly the same size. my guess is if the object changes - most of the time the size will change anyway.



 Comments   
Comment by James Blackburn [ 25/Sep/13 ]

This would fix a major performance issue we're seeing.

We have a schema, much like gridfs, the main differenced is that chunks are sha'd and shared by multiple versions of a 'file'. The chunks have an indexed parent array field, so fetching data is fast, and data is de-deduped on insert.

When it comes to deleting versions of a 'file', however we see huge I/O load as all the chunk data is re-flushed to disk. We could construct our schema such that the only the last field of the chunk doc changed - i.e. the parents field. It would be nice if only the few pages that need to be changed are written back as this can effectively DOS our Mongo cluster.

Comment by Dwight Merriman [ 22/May/09 ]

madness

Generated at Thu Feb 08 02:52:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.