[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. 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 |