Skip to content

db: manually managed memTable arena memory #527

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

Merged
merged 1 commit into from
Feb 13, 2020

Conversation

petermattis
Copy link
Collaborator

No description provided.

@petermattis
Copy link
Collaborator Author

This change is Reviewable

@petermattis
Copy link
Collaborator Author

I extracted the memTable memory management commit from #523. All but the last commit here are the commits in #523.

@petermattis petermattis force-pushed the pmattis/memtable-memory branch from 2cd7183 to fdc5abb Compare February 12, 2020 20:02
Copy link
Collaborator Author

@petermattis petermattis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ready for a look.

Reviewable status: 0 of 6 files reviewed, 1 unresolved discussion (waiting on @itsbilal and @sumeerbhola)


open.go, line 64 at r1 (raw file):

		// allocated memory resources. Note that rather than look for an error, we
		// look for the return of a nil DB pointer.
		if r := recover(); db == nil {

This was probably the trickiest part of the change: properly performing cleanup during the various error conditions that can occur during Open. Something similar showed up in #529.

@petermattis petermattis force-pushed the pmattis/memtable-memory branch 2 times, most recently from 1643a3e to aecc9c4 Compare February 12, 2020 20:11
@petermattis
Copy link
Collaborator Author

The first commit is #529 which is needed for all of the test changes to properly close DBs.

@petermattis petermattis force-pushed the pmattis/memtable-memory branch 2 times, most recently from 6ad5a30 to a0d9a1c Compare February 13, 2020 16:34
@petermattis
Copy link
Collaborator Author

This has been rebased now that #529 has been merged.

Copy link
Collaborator

@sumeerbhola sumeerbhola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 32 of 41 files at r2, 6 of 6 files at r3.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @itsbilal and @petermattis)


mem_table.go, line 42 at r3 (raw file):

// A memTable is implemented on top of a lock-free arena-backed skiplist. An
// arena is a fixed size contiguous chunk of memory (see
// Options.MemTableSize). A memTable's memory consumtion is thus fixed at

nit: consumption


mem_table.go, line 49 at r3 (raw file):

// A batch is "applied" to a memTable in a two step process: prepare(batch) ->
// apply(batch). memTable.prepare() is not thread-safe and must be called with
// external sychronization. Preparation reserves space in the memTable for the

nit: synchronization


internal/arenaskl/arena.go, line 43 at r3 (raw file):

)

// NewArena allocates a new arena of the specified size and returns it.

comment is stale

@petermattis petermattis force-pushed the pmattis/memtable-memory branch from a0d9a1c to 8a09a3a Compare February 13, 2020 21:26
Copy link
Collaborator Author

@petermattis petermattis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @itsbilal and @sumeerbhola)


mem_table.go, line 42 at r3 (raw file):

Previously, sumeerbhola wrote…

nit: consumption

Done. Apparently, I need to use spellcheck on my comments.


internal/arenaskl/arena.go, line 43 at r3 (raw file):

Previously, sumeerbhola wrote…

comment is stale

Done.

@petermattis petermattis force-pushed the pmattis/memtable-memory branch from 8a09a3a to 9f89954 Compare February 13, 2020 21:42
@petermattis
Copy link
Collaborator Author

TFTR!

@petermattis petermattis force-pushed the pmattis/memtable-memory branch from 9f89954 to 317978e Compare February 13, 2020 21:50
@petermattis petermattis force-pushed the pmattis/memtable-memory branch from 317978e to 99983b9 Compare February 13, 2020 22:00
@petermattis
Copy link
Collaborator Author

I had to add a few test-only fixes to missed Cache.Unref() calls. Not sure why these popped up now and not in #529. Oh well, they were easy to find. go test -count 100 was helpful in sussing these out.

@petermattis petermattis merged commit b9b70cf into master Feb 13, 2020
@petermattis petermattis deleted the pmattis/memtable-memory branch February 13, 2020 22:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants