2015-04-10 03:01:11 +02:00
|
|
|
// Copyright (c) 2015, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under the BSD-style license found in the
|
|
|
|
// LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
// of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
#include <algorithm>
|
2015-04-10 03:01:11 +02:00
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
#include "db/memtable_list.h"
|
|
|
|
#include "db/merge_context.h"
|
|
|
|
#include "db/version_set.h"
|
|
|
|
#include "db/write_controller.h"
|
|
|
|
#include "db/writebuffer.h"
|
|
|
|
#include "rocksdb/db.h"
|
|
|
|
#include "rocksdb/status.h"
|
2015-06-08 20:43:55 +02:00
|
|
|
#include "util/string_util.h"
|
2015-04-10 03:01:11 +02:00
|
|
|
#include "util/testharness.h"
|
|
|
|
|
|
|
|
namespace rocksdb {
|
|
|
|
|
|
|
|
class DumbLogger : public Logger {
|
|
|
|
public:
|
|
|
|
using Logger::Logv;
|
|
|
|
virtual void Logv(const char* format, va_list ap) override {}
|
|
|
|
virtual size_t GetLogFileSize() const override { return 0; }
|
|
|
|
};
|
|
|
|
|
|
|
|
class MemTableListTest : public testing::Test {
|
|
|
|
public:
|
|
|
|
std::string dbname;
|
|
|
|
DB* db;
|
|
|
|
Options options;
|
|
|
|
|
|
|
|
MemTableListTest() : db(nullptr) {
|
2015-04-10 07:11:35 +02:00
|
|
|
dbname = test::TmpDir() + "/memtable_list_test";
|
2015-04-10 03:01:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create a test db if not yet created
|
|
|
|
void CreateDB() {
|
2015-04-10 07:11:35 +02:00
|
|
|
if (db == nullptr) {
|
2015-04-10 03:01:11 +02:00
|
|
|
options.create_if_missing = true;
|
|
|
|
DestroyDB(dbname, options);
|
|
|
|
Status s = DB::Open(options, dbname, &db);
|
|
|
|
EXPECT_OK(s);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
~MemTableListTest() {
|
|
|
|
if (db) {
|
|
|
|
delete db;
|
|
|
|
DestroyDB(dbname, options);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Calls MemTableList::InstallMemtableFlushResults() and sets up all
|
|
|
|
// structures needed to call this function.
|
|
|
|
Status Mock_InstallMemtableFlushResults(
|
|
|
|
MemTableList* list, const MutableCFOptions& mutable_cf_options,
|
|
|
|
const autovector<MemTable*>& m, autovector<MemTable*>* to_delete) {
|
|
|
|
// Create a mock Logger
|
|
|
|
DumbLogger logger;
|
|
|
|
LogBuffer log_buffer(DEBUG_LEVEL, &logger);
|
|
|
|
|
|
|
|
// Create a mock VersionSet
|
|
|
|
DBOptions db_options;
|
|
|
|
EnvOptions env_options;
|
|
|
|
shared_ptr<Cache> table_cache(NewLRUCache(50000, 16));
|
|
|
|
WriteBuffer write_buffer(db_options.db_write_buffer_size);
|
|
|
|
WriteController write_controller;
|
|
|
|
|
|
|
|
CreateDB();
|
|
|
|
VersionSet versions(dbname, &db_options, env_options, table_cache.get(),
|
|
|
|
&write_buffer, &write_controller);
|
|
|
|
|
|
|
|
// Create mock default ColumnFamilyData
|
|
|
|
ColumnFamilyOptions cf_options;
|
|
|
|
std::vector<ColumnFamilyDescriptor> column_families;
|
|
|
|
column_families.emplace_back(kDefaultColumnFamilyName, cf_options);
|
|
|
|
EXPECT_OK(versions.Recover(column_families, false));
|
|
|
|
|
|
|
|
auto column_family_set = versions.GetColumnFamilySet();
|
|
|
|
auto cfd = column_family_set->GetColumnFamily(0);
|
|
|
|
EXPECT_TRUE(cfd != nullptr);
|
|
|
|
|
|
|
|
// Create dummy mutex.
|
|
|
|
InstrumentedMutex mutex;
|
|
|
|
InstrumentedMutexLock l(&mutex);
|
|
|
|
|
|
|
|
return list->InstallMemtableFlushResults(cfd, mutable_cf_options, m,
|
|
|
|
&versions, &mutex, 1, to_delete,
|
|
|
|
nullptr, &log_buffer);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
TEST_F(MemTableListTest, Empty) {
|
|
|
|
// Create an empty MemTableList and validate basic functions.
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
MemTableList list(1, 0);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(0, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
|
|
|
|
autovector<MemTable*> mems;
|
|
|
|
list.PickMemtablesToFlush(&mems);
|
|
|
|
ASSERT_EQ(0, mems.size());
|
2015-04-10 23:16:03 +02:00
|
|
|
|
|
|
|
autovector<MemTable*> to_delete;
|
|
|
|
list.current()->Unref(&to_delete);
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(MemTableListTest, GetTest) {
|
|
|
|
// Create MemTableList
|
|
|
|
int min_write_buffer_number_to_merge = 2;
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
int max_write_buffer_number_to_maintain = 0;
|
|
|
|
MemTableList list(min_write_buffer_number_to_merge,
|
|
|
|
max_write_buffer_number_to_maintain);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
SequenceNumber seq = 1;
|
|
|
|
std::string value;
|
|
|
|
Status s;
|
|
|
|
MergeContext merge_context;
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
autovector<MemTable*> to_delete;
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
LookupKey lkey("key1", seq);
|
|
|
|
bool found = list.current()->Get(lkey, &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
// Create a MemTable
|
|
|
|
InternalKeyComparator cmp(BytewiseComparator());
|
|
|
|
auto factory = std::make_shared<SkipListFactory>();
|
|
|
|
options.memtable_factory = factory;
|
|
|
|
ImmutableCFOptions ioptions(options);
|
|
|
|
|
|
|
|
WriteBuffer wb(options.db_write_buffer_size);
|
|
|
|
MemTable* mem =
|
2015-05-29 23:36:35 +02:00
|
|
|
new MemTable(cmp, ioptions, MutableCFOptions(options, ioptions), &wb,
|
|
|
|
kMaxSequenceNumber);
|
2015-04-10 03:01:11 +02:00
|
|
|
mem->Ref();
|
|
|
|
|
|
|
|
// Write some keys to this memtable.
|
|
|
|
mem->Add(++seq, kTypeDeletion, "key1", "");
|
|
|
|
mem->Add(++seq, kTypeValue, "key2", "value2");
|
|
|
|
mem->Add(++seq, kTypeValue, "key1", "value1");
|
|
|
|
mem->Add(++seq, kTypeValue, "key2", "value2.2");
|
|
|
|
|
|
|
|
// Fetch the newly written keys
|
|
|
|
merge_context.Clear();
|
|
|
|
found = mem->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ(value, "value1");
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = mem->Get(LookupKey("key1", 2), &value, &s, &merge_context);
|
|
|
|
// MemTable found out that this key is *not* found (at this sequence#)
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = mem->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ(value, "value2.2");
|
|
|
|
|
|
|
|
ASSERT_EQ(4, mem->num_entries());
|
|
|
|
ASSERT_EQ(1, mem->num_deletes());
|
|
|
|
|
|
|
|
// Add memtable to list
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(mem, &to_delete);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
SequenceNumber saved_seq = seq;
|
|
|
|
|
|
|
|
// Create another memtable and write some keys to it
|
|
|
|
WriteBuffer wb2(options.db_write_buffer_size);
|
|
|
|
MemTable* mem2 =
|
2015-05-29 23:36:35 +02:00
|
|
|
new MemTable(cmp, ioptions, MutableCFOptions(options, ioptions), &wb2,
|
|
|
|
kMaxSequenceNumber);
|
2015-04-10 03:01:11 +02:00
|
|
|
mem2->Ref();
|
|
|
|
|
|
|
|
mem2->Add(++seq, kTypeDeletion, "key1", "");
|
|
|
|
mem2->Add(++seq, kTypeValue, "key2", "value2.3");
|
|
|
|
|
|
|
|
// Add second memtable to list
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(mem2, &to_delete);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Fetch keys via MemTableList
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->Get(LookupKey("key1", saved_seq), &value, &s,
|
|
|
|
&merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ("value1", value);
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ(value, "value2.3");
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->Get(LookupKey("key2", 1), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(2, list.NumNotFlushed());
|
|
|
|
|
|
|
|
list.current()->Unref(&to_delete);
|
|
|
|
for (MemTable* m : to_delete) {
|
|
|
|
delete m;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(MemTableListTest, GetFromHistoryTest) {
|
|
|
|
// Create MemTableList
|
|
|
|
int min_write_buffer_number_to_merge = 2;
|
|
|
|
int max_write_buffer_number_to_maintain = 2;
|
|
|
|
MemTableList list(min_write_buffer_number_to_merge,
|
|
|
|
max_write_buffer_number_to_maintain);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
SequenceNumber seq = 1;
|
|
|
|
std::string value;
|
|
|
|
Status s;
|
|
|
|
MergeContext merge_context;
|
2015-04-10 03:01:11 +02:00
|
|
|
autovector<MemTable*> to_delete;
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
|
|
|
|
LookupKey lkey("key1", seq);
|
|
|
|
bool found = list.current()->Get(lkey, &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
// Create a MemTable
|
|
|
|
InternalKeyComparator cmp(BytewiseComparator());
|
|
|
|
auto factory = std::make_shared<SkipListFactory>();
|
|
|
|
options.memtable_factory = factory;
|
|
|
|
ImmutableCFOptions ioptions(options);
|
|
|
|
|
|
|
|
WriteBuffer wb(options.db_write_buffer_size);
|
|
|
|
MemTable* mem =
|
2015-05-29 23:36:35 +02:00
|
|
|
new MemTable(cmp, ioptions, MutableCFOptions(options, ioptions), &wb,
|
|
|
|
kMaxSequenceNumber);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
mem->Ref();
|
|
|
|
|
|
|
|
// Write some keys to this memtable.
|
|
|
|
mem->Add(++seq, kTypeDeletion, "key1", "");
|
|
|
|
mem->Add(++seq, kTypeValue, "key2", "value2");
|
|
|
|
mem->Add(++seq, kTypeValue, "key2", "value2.2");
|
|
|
|
|
|
|
|
// Fetch the newly written keys
|
|
|
|
merge_context.Clear();
|
|
|
|
found = mem->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
// MemTable found out that this key is *not* found (at this sequence#)
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = mem->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ(value, "value2.2");
|
|
|
|
|
|
|
|
// Add memtable to list
|
|
|
|
list.Add(mem, &to_delete);
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
|
|
|
|
|
|
|
// Fetch keys via MemTableList
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_TRUE(s.ok() && found);
|
|
|
|
ASSERT_EQ("value2.2", value);
|
|
|
|
|
|
|
|
// Flush this memtable from the list.
|
|
|
|
// (It will then be a part of the memtable history).
|
|
|
|
autovector<MemTable*> to_flush;
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(1, to_flush.size());
|
|
|
|
|
|
|
|
s = Mock_InstallMemtableFlushResults(
|
|
|
|
&list, MutableCFOptions(options, ioptions), to_flush, &to_delete);
|
|
|
|
ASSERT_OK(s);
|
|
|
|
ASSERT_EQ(0, list.NumNotFlushed());
|
|
|
|
ASSERT_EQ(1, list.NumFlushed());
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
|
|
|
|
|
|
|
// Verify keys are no longer in MemTableList
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
// Verify keys are present in history
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->GetFromHistory(LookupKey("key1", seq), &value, &s,
|
|
|
|
&merge_context);
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->GetFromHistory(LookupKey("key2", seq), &value, &s,
|
|
|
|
&merge_context);
|
|
|
|
ASSERT_TRUE(found);
|
|
|
|
ASSERT_EQ("value2.2", value);
|
|
|
|
|
|
|
|
// Create another memtable and write some keys to it
|
|
|
|
WriteBuffer wb2(options.db_write_buffer_size);
|
|
|
|
MemTable* mem2 =
|
2015-05-29 23:36:35 +02:00
|
|
|
new MemTable(cmp, ioptions, MutableCFOptions(options, ioptions), &wb2,
|
|
|
|
kMaxSequenceNumber);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
mem2->Ref();
|
|
|
|
|
|
|
|
mem2->Add(++seq, kTypeDeletion, "key1", "");
|
|
|
|
mem2->Add(++seq, kTypeValue, "key3", "value3");
|
|
|
|
|
|
|
|
// Add second memtable to list
|
|
|
|
list.Add(mem2, &to_delete);
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
|
|
|
|
|
|
|
to_flush.clear();
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(1, to_flush.size());
|
|
|
|
|
|
|
|
// Flush second memtable
|
|
|
|
s = Mock_InstallMemtableFlushResults(
|
|
|
|
&list, MutableCFOptions(options, ioptions), to_flush, &to_delete);
|
|
|
|
ASSERT_OK(s);
|
|
|
|
ASSERT_EQ(0, list.NumNotFlushed());
|
|
|
|
ASSERT_EQ(2, list.NumFlushed());
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
|
|
|
|
|
|
|
// Add a third memtable to push the first memtable out of the history
|
|
|
|
WriteBuffer wb3(options.db_write_buffer_size);
|
|
|
|
MemTable* mem3 =
|
2015-05-29 23:36:35 +02:00
|
|
|
new MemTable(cmp, ioptions, MutableCFOptions(options, ioptions), &wb3,
|
|
|
|
kMaxSequenceNumber);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
mem3->Ref();
|
|
|
|
list.Add(mem3, &to_delete);
|
|
|
|
ASSERT_EQ(1, list.NumNotFlushed());
|
|
|
|
ASSERT_EQ(1, list.NumFlushed());
|
|
|
|
ASSERT_EQ(1, to_delete.size());
|
|
|
|
|
|
|
|
// Verify keys are no longer in MemTableList
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key1", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key3", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
// Verify that the second memtable's keys are in the history
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->GetFromHistory(LookupKey("key1", seq), &value, &s,
|
|
|
|
&merge_context);
|
|
|
|
ASSERT_TRUE(found && s.IsNotFound());
|
|
|
|
|
|
|
|
merge_context.Clear();
|
|
|
|
found = list.current()->GetFromHistory(LookupKey("key3", seq), &value, &s,
|
|
|
|
&merge_context);
|
|
|
|
ASSERT_TRUE(found);
|
|
|
|
ASSERT_EQ("value3", value);
|
|
|
|
|
|
|
|
// Verify that key2 from the first memtable is no longer in the history
|
|
|
|
merge_context.Clear();
|
|
|
|
found =
|
|
|
|
list.current()->Get(LookupKey("key2", seq), &value, &s, &merge_context);
|
|
|
|
ASSERT_FALSE(found);
|
|
|
|
|
|
|
|
// Cleanup
|
2015-04-10 03:01:11 +02:00
|
|
|
list.current()->Unref(&to_delete);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(3, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
for (MemTable* m : to_delete) {
|
|
|
|
delete m;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_F(MemTableListTest, FlushPendingTest) {
|
|
|
|
const int num_tables = 5;
|
|
|
|
SequenceNumber seq = 1;
|
|
|
|
Status s;
|
|
|
|
|
|
|
|
auto factory = std::make_shared<SkipListFactory>();
|
|
|
|
options.memtable_factory = factory;
|
|
|
|
ImmutableCFOptions ioptions(options);
|
|
|
|
InternalKeyComparator cmp(BytewiseComparator());
|
|
|
|
WriteBuffer wb(options.db_write_buffer_size);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
autovector<MemTable*> to_delete;
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Create MemTableList
|
|
|
|
int min_write_buffer_number_to_merge = 3;
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
int max_write_buffer_number_to_maintain = 7;
|
|
|
|
MemTableList list(min_write_buffer_number_to_merge,
|
|
|
|
max_write_buffer_number_to_maintain);
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Create some MemTables
|
|
|
|
std::vector<MemTable*> tables;
|
Include bunch of more events into EventLogger
Summary:
Added these events:
* Recovery start, finish and also when recovery creates a file
* Trivial move
* Compaction start, finish and when compaction creates a file
* Flush start, finish
Also includes small fix to EventLogger
Also added option ROCKSDB_PRINT_EVENTS_TO_STDOUT which is useful when we debug things. I've spent far too much time chasing LOG files.
Still didn't get sst table properties in JSON. They are written very deeply into the stack. I'll address in separate diff.
TODO:
* Write specification. Let's first use this for a while and figure out what's good data to put here, too. After that we'll write spec
* Write tools that parse and analyze LOGs. This can be in python or go. Good intern task.
Test Plan: Ran db_bench with ROCKSDB_PRINT_EVENTS_TO_STDOUT. Here's the output: https://phabricator.fb.com/P19811976
Reviewers: sdong, yhchiang, rven, MarkCallaghan, kradhakrishnan, anthony
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37521
2015-04-28 00:20:02 +02:00
|
|
|
MutableCFOptions mutable_cf_options(options, ioptions);
|
2015-04-10 03:01:11 +02:00
|
|
|
for (int i = 0; i < num_tables; i++) {
|
2015-05-29 23:36:35 +02:00
|
|
|
MemTable* mem = new MemTable(cmp, ioptions, mutable_cf_options, &wb,
|
|
|
|
kMaxSequenceNumber);
|
2015-04-10 03:01:11 +02:00
|
|
|
mem->Ref();
|
|
|
|
|
|
|
|
std::string value;
|
|
|
|
MergeContext merge_context;
|
|
|
|
|
2015-06-08 20:43:55 +02:00
|
|
|
mem->Add(++seq, kTypeValue, "key1", ToString(i));
|
|
|
|
mem->Add(++seq, kTypeValue, "keyN" + ToString(i), "valueN");
|
|
|
|
mem->Add(++seq, kTypeValue, "keyX" + ToString(i), "value");
|
|
|
|
mem->Add(++seq, kTypeValue, "keyM" + ToString(i), "valueM");
|
|
|
|
mem->Add(++seq, kTypeDeletion, "keyX" + ToString(i), "");
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
tables.push_back(mem);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Nothing to flush
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
autovector<MemTable*> to_flush;
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(0, to_flush.size());
|
|
|
|
|
|
|
|
// Request a flush even though there is nothing to flush
|
|
|
|
list.FlushRequested();
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Attempt to 'flush' to clear request for flush
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(0, to_flush.size());
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Request a flush again
|
|
|
|
list.FlushRequested();
|
|
|
|
// No flush pending since the list is empty.
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Add 2 tables
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(tables[0], &to_delete);
|
|
|
|
list.Add(tables[1], &to_delete);
|
|
|
|
ASSERT_EQ(2, list.NumNotFlushed());
|
|
|
|
ASSERT_EQ(0, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Even though we have less than the minimum to flush, a flush is
|
|
|
|
// pending since we had previously requested a flush and never called
|
|
|
|
// PickMemtablesToFlush() to clear the flush.
|
|
|
|
ASSERT_TRUE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Pick tables to flush
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(2, to_flush.size());
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(2, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Revert flush
|
|
|
|
list.RollbackMemtableFlush(to_flush, 0);
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
to_flush.clear();
|
|
|
|
|
|
|
|
// Add another table
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(tables[2], &to_delete);
|
2015-04-10 03:01:11 +02:00
|
|
|
// We now have the minimum to flush regardles of whether FlushRequested()
|
|
|
|
// was called.
|
|
|
|
ASSERT_TRUE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(0, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Pick tables to flush
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
ASSERT_EQ(3, to_flush.size());
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(3, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Pick tables to flush again
|
|
|
|
autovector<MemTable*> to_flush2;
|
|
|
|
list.PickMemtablesToFlush(&to_flush2);
|
|
|
|
ASSERT_EQ(0, to_flush2.size());
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(3, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Add another table
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(tables[3], &to_delete);
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(0, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Request a flush again
|
|
|
|
list.FlushRequested();
|
|
|
|
ASSERT_TRUE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Pick tables to flush again
|
|
|
|
list.PickMemtablesToFlush(&to_flush2);
|
|
|
|
ASSERT_EQ(1, to_flush2.size());
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(4, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Rollback first pick of tables
|
|
|
|
list.RollbackMemtableFlush(to_flush, 0);
|
|
|
|
ASSERT_TRUE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
to_flush.clear();
|
|
|
|
|
|
|
|
// Add another tables
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
list.Add(tables[4], &to_delete);
|
|
|
|
ASSERT_EQ(5, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
// We now have the minimum to flush regardles of whether FlushRequested()
|
|
|
|
ASSERT_TRUE(list.IsFlushPending());
|
|
|
|
ASSERT_TRUE(list.imm_flush_needed.load(std::memory_order_acquire));
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(0, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Pick tables to flush
|
|
|
|
list.PickMemtablesToFlush(&to_flush);
|
|
|
|
// Should pick 4 of 5 since 1 table has been picked in to_flush2
|
|
|
|
ASSERT_EQ(4, to_flush.size());
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(5, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Pick tables to flush again
|
|
|
|
autovector<MemTable*> to_flush3;
|
|
|
|
ASSERT_EQ(0, to_flush3.size()); // nothing not in progress of being flushed
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(5, list.NumNotFlushed());
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Flush the 4 memtables that were picked in to_flush
|
|
|
|
s = Mock_InstallMemtableFlushResults(
|
|
|
|
&list, MutableCFOptions(options, ioptions), to_flush, &to_delete);
|
|
|
|
ASSERT_OK(s);
|
|
|
|
|
|
|
|
// Note: now to_flush contains tables[0,1,2,4]. to_flush2 contains
|
|
|
|
// tables[3].
|
|
|
|
// Current implementation will only commit memtables in the order they were
|
|
|
|
// created. So InstallMemtableFlushResults will install the first 3 tables
|
|
|
|
// in to_flush and stop when it encounters a table not yet flushed.
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(2, list.NumNotFlushed());
|
|
|
|
int num_in_history = std::min(3, max_write_buffer_number_to_maintain);
|
|
|
|
ASSERT_EQ(num_in_history, list.NumFlushed());
|
|
|
|
ASSERT_EQ(5 - list.NumNotFlushed() - num_in_history, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
|
|
|
// Request a flush again. Should be nothing to flush
|
|
|
|
list.FlushRequested();
|
|
|
|
ASSERT_FALSE(list.IsFlushPending());
|
|
|
|
ASSERT_FALSE(list.imm_flush_needed.load(std::memory_order_acquire));
|
|
|
|
|
|
|
|
// Flush the 1 memtable that was picked in to_flush2
|
|
|
|
s = MemTableListTest::Mock_InstallMemtableFlushResults(
|
2015-04-10 23:16:03 +02:00
|
|
|
&list, MutableCFOptions(options, ioptions), to_flush2, &to_delete);
|
2015-04-10 03:01:11 +02:00
|
|
|
ASSERT_OK(s);
|
|
|
|
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
// This will actually install 2 tables. The 1 we told it to flush, and also
|
2015-04-10 03:01:11 +02:00
|
|
|
// tables[4] which has been waiting for tables[3] to commit.
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
ASSERT_EQ(0, list.NumNotFlushed());
|
|
|
|
num_in_history = std::min(5, max_write_buffer_number_to_maintain);
|
|
|
|
ASSERT_EQ(num_in_history, list.NumFlushed());
|
|
|
|
ASSERT_EQ(5 - list.NumNotFlushed() - num_in_history, to_delete.size());
|
2015-04-10 03:01:11 +02:00
|
|
|
|
2015-04-10 23:16:03 +02:00
|
|
|
for (const auto& m : to_delete) {
|
2015-04-10 03:01:11 +02:00
|
|
|
// Refcount should be 0 after calling InstallMemtableFlushResults.
|
|
|
|
// Verify this, by Ref'ing then UnRef'ing:
|
|
|
|
m->Ref();
|
|
|
|
ASSERT_EQ(m, m->Unref());
|
|
|
|
delete m;
|
|
|
|
}
|
2015-04-10 23:16:03 +02:00
|
|
|
to_delete.clear();
|
|
|
|
|
|
|
|
list.current()->Unref(&to_delete);
|
Support saving history in memtable_list
Summary:
For transactions, we are using the memtables to validate that there are no write conflicts. But after flushing, we don't have any memtables, and transactions could fail to commit. So we want to someone keep around some extra history to use for conflict checking. In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure). It seems like the best place for this is abstracted inside the memtable_list. I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
This diff adds a new parameter to control how much memtable history to keep around after flushing. However, it sounds like people aren't too fond of adding new parameters. So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers. This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit. (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached). So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests. Added testing in memtablelist_test and planning on adding more testing here.
Reviewers: sdong, rven, igor
Reviewed By: igor
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D37443
2015-05-29 01:34:24 +02:00
|
|
|
int to_delete_size = std::min(5, max_write_buffer_number_to_maintain);
|
|
|
|
ASSERT_EQ(to_delete_size, to_delete.size());
|
2015-05-29 23:36:35 +02:00
|
|
|
|
|
|
|
for (const auto& m : to_delete) {
|
|
|
|
// Refcount should be 0 after calling InstallMemtableFlushResults.
|
|
|
|
// Verify this, by Ref'ing then UnRef'ing:
|
|
|
|
m->Ref();
|
|
|
|
ASSERT_EQ(m, m->Unref());
|
|
|
|
delete m;
|
|
|
|
}
|
|
|
|
to_delete.clear();
|
2015-04-10 03:01:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace rocksdb
|
|
|
|
|
|
|
|
int main(int argc, char** argv) {
|
|
|
|
::testing::InitGoogleTest(&argc, argv);
|
|
|
|
return RUN_ALL_TESTS();
|
|
|
|
}
|