Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for disk size growth in high insert / delete environment #37

Merged
merged 97 commits into from Dec 8, 2011

Conversation

cwolfinger
Copy link

Since I work on a high insert / delete application the issue with mongodb disk space has become a large problem. I did some testing on v1.8 of the following changes that adds a new command line option to allocate to the next closest bucket size used by the freelist. In my testing, this has eliminated the disk growth in a high insert / delete environment. The test program I wrote basically executes the following algorithm:

  1. Setup a new collection - with 1 additional index (besides the _id).
  2. Execute 100,000 inserts on an increment key - the payload is a random sized byte array from 800 - 3800 bytes
  3. Execute 100,00 deletes to remove the records.
  4. Repeat this over and over again

With the patched version the number of extents and allocated space stayed constant and the non-patched server grows from 368,078,848 to 1 GB.

erh and others added 26 commits August 16, 2011 14:05
…nection, not replica set connection SERVER-3683

Conflicts:

	s/shard_version.cpp
…es array

in the replica set monitor.  SERVER-3605
…are in flight.

also correct UpdateResult in one case

Conflicts:

	db/oplog.cpp
	db/repl/rs_sync.cpp
Conflicts:

	db/repl/rs_sync.cpp
Conflicts:

	db/repl.cpp
	db/repl.h
	db/repl/rs_sync.cpp
@gregstuder gregstuder merged commit 0524f59 into mongodb:v1.8 Dec 8, 2011
@cangove
Copy link

cangove commented Mar 23, 2012

It seems this was merged into 1.8.5. The above description indicates, "new command line option" to control this behavior but in the code diff I do not see a command line change related to this. Is there a command line flag? Is there any reason not to always do the new approach and avoid deletes not freeing space?

puppyofkosh added a commit that referenced this pull request Feb 12, 2019
…f invocation)

Original commit message from timelib:
Fixed #37: Incorrect snprintf invocation with static buffer
puppyofkosh added a commit that referenced this pull request Feb 12, 2019
…f invocation)

Original commit message from timelib:
Fixed #37: Incorrect snprintf invocation with static buffer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
8 participants