[SERVER-4457] avgObjSize didn't shrink as expected after updating documents and compacting Created: 08/Dec/11 Updated: 29/Feb/12 Resolved: 11/Dec/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dan Spinosa | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
3 mongo production cluster on Unbuntu 10.10 cloud machines |
||
| Operating System: | Linux |
| Participants: |
| Description |
|
I recently transitioned a collection (> 30MM documents) from long, human readable key names to short, 1 character keys to save on storage space (on disk and in memory) & improve performance. I dropped the old indexes, ran a big db.mycollection.update( {...}), compacted the collection (on primary and 2 replicas) then built new indexes. The storageSize and totalIndexSize were cut in half (about what I expected). But avgObjSize hasn't change significantly for that collection! I've also noticed that paddingFactor is significantly different on each server (1.01, 1.49 on replicas, 1.36 on primary). Why wouldn't the avgObjSize drop by about half? --- PRIMARY> db.broadcasts.stats() , --- PRIMARY> db.broadcasts.stats() , |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 11/Dec/11 ] |
|
Running compact would do it. |
| Comment by Dan Spinosa [ 08/Dec/11 ] |
|
Is there any way to force a paddingFactor re-calculation? Seems like documents (particularly new ones) are using significantly more space than necessary under the above conditions... |
| Comment by Eliot Horowitz (Inactive) [ 08/Dec/11 ] |
|
avgObjSize includes padding - so making documents smaller doesn't change this. |