|
|
|
|
# Prerequisites for Windows:
|
|
|
|
|
# This cmake build is for Windows 64-bit only.
|
|
|
|
|
#
|
|
|
|
|
# Prerequisites:
|
|
|
|
|
# You must have at least Visual Studio 2019. Start the Developer Command Prompt window that is a part of Visual Studio installation.
|
|
|
|
|
# Run the build commands from within the Developer Command Prompt window to have paths to the compiler and runtime libraries set.
|
|
|
|
|
# You must have git.exe in your %PATH% environment variable.
|
|
|
|
|
#
|
|
|
|
|
# To build Rocksdb for Windows is as easy as 1-2-3-4-5:
|
|
|
|
|
#
|
|
|
|
|
# 1. Update paths to third-party libraries in thirdparty.inc file
|
|
|
|
|
# 2. Create a new directory for build artifacts
|
|
|
|
|
# mkdir build
|
|
|
|
|
# cd build
|
|
|
|
|
# 3. Run cmake to generate project files for Windows, add more options to enable required third-party libraries.
|
|
|
|
|
# See thirdparty.inc for more information.
|
|
|
|
|
# sample command: cmake -G "Visual Studio 16 2019" -DCMAKE_BUILD_TYPE=Release -DWITH_GFLAGS=1 -DWITH_SNAPPY=1 -DWITH_JEMALLOC=1 -DWITH_JNI=1 ..
|
|
|
|
|
# 4. Then build the project in debug mode (you may want to add /m[:<N>] flag to run msbuild in <N> parallel threads
|
|
|
|
|
# or simply /m to use all avail cores)
|
|
|
|
|
# msbuild rocksdb.sln
|
|
|
|
|
#
|
|
|
|
|
# rocksdb.sln build features exclusions of test only code in Release. If you build ALL_BUILD then everything
|
|
|
|
|
# will be attempted but test only code does not build in Release mode.
|
|
|
|
|
#
|
|
|
|
|
# 5. And release mode (/m[:<N>] is also supported)
|
|
|
|
|
# msbuild rocksdb.sln /p:Configuration=Release
|
|
|
|
|
#
|
|
|
|
|
# Linux:
|
|
|
|
|
#
|
|
|
|
|
# 1. Install a recent toolchain if you're on a older distro. C++17 required (GCC >= 7, Clang >= 5)
|
|
|
|
|
# 2. mkdir build; cd build
|
|
|
|
|
# 3. cmake ..
|
|
|
|
|
# 4. make -j
|
|
|
|
|
|
|
|
|
|
cmake_minimum_required(VERSION 3.10)
|
|
|
|
|
|
|
|
|
|
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake/modules/")
|
|
|
|
|
include(ReadVersion)
|
|
|
|
|
include(GoogleTest)
|
|
|
|
|
get_rocksdb_version(rocksdb_VERSION)
|
|
|
|
|
project(rocksdb
|
|
|
|
|
VERSION ${rocksdb_VERSION}
|
|
|
|
|
DESCRIPTION "An embeddable persistent key-value store for fast storage"
|
|
|
|
|
HOMEPAGE_URL https://rocksdb.org/
|
|
|
|
|
LANGUAGES CXX C ASM)
|
|
|
|
|
|
|
|
|
|
if(POLICY CMP0042)
|
|
|
|
|
cmake_policy(SET CMP0042 NEW)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT CMAKE_BUILD_TYPE)
|
|
|
|
|
if(EXISTS "${CMAKE_SOURCE_DIR}/.git")
|
|
|
|
|
set(default_build_type "Debug")
|
|
|
|
|
else()
|
|
|
|
|
set(default_build_type "RelWithDebInfo")
|
|
|
|
|
endif()
|
|
|
|
|
set(CMAKE_BUILD_TYPE "${default_build_type}" CACHE STRING
|
|
|
|
|
"Default BUILD_TYPE is ${default_build_type}" FORCE)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
find_program(CCACHE_FOUND ccache)
|
|
|
|
|
if(CCACHE_FOUND)
|
|
|
|
|
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
|
|
|
|
|
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
|
|
|
|
|
endif(CCACHE_FOUND)
|
|
|
|
|
|
|
|
|
|
option(WITH_JEMALLOC "build with JeMalloc" OFF)
|
|
|
|
|
option(WITH_LIBURING "build with liburing" ON)
|
|
|
|
|
option(WITH_SNAPPY "build with SNAPPY" OFF)
|
|
|
|
|
option(WITH_LZ4 "build with lz4" OFF)
|
|
|
|
|
option(WITH_ZLIB "build with zlib" OFF)
|
|
|
|
|
option(WITH_ZSTD "build with zstd" OFF)
|
|
|
|
|
option(WITH_WINDOWS_UTF8_FILENAMES "use UTF8 as characterset for opening files, regardles of the system code page" OFF)
|
|
|
|
|
if (WITH_WINDOWS_UTF8_FILENAMES)
|
|
|
|
|
add_definitions(-DROCKSDB_WINDOWS_UTF8_FILENAMES)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if ($ENV{CIRCLECI})
|
|
|
|
|
message(STATUS "Build for CircieCI env, a few tests may be disabled")
|
|
|
|
|
add_definitions(-DCIRCLECI)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if( NOT DEFINED CMAKE_CXX_STANDARD )
|
|
|
|
|
set(CMAKE_CXX_STANDARD 17)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include(CMakeDependentOption)
|
|
|
|
|
|
|
|
|
|
if(MSVC)
|
|
|
|
|
option(WITH_GFLAGS "build with GFlags" OFF)
|
|
|
|
|
option(WITH_XPRESS "build with windows built in compression" OFF)
|
|
|
|
|
option(ROCKSDB_SKIP_THIRDPARTY "skip thirdparty.inc" OFF)
|
|
|
|
|
|
|
|
|
|
if(NOT ROCKSDB_SKIP_THIRDPARTY)
|
|
|
|
|
include(${CMAKE_CURRENT_SOURCE_DIR}/thirdparty.inc)
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
if(CMAKE_SYSTEM_NAME MATCHES "FreeBSD" AND NOT CMAKE_SYSTEM_NAME MATCHES "kFreeBSD")
|
|
|
|
|
# FreeBSD has jemalloc as default malloc
|
|
|
|
|
# but it does not have all the jemalloc files in include/...
|
|
|
|
|
set(WITH_JEMALLOC ON)
|
|
|
|
|
else()
|
|
|
|
|
if(WITH_JEMALLOC)
|
|
|
|
|
find_package(JeMalloc REQUIRED)
|
|
|
|
|
add_definitions(-DROCKSDB_JEMALLOC -DJEMALLOC_NO_DEMANGLE)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS JeMalloc::JeMalloc)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(MINGW)
|
|
|
|
|
option(WITH_GFLAGS "build with GFlags" OFF)
|
|
|
|
|
else()
|
|
|
|
|
option(WITH_GFLAGS "build with GFlags" ON)
|
|
|
|
|
endif()
|
|
|
|
|
set(GFLAGS_LIB)
|
|
|
|
|
if(WITH_GFLAGS)
|
|
|
|
|
# Config with namespace available since gflags 2.2.2
|
|
|
|
|
option(GFLAGS_USE_TARGET_NAMESPACE "Use gflags import target with namespace." ON)
|
|
|
|
|
find_package(gflags CONFIG)
|
|
|
|
|
if(gflags_FOUND)
|
|
|
|
|
if(TARGET ${GFLAGS_TARGET})
|
|
|
|
|
# Config with GFLAGS_TARGET available since gflags 2.2.0
|
|
|
|
|
set(GFLAGS_LIB ${GFLAGS_TARGET})
|
|
|
|
|
else()
|
|
|
|
|
# Config with GFLAGS_LIBRARIES available since gflags 2.1.0
|
|
|
|
|
set(GFLAGS_LIB ${gflags_LIBRARIES})
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
find_package(gflags REQUIRED)
|
|
|
|
|
set(GFLAGS_LIB gflags::gflags)
|
|
|
|
|
endif()
|
|
|
|
|
include_directories(${GFLAGS_INCLUDE_DIR})
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS ${GFLAGS_LIB})
|
|
|
|
|
add_definitions(-DGFLAGS=1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_SNAPPY)
|
|
|
|
|
find_package(Snappy CONFIG)
|
|
|
|
|
if(NOT Snappy_FOUND)
|
|
|
|
|
find_package(Snappy REQUIRED)
|
|
|
|
|
endif()
|
|
|
|
|
add_definitions(-DSNAPPY)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS Snappy::snappy)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_ZLIB)
|
|
|
|
|
find_package(ZLIB REQUIRED)
|
|
|
|
|
add_definitions(-DZLIB)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS ZLIB::ZLIB)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_BZ2 "build with bzip2" OFF)
|
|
|
|
|
if(WITH_BZ2)
|
|
|
|
|
find_package(BZip2 REQUIRED)
|
|
|
|
|
add_definitions(-DBZIP2)
|
|
|
|
|
if(BZIP2_INCLUDE_DIRS)
|
|
|
|
|
include_directories(${BZIP2_INCLUDE_DIRS})
|
|
|
|
|
else()
|
|
|
|
|
include_directories(${BZIP2_INCLUDE_DIR})
|
|
|
|
|
endif()
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS ${BZIP2_LIBRARIES})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_LZ4)
|
|
|
|
|
find_package(lz4 REQUIRED)
|
|
|
|
|
add_definitions(-DLZ4)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS lz4::lz4)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_ZSTD)
|
|
|
|
|
find_package(zstd REQUIRED)
|
|
|
|
|
add_definitions(-DZSTD)
|
|
|
|
|
include_directories(${ZSTD_INCLUDE_DIR})
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS zstd::zstd)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
option(WITH_MD_LIBRARY "build with MD" ON)
|
|
|
|
|
if(WIN32 AND MSVC)
|
|
|
|
|
if(WITH_MD_LIBRARY)
|
|
|
|
|
set(RUNTIME_LIBRARY "MD")
|
|
|
|
|
else()
|
|
|
|
|
set(RUNTIME_LIBRARY "MT")
|
|
|
|
|
endif()
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(MSVC)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Zi /nologo /EHsc /GS /Gd /GR /GF /fp:precise /Zc:wchar_t /Zc:forScope /errorReport:queue")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FC /d2Zi+ /W4 /wd4127 /wd4800 /wd4996 /wd4351 /wd4100 /wd4204 /wd4324")
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -W -Wextra -Wall -pthread")
|
Use -Wno-invalid-offsetof instead of dangerous offset_of hack (#9563)
Summary:
After https://github.com/facebook/rocksdb/issues/9515 added a unique_ptr to Status, we see some
warnings-as-error in some internal builds like this:
```
stderr: rocksdb/src/db/compaction/compaction_job.cc:2839:7: error:
offset of on non-standard-layout type 'struct CompactionServiceResult'
[-Werror,-Winvalid-offsetof]
{offsetof(struct CompactionServiceResult, status),
^ ~~~~~~
```
I see three potential solutions to resolving this:
* Expand our use of an idiom that works around the warning (see offset_of
functions removed in this change, inspired by
https://gist.github.com/graphitemaster/494f21190bb2c63c5516) However,
this construction is invoking undefined behavior that assumes consistent
layout with no compiler-introduced indirection. A compiler incompatible
with our assumptions will likely compile the code and exhibit undefined
behavior.
* Migrate to something in place of offset, like a function mapping
CompactionServiceResult* to Status* (for the `status` field). This might
be required in the long term.
* **Selected:** Use our new C++17 dependency to use offsetof in a well-defined way
when the compiler allows it. From a comment on
https://gist.github.com/graphitemaster/494f21190bb2c63c5516:
> A final note: in C++17, offsetof is conditionally supported, which
> means that you can use it on any type (not just standard layout
> types) and the compiler will error if it can't compile it correctly.
> That appears to be the best option if you can live with C++17 and
> don't need constexpr support.
The C++17 semantics are confirmed on
https://en.cppreference.com/w/cpp/types/offsetof, so we can suppress the
warning as long as we accept that we might run into a compiler that
rejects the code, and at that point we will find a solution, such as
the more intrusive "migrate" solution above.
Although this is currently only showing in our buck build, it will
surely show up also with make and cmake, so I have updated those
configurations as well.
Also in the buck build, -Wno-expansion-to-defined does not appear to be
needed anymore (both current compiler configurations) so I
removed it.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9563
Test Plan: Tried out buck builds with both current compiler configurations
Reviewed By: riversand963
Differential Revision: D34220931
Pulled By: pdillinger
fbshipit-source-id: d39436008259bd1eaaa87c77be69fb2a5b559e1f
3 years ago
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wsign-compare -Wshadow -Wno-unused-parameter -Wno-unused-variable -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-strict-aliasing -Wno-invalid-offsetof")
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wstrict-prototypes")
|
|
|
|
|
endif()
|
|
|
|
|
if(MINGW)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-format")
|
|
|
|
|
add_definitions(-D_POSIX_C_SOURCE=1)
|
|
|
|
|
endif()
|
|
|
|
|
if(NOT CMAKE_BUILD_TYPE STREQUAL "Debug")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-omit-frame-pointer")
|
|
|
|
|
include(CheckCXXCompilerFlag)
|
|
|
|
|
CHECK_CXX_COMPILER_FLAG("-momit-leaf-frame-pointer" HAVE_OMIT_LEAF_FRAME_POINTER)
|
|
|
|
|
if(HAVE_OMIT_LEAF_FRAME_POINTER)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -momit-leaf-frame-pointer")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include(CheckCCompilerFlag)
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
|
|
|
|
|
CHECK_C_COMPILER_FLAG("-mcpu=power9" HAS_POWER9)
|
|
|
|
|
if(HAS_POWER9)
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mcpu=power9 -mtune=power9")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=power9 -mtune=power9")
|
|
|
|
|
else()
|
|
|
|
|
CHECK_C_COMPILER_FLAG("-mcpu=power8" HAS_POWER8)
|
|
|
|
|
if(HAS_POWER8)
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mcpu=power8 -mtune=power8")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=power8 -mtune=power8")
|
|
|
|
|
endif(HAS_POWER8)
|
|
|
|
|
endif(HAS_POWER9)
|
|
|
|
|
CHECK_C_COMPILER_FLAG("-maltivec" HAS_ALTIVEC)
|
|
|
|
|
if(HAS_ALTIVEC)
|
|
|
|
|
message(STATUS " HAS_ALTIVEC yes")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -maltivec")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -maltivec")
|
|
|
|
|
endif(HAS_ALTIVEC)
|
|
|
|
|
endif(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
|
|
|
|
|
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "arm64|aarch64|AARCH64")
|
|
|
|
|
CHECK_C_COMPILER_FLAG("-march=armv8-a+crc+crypto" HAS_ARMV8_CRC)
|
|
|
|
|
if(HAS_ARMV8_CRC)
|
|
|
|
|
message(STATUS " HAS_ARMV8_CRC yes")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=armv8-a+crc+crypto -Wno-unused-function")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=armv8-a+crc+crypto -Wno-unused-function")
|
|
|
|
|
endif(HAS_ARMV8_CRC)
|
|
|
|
|
endif(CMAKE_SYSTEM_PROCESSOR MATCHES "arm64|aarch64|AARCH64")
|
|
|
|
|
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "s390x")
|
|
|
|
|
CHECK_C_COMPILER_FLAG("-march=native" HAS_S390X_MARCH_NATIVE)
|
|
|
|
|
if(HAS_S390X_MARCH_NATIVE)
|
|
|
|
|
message(STATUS " HAS_S390X_MARCH_NATIVE yes")
|
|
|
|
|
endif(HAS_S390X_MARCH_NATIVE)
|
|
|
|
|
endif(CMAKE_SYSTEM_PROCESSOR MATCHES "s390x")
|
|
|
|
|
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
option(PORTABLE "build a portable binary" OFF)
|
|
|
|
|
option(FORCE_SSE42 "force building with SSE4.2, even when PORTABLE=ON" OFF)
|
|
|
|
|
option(FORCE_AVX "force building with AVX, even when PORTABLE=ON" OFF)
|
|
|
|
|
option(FORCE_AVX2 "force building with AVX2, even when PORTABLE=ON" OFF)
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
if(PORTABLE)
|
|
|
|
|
# MSVC does not need a separate compiler flag to enable SSE4.2; if nmmintrin.h
|
|
|
|
|
# is available, it is available by default.
|
|
|
|
|
if(FORCE_SSE42 AND NOT MSVC)
|
Port 3 way SSE4.2 crc32c implementation from Folly
Summary:
**# Summary**
RocksDB uses SSE crc32 intrinsics to calculate the crc32 values but it does it in single way fashion (not pipelined on single CPU core). Intel's whitepaper () published an algorithm that uses 3-way pipelining for the crc32 intrinsics, then use pclmulqdq intrinsic to combine the values. Because pclmulqdq has overhead on its own, this algorithm will show perf gains on buffers larger than 216 bytes, which makes RocksDB a perfect user, since most of the buffers RocksDB call crc32c on is over 4KB. Initial db_bench show tremendous CPU gain.
This change uses the 3-way SSE algorithm by default. The old SSE algorithm is now behind a compiler tag NO_THREEWAY_CRC32C. If user compiles the code with NO_THREEWAY_CRC32C=1 then the old SSE Crc32c algorithm would be used. If the server does not have SSE4.2 at the run time the slow way (Non SSE) will be used.
**# Performance Test Results**
We ran the FillRandom and ReadRandom benchmarks in db_bench. ReadRandom is the point of interest here since it calculates the CRC32 for the in-mem buffers. We did 3 runs for each algorithm.
Before this change the CRC32 value computation takes about 11.5% of total CPU cost, and with the new 3-way algorithm it reduced to around 4.5%. The overall throughput also improved from 25.53MB/s to 27.63MB/s.
1) ReadRandom in db_bench overall metrics
PER RUN
Algorithm | run | micros/op | ops/sec |Throughput (MB/s)
3-way | 1 | 4.143 | 241387 | 26.7
3-way | 2 | 3.775 | 264872 | 29.3
3-way | 3 | 4.116 | 242929 | 26.9
FastCrc32c|1 | 4.037 | 247727 | 27.4
FastCrc32c|2 | 4.648 | 215166 | 23.8
FastCrc32c|3 | 4.352 | 229799 | 25.4
AVG
Algorithm | Average of micros/op | Average of ops/sec | Average of Throughput (MB/s)
3-way | 4.01 | 249,729 | 27.63
FastCrc32c | 4.35 | 230,897 | 25.53
2) Crc32c computation CPU cost (inclusive samples percentage)
PER RUN
Implementation | run | TotalSamples | Crc32c percentage
3-way | 1 | 4,572,250,000 | 4.37%
3-way | 2 | 3,779,250,000 | 4.62%
3-way | 3 | 4,129,500,000 | 4.48%
FastCrc32c | 1 | 4,663,500,000 | 11.24%
FastCrc32c | 2 | 4,047,500,000 | 12.34%
FastCrc32c | 3 | 4,366,750,000 | 11.68%
**# Test Plan**
make -j64 corruption_test && ./corruption_test
By default it uses 3-way SSE algorithm
NO_THREEWAY_CRC32C=1 make -j64 corruption_test && ./corruption_test
make clean && DEBUG_LEVEL=0 make -j64 db_bench
make clean && DEBUG_LEVEL=0 NO_THREEWAY_CRC32C=1 make -j64 db_bench
Closes https://github.com/facebook/rocksdb/pull/3173
Differential Revision: D6330882
Pulled By: yingsu00
fbshipit-source-id: 8ec3d89719533b63b536a736663ca6f0dd4482e9
7 years ago
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -msse4.2 -mpclmul")
|
|
|
|
|
endif()
|
|
|
|
|
if(MSVC)
|
|
|
|
|
if(FORCE_AVX)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /arch:AVX")
|
|
|
|
|
endif()
|
|
|
|
|
# MSVC automatically enables BMI / lzcnt with AVX2.
|
|
|
|
|
if(FORCE_AVX2)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /arch:AVX2")
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
if(FORCE_AVX)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mavx")
|
|
|
|
|
endif()
|
|
|
|
|
if(FORCE_AVX2)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mavx2 -mbmi -mlzcnt")
|
|
|
|
|
endif()
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^s390x")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=z196")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
if(MSVC)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /arch:AVX2")
|
|
|
|
|
else()
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^s390x" AND NOT HAS_S390X_MARCH_NATIVE)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=z196")
|
|
|
|
|
elseif(NOT CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64" AND NOT HAS_ARMV8_CRC)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
include(CheckCXXSourceCompiles)
|
|
|
|
|
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
|
|
|
|
|
if(NOT MSVC)
|
Port 3 way SSE4.2 crc32c implementation from Folly
Summary:
**# Summary**
RocksDB uses SSE crc32 intrinsics to calculate the crc32 values but it does it in single way fashion (not pipelined on single CPU core). Intel's whitepaper () published an algorithm that uses 3-way pipelining for the crc32 intrinsics, then use pclmulqdq intrinsic to combine the values. Because pclmulqdq has overhead on its own, this algorithm will show perf gains on buffers larger than 216 bytes, which makes RocksDB a perfect user, since most of the buffers RocksDB call crc32c on is over 4KB. Initial db_bench show tremendous CPU gain.
This change uses the 3-way SSE algorithm by default. The old SSE algorithm is now behind a compiler tag NO_THREEWAY_CRC32C. If user compiles the code with NO_THREEWAY_CRC32C=1 then the old SSE Crc32c algorithm would be used. If the server does not have SSE4.2 at the run time the slow way (Non SSE) will be used.
**# Performance Test Results**
We ran the FillRandom and ReadRandom benchmarks in db_bench. ReadRandom is the point of interest here since it calculates the CRC32 for the in-mem buffers. We did 3 runs for each algorithm.
Before this change the CRC32 value computation takes about 11.5% of total CPU cost, and with the new 3-way algorithm it reduced to around 4.5%. The overall throughput also improved from 25.53MB/s to 27.63MB/s.
1) ReadRandom in db_bench overall metrics
PER RUN
Algorithm | run | micros/op | ops/sec |Throughput (MB/s)
3-way | 1 | 4.143 | 241387 | 26.7
3-way | 2 | 3.775 | 264872 | 29.3
3-way | 3 | 4.116 | 242929 | 26.9
FastCrc32c|1 | 4.037 | 247727 | 27.4
FastCrc32c|2 | 4.648 | 215166 | 23.8
FastCrc32c|3 | 4.352 | 229799 | 25.4
AVG
Algorithm | Average of micros/op | Average of ops/sec | Average of Throughput (MB/s)
3-way | 4.01 | 249,729 | 27.63
FastCrc32c | 4.35 | 230,897 | 25.53
2) Crc32c computation CPU cost (inclusive samples percentage)
PER RUN
Implementation | run | TotalSamples | Crc32c percentage
3-way | 1 | 4,572,250,000 | 4.37%
3-way | 2 | 3,779,250,000 | 4.62%
3-way | 3 | 4,129,500,000 | 4.48%
FastCrc32c | 1 | 4,663,500,000 | 11.24%
FastCrc32c | 2 | 4,047,500,000 | 12.34%
FastCrc32c | 3 | 4,366,750,000 | 11.68%
**# Test Plan**
make -j64 corruption_test && ./corruption_test
By default it uses 3-way SSE algorithm
NO_THREEWAY_CRC32C=1 make -j64 corruption_test && ./corruption_test
make clean && DEBUG_LEVEL=0 make -j64 db_bench
make clean && DEBUG_LEVEL=0 NO_THREEWAY_CRC32C=1 make -j64 db_bench
Closes https://github.com/facebook/rocksdb/pull/3173
Differential Revision: D6330882
Pulled By: yingsu00
fbshipit-source-id: 8ec3d89719533b63b536a736663ca6f0dd4482e9
7 years ago
|
|
|
set(CMAKE_REQUIRED_FLAGS "-msse4.2 -mpclmul")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (NOT PORTABLE OR FORCE_SSE42)
|
|
|
|
|
CHECK_CXX_SOURCE_COMPILES("
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
#include <cstdint>
|
|
|
|
|
#include <nmmintrin.h>
|
Port 3 way SSE4.2 crc32c implementation from Folly
Summary:
**# Summary**
RocksDB uses SSE crc32 intrinsics to calculate the crc32 values but it does it in single way fashion (not pipelined on single CPU core). Intel's whitepaper () published an algorithm that uses 3-way pipelining for the crc32 intrinsics, then use pclmulqdq intrinsic to combine the values. Because pclmulqdq has overhead on its own, this algorithm will show perf gains on buffers larger than 216 bytes, which makes RocksDB a perfect user, since most of the buffers RocksDB call crc32c on is over 4KB. Initial db_bench show tremendous CPU gain.
This change uses the 3-way SSE algorithm by default. The old SSE algorithm is now behind a compiler tag NO_THREEWAY_CRC32C. If user compiles the code with NO_THREEWAY_CRC32C=1 then the old SSE Crc32c algorithm would be used. If the server does not have SSE4.2 at the run time the slow way (Non SSE) will be used.
**# Performance Test Results**
We ran the FillRandom and ReadRandom benchmarks in db_bench. ReadRandom is the point of interest here since it calculates the CRC32 for the in-mem buffers. We did 3 runs for each algorithm.
Before this change the CRC32 value computation takes about 11.5% of total CPU cost, and with the new 3-way algorithm it reduced to around 4.5%. The overall throughput also improved from 25.53MB/s to 27.63MB/s.
1) ReadRandom in db_bench overall metrics
PER RUN
Algorithm | run | micros/op | ops/sec |Throughput (MB/s)
3-way | 1 | 4.143 | 241387 | 26.7
3-way | 2 | 3.775 | 264872 | 29.3
3-way | 3 | 4.116 | 242929 | 26.9
FastCrc32c|1 | 4.037 | 247727 | 27.4
FastCrc32c|2 | 4.648 | 215166 | 23.8
FastCrc32c|3 | 4.352 | 229799 | 25.4
AVG
Algorithm | Average of micros/op | Average of ops/sec | Average of Throughput (MB/s)
3-way | 4.01 | 249,729 | 27.63
FastCrc32c | 4.35 | 230,897 | 25.53
2) Crc32c computation CPU cost (inclusive samples percentage)
PER RUN
Implementation | run | TotalSamples | Crc32c percentage
3-way | 1 | 4,572,250,000 | 4.37%
3-way | 2 | 3,779,250,000 | 4.62%
3-way | 3 | 4,129,500,000 | 4.48%
FastCrc32c | 1 | 4,663,500,000 | 11.24%
FastCrc32c | 2 | 4,047,500,000 | 12.34%
FastCrc32c | 3 | 4,366,750,000 | 11.68%
**# Test Plan**
make -j64 corruption_test && ./corruption_test
By default it uses 3-way SSE algorithm
NO_THREEWAY_CRC32C=1 make -j64 corruption_test && ./corruption_test
make clean && DEBUG_LEVEL=0 make -j64 db_bench
make clean && DEBUG_LEVEL=0 NO_THREEWAY_CRC32C=1 make -j64 db_bench
Closes https://github.com/facebook/rocksdb/pull/3173
Differential Revision: D6330882
Pulled By: yingsu00
fbshipit-source-id: 8ec3d89719533b63b536a736663ca6f0dd4482e9
7 years ago
|
|
|
#include <wmmintrin.h>
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
int main() {
|
|
|
|
|
volatile uint32_t x = _mm_crc32_u32(0, 0);
|
Port 3 way SSE4.2 crc32c implementation from Folly
Summary:
**# Summary**
RocksDB uses SSE crc32 intrinsics to calculate the crc32 values but it does it in single way fashion (not pipelined on single CPU core). Intel's whitepaper () published an algorithm that uses 3-way pipelining for the crc32 intrinsics, then use pclmulqdq intrinsic to combine the values. Because pclmulqdq has overhead on its own, this algorithm will show perf gains on buffers larger than 216 bytes, which makes RocksDB a perfect user, since most of the buffers RocksDB call crc32c on is over 4KB. Initial db_bench show tremendous CPU gain.
This change uses the 3-way SSE algorithm by default. The old SSE algorithm is now behind a compiler tag NO_THREEWAY_CRC32C. If user compiles the code with NO_THREEWAY_CRC32C=1 then the old SSE Crc32c algorithm would be used. If the server does not have SSE4.2 at the run time the slow way (Non SSE) will be used.
**# Performance Test Results**
We ran the FillRandom and ReadRandom benchmarks in db_bench. ReadRandom is the point of interest here since it calculates the CRC32 for the in-mem buffers. We did 3 runs for each algorithm.
Before this change the CRC32 value computation takes about 11.5% of total CPU cost, and with the new 3-way algorithm it reduced to around 4.5%. The overall throughput also improved from 25.53MB/s to 27.63MB/s.
1) ReadRandom in db_bench overall metrics
PER RUN
Algorithm | run | micros/op | ops/sec |Throughput (MB/s)
3-way | 1 | 4.143 | 241387 | 26.7
3-way | 2 | 3.775 | 264872 | 29.3
3-way | 3 | 4.116 | 242929 | 26.9
FastCrc32c|1 | 4.037 | 247727 | 27.4
FastCrc32c|2 | 4.648 | 215166 | 23.8
FastCrc32c|3 | 4.352 | 229799 | 25.4
AVG
Algorithm | Average of micros/op | Average of ops/sec | Average of Throughput (MB/s)
3-way | 4.01 | 249,729 | 27.63
FastCrc32c | 4.35 | 230,897 | 25.53
2) Crc32c computation CPU cost (inclusive samples percentage)
PER RUN
Implementation | run | TotalSamples | Crc32c percentage
3-way | 1 | 4,572,250,000 | 4.37%
3-way | 2 | 3,779,250,000 | 4.62%
3-way | 3 | 4,129,500,000 | 4.48%
FastCrc32c | 1 | 4,663,500,000 | 11.24%
FastCrc32c | 2 | 4,047,500,000 | 12.34%
FastCrc32c | 3 | 4,366,750,000 | 11.68%
**# Test Plan**
make -j64 corruption_test && ./corruption_test
By default it uses 3-way SSE algorithm
NO_THREEWAY_CRC32C=1 make -j64 corruption_test && ./corruption_test
make clean && DEBUG_LEVEL=0 make -j64 db_bench
make clean && DEBUG_LEVEL=0 NO_THREEWAY_CRC32C=1 make -j64 db_bench
Closes https://github.com/facebook/rocksdb/pull/3173
Differential Revision: D6330882
Pulled By: yingsu00
fbshipit-source-id: 8ec3d89719533b63b536a736663ca6f0dd4482e9
7 years ago
|
|
|
const auto a = _mm_set_epi64x(0, 0);
|
|
|
|
|
const auto b = _mm_set_epi64x(0, 0);
|
|
|
|
|
const auto c = _mm_clmulepi64_si128(a, b, 0x00);
|
|
|
|
|
auto d = _mm_cvtsi128_si64(c);
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
}
|
|
|
|
|
" HAVE_SSE42)
|
|
|
|
|
if(HAVE_SSE42)
|
|
|
|
|
add_definitions(-DHAVE_SSE42)
|
|
|
|
|
add_definitions(-DHAVE_PCLMUL)
|
|
|
|
|
elseif(FORCE_SSE42)
|
|
|
|
|
message(FATAL_ERROR "FORCE_SSE42=ON but unable to compile with SSE4.2 enabled")
|
|
|
|
|
endif()
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Check if -latomic is required or not
|
|
|
|
|
if (NOT MSVC)
|
|
|
|
|
set(CMAKE_REQUIRED_FLAGS "--std=c++17")
|
|
|
|
|
CHECK_CXX_SOURCE_COMPILES("
|
|
|
|
|
#include <atomic>
|
|
|
|
|
std::atomic<uint64_t> x(0);
|
|
|
|
|
int main() {
|
|
|
|
|
uint64_t i = x.load(std::memory_order_relaxed);
|
|
|
|
|
bool b = x.is_lock_free();
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
" BUILTIN_ATOMIC)
|
|
|
|
|
if (NOT BUILTIN_ATOMIC)
|
|
|
|
|
#TODO: Check if -latomic exists
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS atomic)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (WITH_LIBURING)
|
|
|
|
|
find_package(uring)
|
|
|
|
|
if (uring_FOUND)
|
|
|
|
|
add_definitions(-DROCKSDB_IOURING_PRESENT)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS uring::uring)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Reset the required flags
|
|
|
|
|
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
|
|
|
|
|
option(WITH_IOSTATS_CONTEXT "Enable IO stats context" ON)
|
|
|
|
|
if (NOT WITH_IOSTATS_CONTEXT)
|
|
|
|
|
add_definitions(-DNIOSTATS_CONTEXT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_PERF_CONTEXT "Enable perf context" ON)
|
|
|
|
|
if (NOT WITH_PERF_CONTEXT)
|
|
|
|
|
add_definitions(-DNPERF_CONTEXT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(FAIL_ON_WARNINGS "Treat compile warnings as errors" ON)
|
|
|
|
|
if(FAIL_ON_WARNINGS)
|
|
|
|
|
if(MSVC)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /WX")
|
|
|
|
|
else() # assume GCC
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_ASAN "build with ASAN" OFF)
|
|
|
|
|
if(WITH_ASAN)
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address")
|
|
|
|
|
if(WITH_JEMALLOC)
|
|
|
|
|
message(FATAL "ASAN does not work well with JeMalloc")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_TSAN "build with TSAN" OFF)
|
|
|
|
|
if(WITH_TSAN)
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=thread -Wl,-pie")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread -fPIC")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=thread -fPIC")
|
|
|
|
|
if(WITH_JEMALLOC)
|
|
|
|
|
message(FATAL "TSAN does not work well with JeMalloc")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_UBSAN "build with UBSAN" OFF)
|
|
|
|
|
if(WITH_UBSAN)
|
|
|
|
|
add_definitions(-DROCKSDB_UBSAN_RUN)
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=undefined")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=undefined")
|
|
|
|
|
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=undefined")
|
|
|
|
|
if(WITH_JEMALLOC)
|
|
|
|
|
message(FATAL "UBSAN does not work well with JeMalloc")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_NUMA "build with NUMA policy support" OFF)
|
|
|
|
|
if(WITH_NUMA)
|
|
|
|
|
find_package(NUMA REQUIRED)
|
|
|
|
|
add_definitions(-DNUMA)
|
|
|
|
|
include_directories(${NUMA_INCLUDE_DIR})
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS NUMA::NUMA)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_TBB "build with Threading Building Blocks (TBB)" OFF)
|
|
|
|
|
if(WITH_TBB)
|
|
|
|
|
find_package(TBB REQUIRED)
|
|
|
|
|
add_definitions(-DTBB)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS TBB::TBB)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Stall notifications eat some performance from inserts
|
|
|
|
|
option(DISABLE_STALL_NOTIF "Build with stall notifications" OFF)
|
|
|
|
|
if(DISABLE_STALL_NOTIF)
|
|
|
|
|
add_definitions(-DROCKSDB_DISABLE_STALL_NOTIFICATION)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_DYNAMIC_EXTENSION "build with dynamic extension support" OFF)
|
|
|
|
|
if(NOT WITH_DYNAMIC_EXTENSION)
|
|
|
|
|
add_definitions(-DROCKSDB_NO_DYNAMIC_EXTENSION)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(ASSERT_STATUS_CHECKED "build with assert status checked" OFF)
|
|
|
|
|
if (ASSERT_STATUS_CHECKED)
|
|
|
|
|
message(STATUS "Build with assert status checked")
|
|
|
|
|
add_definitions(-DROCKSDB_ASSERT_STATUS_CHECKED)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# RTTI is by default AUTO which enables it in debug and disables it in release.
|
|
|
|
|
set(USE_RTTI AUTO CACHE STRING "Enable RTTI in builds")
|
|
|
|
|
set_property(CACHE USE_RTTI PROPERTY STRINGS AUTO ON OFF)
|
|
|
|
|
if(USE_RTTI STREQUAL "AUTO")
|
|
|
|
|
message(STATUS "Enabling RTTI in Debug builds only (default)")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI")
|
|
|
|
|
if(MSVC)
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /GR-")
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -fno-rtti")
|
|
|
|
|
endif()
|
|
|
|
|
elseif(USE_RTTI)
|
|
|
|
|
message(STATUS "Enabling RTTI in all builds")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -DROCKSDB_USE_RTTI")
|
|
|
|
|
else()
|
|
|
|
|
if(MSVC)
|
|
|
|
|
message(STATUS "Disabling RTTI in Release builds. Always on in Debug.")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /GR-")
|
|
|
|
|
else()
|
|
|
|
|
message(STATUS "Disabling RTTI in all builds")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-rtti")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -fno-rtti")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Used to run CI build and tests so we can run faster
|
|
|
|
|
option(OPTDBG "Build optimized debug build with MSVC" OFF)
|
|
|
|
|
option(WITH_RUNTIME_DEBUG "build with debug version of runtime library" ON)
|
|
|
|
|
if(MSVC)
|
|
|
|
|
if(OPTDBG)
|
|
|
|
|
message(STATUS "Debug optimization is enabled")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "/Oxt")
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /Od /RTC1")
|
|
|
|
|
|
|
|
|
|
# Minimal Build is deprecated after MSVC 2015
|
|
|
|
|
if( MSVC_VERSION GREATER 1900 )
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /Gm-")
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /Gm")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
endif()
|
|
|
|
|
if(WITH_RUNTIME_DEBUG)
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /${RUNTIME_LIBRARY}d")
|
|
|
|
|
else()
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /${RUNTIME_LIBRARY}")
|
|
|
|
|
endif()
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /Oxt /Zp8 /Gm- /Gy /${RUNTIME_LIBRARY}")
|
|
|
|
|
|
|
|
|
|
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} /DEBUG")
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEBUG")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(CMAKE_COMPILER_IS_GNUCXX)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-builtin-memcmp")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(ROCKSDB_LITE "Build RocksDBLite version" OFF)
|
|
|
|
|
if(ROCKSDB_LITE)
|
|
|
|
|
add_definitions(-DROCKSDB_LITE)
|
|
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -Os")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(CMAKE_SYSTEM_NAME MATCHES "Cygwin")
|
|
|
|
|
add_definitions(-fno-builtin-memcmp -DCYGWIN)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "Darwin")
|
|
|
|
|
add_definitions(-DOS_MACOSX)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "Linux")
|
|
|
|
|
add_definitions(-DOS_LINUX)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "SunOS")
|
|
|
|
|
add_definitions(-DOS_SOLARIS)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "kFreeBSD")
|
|
|
|
|
add_definitions(-DOS_GNU_KFREEBSD)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
|
|
|
|
|
add_definitions(-DOS_FREEBSD)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "NetBSD")
|
|
|
|
|
add_definitions(-DOS_NETBSD)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "OpenBSD")
|
|
|
|
|
add_definitions(-DOS_OPENBSD)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "DragonFly")
|
|
|
|
|
add_definitions(-DOS_DRAGONFLYBSD)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "Android")
|
|
|
|
|
add_definitions(-DOS_ANDROID)
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME MATCHES "Windows")
|
|
|
|
|
add_definitions(-DWIN32 -DOS_WIN -D_MBCS -DWIN64 -DNOMINMAX)
|
|
|
|
|
if(MINGW)
|
|
|
|
|
add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_VISTA)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT WIN32)
|
|
|
|
|
add_definitions(-DROCKSDB_PLATFORM_POSIX -DROCKSDB_LIB_IO_POSIX)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_FALLOCATE "build with fallocate" ON)
|
|
|
|
|
if(WITH_FALLOCATE)
|
|
|
|
|
CHECK_CXX_SOURCE_COMPILES("
|
|
|
|
|
#include <fcntl.h>
|
|
|
|
|
#include <linux/falloc.h>
|
|
|
|
|
int main() {
|
|
|
|
|
int fd = open(\"/dev/null\", 0);
|
|
|
|
|
fallocate(fd, FALLOC_FL_KEEP_SIZE, 0, 1024);
|
|
|
|
|
}
|
|
|
|
|
" HAVE_FALLOCATE)
|
|
|
|
|
if(HAVE_FALLOCATE)
|
|
|
|
|
add_definitions(-DROCKSDB_FALLOCATE_PRESENT)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
CHECK_CXX_SOURCE_COMPILES("
|
|
|
|
|
#include <fcntl.h>
|
|
|
|
|
int main() {
|
|
|
|
|
int fd = open(\"/dev/null\", 0);
|
|
|
|
|
sync_file_range(fd, 0, 1024, SYNC_FILE_RANGE_WRITE);
|
|
|
|
|
}
|
|
|
|
|
" HAVE_SYNC_FILE_RANGE_WRITE)
|
|
|
|
|
if(HAVE_SYNC_FILE_RANGE_WRITE)
|
|
|
|
|
add_definitions(-DROCKSDB_RANGESYNC_PRESENT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
CHECK_CXX_SOURCE_COMPILES("
|
|
|
|
|
#include <pthread.h>
|
|
|
|
|
int main() {
|
|
|
|
|
(void) PTHREAD_MUTEX_ADAPTIVE_NP;
|
|
|
|
|
}
|
|
|
|
|
" HAVE_PTHREAD_MUTEX_ADAPTIVE_NP)
|
|
|
|
|
if(HAVE_PTHREAD_MUTEX_ADAPTIVE_NP)
|
|
|
|
|
add_definitions(-DROCKSDB_PTHREAD_ADAPTIVE_MUTEX)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include(CheckCXXSymbolExists)
|
|
|
|
|
if(CMAKE_SYSTEM_NAME MATCHES "^FreeBSD")
|
|
|
|
|
check_cxx_symbol_exists(malloc_usable_size malloc_np.h HAVE_MALLOC_USABLE_SIZE)
|
|
|
|
|
else()
|
|
|
|
|
check_cxx_symbol_exists(malloc_usable_size malloc.h HAVE_MALLOC_USABLE_SIZE)
|
|
|
|
|
endif()
|
|
|
|
|
if(HAVE_MALLOC_USABLE_SIZE)
|
|
|
|
|
add_definitions(-DROCKSDB_MALLOC_USABLE_SIZE)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_cxx_symbol_exists(sched_getcpu sched.h HAVE_SCHED_GETCPU)
|
|
|
|
|
if(HAVE_SCHED_GETCPU)
|
|
|
|
|
add_definitions(-DROCKSDB_SCHED_GETCPU_PRESENT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_cxx_symbol_exists(getauxval auvx.h HAVE_AUXV_GETAUXVAL)
|
|
|
|
|
if(HAVE_AUXV_GETAUXVAL)
|
|
|
|
|
add_definitions(-DROCKSDB_AUXV_GETAUXVAL_PRESENT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_cxx_symbol_exists(F_FULLFSYNC "fcntl.h" HAVE_FULLFSYNC)
|
|
|
|
|
if(HAVE_FULLFSYNC)
|
|
|
|
|
add_definitions(-DHAVE_FULLFSYNC)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include_directories(${PROJECT_SOURCE_DIR})
|
|
|
|
|
include_directories(${PROJECT_SOURCE_DIR}/include)
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
3 years ago
|
|
|
if(USE_FOLLY)
|
|
|
|
|
include_directories(${PROJECT_SOURCE_DIR}/third-party/folly)
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
3 years ago
|
|
|
add_definitions(-DUSE_FOLLY -DFOLLY_NO_CONFIG)
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS glog)
|
|
|
|
|
endif()
|
|
|
|
|
find_package(Threads REQUIRED)
|
|
|
|
|
|
|
|
|
|
# Main library source code
|
|
|
|
|
|
|
|
|
|
set(SOURCES
|
|
|
|
|
cache/cache.cc
|
Use deleters to label cache entries and collect stats (#8297)
Summary:
This change gathers and publishes statistics about the
kinds of items in block cache. This is especially important for
profiling relative usage of cache by index vs. filter vs. data blocks.
It works by iterating over the cache during periodic stats dump
(InternalStats, stats_dump_period_sec) or on demand when
DB::Get(Map)Property(kBlockCacheEntryStats), except that for
efficiency and sharing among column families, saved data from
the last scan is used when the data is not considered too old.
The new information can be seen in info LOG, for example:
Block cache LRUCache@0x7fca62229330 capacity: 95.37 MB collections: 8 last_copies: 0 last_secs: 0.00178 secs_since: 0
Block cache entry stats(count,size,portion): DataBlock(7092,28.24 MB,29.6136%) FilterBlock(215,867.90 KB,0.888728%) FilterMetaBlock(2,5.31 KB,0.00544%) IndexBlock(217,180.11 KB,0.184432%) WriteBuffer(1,256.00 KB,0.262144%) Misc(1,0.00 KB,0%)
And also through DB::GetProperty and GetMapProperty (here using
ldb just for demonstration):
$ ./ldb --db=/dev/shm/dbbench/ get_property rocksdb.block-cache-entry-stats
rocksdb.block-cache-entry-stats.bytes.data-block: 0
rocksdb.block-cache-entry-stats.bytes.deprecated-filter-block: 0
rocksdb.block-cache-entry-stats.bytes.filter-block: 0
rocksdb.block-cache-entry-stats.bytes.filter-meta-block: 0
rocksdb.block-cache-entry-stats.bytes.index-block: 178992
rocksdb.block-cache-entry-stats.bytes.misc: 0
rocksdb.block-cache-entry-stats.bytes.other-block: 0
rocksdb.block-cache-entry-stats.bytes.write-buffer: 0
rocksdb.block-cache-entry-stats.capacity: 8388608
rocksdb.block-cache-entry-stats.count.data-block: 0
rocksdb.block-cache-entry-stats.count.deprecated-filter-block: 0
rocksdb.block-cache-entry-stats.count.filter-block: 0
rocksdb.block-cache-entry-stats.count.filter-meta-block: 0
rocksdb.block-cache-entry-stats.count.index-block: 215
rocksdb.block-cache-entry-stats.count.misc: 1
rocksdb.block-cache-entry-stats.count.other-block: 0
rocksdb.block-cache-entry-stats.count.write-buffer: 0
rocksdb.block-cache-entry-stats.id: LRUCache@0x7f3636661290
rocksdb.block-cache-entry-stats.percent.data-block: 0.000000
rocksdb.block-cache-entry-stats.percent.deprecated-filter-block: 0.000000
rocksdb.block-cache-entry-stats.percent.filter-block: 0.000000
rocksdb.block-cache-entry-stats.percent.filter-meta-block: 0.000000
rocksdb.block-cache-entry-stats.percent.index-block: 2.133751
rocksdb.block-cache-entry-stats.percent.misc: 0.000000
rocksdb.block-cache-entry-stats.percent.other-block: 0.000000
rocksdb.block-cache-entry-stats.percent.write-buffer: 0.000000
rocksdb.block-cache-entry-stats.secs_for_last_collection: 0.000052
rocksdb.block-cache-entry-stats.secs_since_last_collection: 0
Solution detail - We need some way to flag what kind of blocks each
entry belongs to, preferably without changing the Cache API.
One of the complications is that Cache is a general interface that could
have other users that don't adhere to whichever convention we decide
on for keys and values. Or we would pay for an extra field in the Handle
that would only be used for this purpose.
This change uses a back-door approach, the deleter, to indicate the
"role" of a Cache entry (in addition to the value type, implicitly).
This has the added benefit of ensuring proper code origin whenever we
recognize a particular role for a cache entry; if the entry came from
some other part of the code, it will use an unrecognized deleter, which
we simply attribute to the "Misc" role.
An internal API makes for simple instantiation and automatic
registration of Cache deleters for a given value type and "role".
Another internal API, CacheEntryStatsCollector, solves the problem of
caching the results of a scan and sharing them, to ensure scans are
neither excessive nor redundant so as not to harm Cache performance.
Because code is added to BlocklikeTraits, it is pulled out of
block_based_table_reader.cc into its own file.
This is a reformulation of https://github.com/facebook/rocksdb/issues/8276, without the type checking option
(could still be added), and with actual stat gathering.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8297
Test Plan: manual testing with db_bench, and a couple of basic unit tests
Reviewed By: ltamasi
Differential Revision: D28488721
Pulled By: pdillinger
fbshipit-source-id: 472f524a9691b5afb107934be2d41d84f2b129fb
4 years ago
|
|
|
cache/cache_entry_roles.cc
|
New stable, fixed-length cache keys (#9126)
Summary:
This change standardizes on a new 16-byte cache key format for
block cache (incl compressed and secondary) and persistent cache (but
not table cache and row cache).
The goal is a really fast cache key with practically ideal stability and
uniqueness properties without external dependencies (e.g. from FileSystem).
A fixed key size of 16 bytes should enable future optimizations to the
concurrent hash table for block cache, which is a heavy CPU user /
bottleneck, but there appears to be measurable performance improvement
even with no changes to LRUCache.
This change replaces a lot of disjointed and ugly code handling cache
keys with calls to a simple, clean new internal API (cache_key.h).
(Preserving the old cache key logic under an option would be very ugly
and likely negate the performance gain of the new approach. Complete
replacement carries some inherent risk, but I think that's acceptable
with sufficient analysis and testing.)
The scheme for encoding new cache keys is complicated but explained
in cache_key.cc.
Also: EndianSwapValue is moved to math.h to be next to other bit
operations. (Explains some new include "math.h".) ReverseBits operation
added and unit tests added to hash_test for both.
Fixes https://github.com/facebook/rocksdb/issues/7405 (presuming a root cause)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9126
Test Plan:
### Basic correctness
Several tests needed updates to work with the new functionality, mostly
because we are no longer relying on filesystem for stable cache keys
so table builders & readers need more context info to agree on cache
keys. This functionality is so core, a huge number of existing tests
exercise the cache key functionality.
### Performance
Create db with
`TEST_TMPDIR=/dev/shm ./db_bench -bloom_bits=10 -benchmarks=fillrandom -num=3000000 -partition_index_and_filters`
And test performance with
`TEST_TMPDIR=/dev/shm ./db_bench -readonly -use_existing_db -bloom_bits=10 -benchmarks=readrandom -num=3000000 -duration=30 -cache_index_and_filter_blocks -cache_size=250000 -threads=4`
using DEBUG_LEVEL=0 and simultaneous before & after runs.
Before ops/sec, avg over 100 runs: 121924
After ops/sec, avg over 100 runs: 125385 (+2.8%)
### Collision probability
I have built a tool, ./cache_bench -stress_cache_key to broadly simulate host-wide cache activity
over many months, by making some pessimistic simplifying assumptions:
* Every generated file has a cache entry for every byte offset in the file (contiguous range of cache keys)
* All of every file is cached for its entire lifetime
We use a simple table with skewed address assignment and replacement on address collision
to simulate files coming & going, with quite a variance (super-Poisson) in ages. Some output
with `./cache_bench -stress_cache_key -sck_keep_bits=40`:
```
Total cache or DBs size: 32TiB Writing 925.926 MiB/s or 76.2939TiB/day
Multiply by 9.22337e+18 to correct for simulation losses (but still assume whole file cached)
```
These come from default settings of 2.5M files per day of 32 MB each, and
`-sck_keep_bits=40` means that to represent a single file, we are only keeping 40 bits of
the 128-bit cache key. With file size of 2\*\*25 contiguous keys (pessimistic), our simulation
is about 2\*\*(128-40-25) or about 9 billion billion times more prone to collision than reality.
More default assumptions, relatively pessimistic:
* 100 DBs in same process (doesn't matter much)
* Re-open DB in same process (new session ID related to old session ID) on average
every 100 files generated
* Restart process (all new session IDs unrelated to old) 24 times per day
After enough data, we get a result at the end:
```
(keep 40 bits) 17 collisions after 2 x 90 days, est 10.5882 days between (9.76592e+19 corrected)
```
If we believe the (pessimistic) simulation and the mathematical generalization, we would need to run a billion machines all for 97 billion days to expect a cache key collision. To help verify that our generalization ("corrected") is robust, we can make our simulation more precise with `-sck_keep_bits=41` and `42`, which takes more running time to get enough data:
```
(keep 41 bits) 16 collisions after 4 x 90 days, est 22.5 days between (1.03763e+20 corrected)
(keep 42 bits) 19 collisions after 10 x 90 days, est 47.3684 days between (1.09224e+20 corrected)
```
The generalized prediction still holds. With the `-sck_randomize` option, we can see that we are beating "random" cache keys (except offsets still non-randomized) by a modest amount (roughly 20x less collision prone than random), which should make us reasonably comfortable even in "degenerate" cases:
```
197 collisions after 1 x 90 days, est 0.456853 days between (4.21372e+18 corrected)
```
I've run other tests to validate other conditions behave as expected, never behaving "worse than random" unless we start chopping off structured data.
Reviewed By: zhichao-cao
Differential Revision: D33171746
Pulled By: pdillinger
fbshipit-source-id: f16a57e369ed37be5e7e33525ace848d0537c88f
3 years ago
|
|
|
cache/cache_key.cc
|
|
|
|
|
cache/cache_reservation_manager.cc
|
|
|
|
|
cache/charged_cache.cc
|
|
|
|
|
cache/clock_cache.cc
|
|
|
|
|
cache/compressed_secondary_cache.cc
|
|
|
|
|
cache/fast_lru_cache.cc
|
|
|
|
|
cache/lru_cache.cc
|
|
|
|
|
cache/sharded_cache.cc
|
|
|
|
|
db/arena_wrapped_db_iter.cc
|
|
|
|
|
db/blob/blob_contents.cc
|
|
|
|
|
db/blob/blob_fetcher.cc
|
|
|
|
|
db/blob/blob_file_addition.cc
|
|
|
|
|
db/blob/blob_file_builder.cc
|
|
|
|
|
db/blob/blob_file_cache.cc
|
|
|
|
|
db/blob/blob_file_garbage.cc
|
Add blob files to VersionStorageInfo/VersionBuilder (#6597)
Summary:
The patch adds a couple of classes to represent metadata about
blob files: `SharedBlobFileMetaData` contains the information elements
that are immutable (once the blob file is closed), e.g. blob file number,
total number and size of blob files, checksum method/value, while
`BlobFileMetaData` contains attributes that can vary across versions like
the amount of garbage in the file. There is a single `SharedBlobFileMetaData`
for each blob file, which is jointly owned by the `BlobFileMetaData` objects
that point to it; `BlobFileMetaData` objects, in turn, are owned by `Version`s
and can also be shared if the (immutable _and_ mutable) state of the blob file
is the same in two versions.
In addition, the patch adds the blob file metadata to `VersionStorageInfo`, and extends
`VersionBuilder` so that it can apply blob file related `VersionEdit`s (i.e. those
containing `BlobFileAddition`s and/or `BlobFileGarbage`), and save blob file metadata
to a new `VersionStorageInfo`. Consistency checks are also extended to ensure
that table files point to blob files that are part of the `Version`, and that all blob files
that are part of any given `Version` have at least some _non_-garbage data in them.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6597
Test Plan: `make check`
Reviewed By: riversand963
Differential Revision: D20656803
Pulled By: ltamasi
fbshipit-source-id: f1f74d135045b3b42d0146f03ee576ef0a4bfd80
5 years ago
|
|
|
db/blob/blob_file_meta.cc
|
Introduce a blob file reader class (#7461)
Summary:
The patch adds a class called `BlobFileReader` that can be used to retrieve blobs
using the information available in blob references (e.g. blob file number, offset, and
size). This will come in handy when implementing blob support for `Get`, `MultiGet`,
and iterators, and also for compaction/garbage collection.
When a `BlobFileReader` object is created (using the factory method `Create`),
it first checks whether the specified file is potentially valid by comparing the file
size against the combined size of the blob file header and footer (files smaller than
the threshold are considered malformed). Then, it opens the file, and reads and verifies
the header and footer. The verification involves magic number/CRC checks
as well as checking for unexpected header/footer fields, e.g. incorrect column family ID
or TTL blob files.
Blobs can be retrieved using `GetBlob`. `GetBlob` validates the offset and compression
type passed by the caller (because of the presence of the header and footer, the
specified offset cannot be too close to the start/end of the file; also, the compression type
has to match the one in the blob file header), and retrieves and potentially verifies and
uncompresses the blob. In particular, when `ReadOptions::verify_checksums` is set,
`BlobFileReader` reads the blob record header as well (as opposed to just the blob itself)
and verifies the key/value size, the key itself, as well as the CRC of the blob record header
and the key/value pair.
In addition, the patch exposes the compression type from `BlobIndex` (both using an
accessor and via `DebugString`), and adds a blob file read latency histogram to
`InternalStats` that can be used with `BlobFileReader`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7461
Test Plan: `make check`
Reviewed By: riversand963
Differential Revision: D23999219
Pulled By: ltamasi
fbshipit-source-id: deb6b1160d251258b308d5156e2ec063c3e12e5e
4 years ago
|
|
|
db/blob/blob_file_reader.cc
|
|
|
|
|
db/blob/blob_garbage_meter.cc
|
|
|
|
|
db/blob/blob_log_format.cc
|
|
|
|
|
db/blob/blob_log_sequential_reader.cc
|
|
|
|
|
db/blob/blob_log_writer.cc
|
|
|
|
|
db/blob/blob_source.cc
|
|
|
|
|
db/blob/prefetch_buffer_collection.cc
|
|
|
|
|
db/builder.cc
|
|
|
|
|
db/c.cc
|
|
|
|
|
db/column_family.cc
|
|
|
|
|
db/compaction/compaction.cc
|
|
|
|
|
db/compaction/compaction_iterator.cc
|
|
|
|
|
db/compaction/compaction_picker.cc
|
|
|
|
|
db/compaction/compaction_job.cc
|
|
|
|
|
db/compaction/compaction_picker_fifo.cc
|
|
|
|
|
db/compaction/compaction_picker_level.cc
|
|
|
|
|
db/compaction/compaction_picker_universal.cc
|
|
|
|
|
db/compaction/compaction_service_job.cc
|
|
|
|
|
db/compaction/compaction_state.cc
|
|
|
|
|
db/compaction/compaction_outputs.cc
|
|
|
|
|
db/compaction/sst_partitioner.cc
|
|
|
|
|
db/compaction/subcompaction_state.cc
|
|
|
|
|
db/convenience.cc
|
|
|
|
|
db/db_filesnapshot.cc
|
|
|
|
|
db/db_impl/compacted_db_impl.cc
|
|
|
|
|
db/db_impl/db_impl.cc
|
|
|
|
|
db/db_impl/db_impl_write.cc
|
|
|
|
|
db/db_impl/db_impl_compaction_flush.cc
|
|
|
|
|
db/db_impl/db_impl_files.cc
|
|
|
|
|
db/db_impl/db_impl_open.cc
|
|
|
|
|
db/db_impl/db_impl_debug.cc
|
|
|
|
|
db/db_impl/db_impl_experimental.cc
|
|
|
|
|
db/db_impl/db_impl_readonly.cc
|
|
|
|
|
db/db_impl/db_impl_secondary.cc
|
|
|
|
|
db/db_info_dumper.cc
|
|
|
|
|
db/db_iter.cc
|
|
|
|
|
db/dbformat.cc
|
|
|
|
|
db/error_handler.cc
|
|
|
|
|
db/event_helpers.cc
|
|
|
|
|
db/experimental.cc
|
|
|
|
|
db/external_sst_file_ingestion_job.cc
|
|
|
|
|
db/file_indexer.cc
|
|
|
|
|
db/flush_job.cc
|
|
|
|
|
db/flush_scheduler.cc
|
|
|
|
|
db/forward_iterator.cc
|
|
|
|
|
db/import_column_family_job.cc
|
|
|
|
|
db/internal_stats.cc
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
7 years ago
|
|
|
db/logs_with_prep_tracker.cc
|
|
|
|
|
db/log_reader.cc
|
|
|
|
|
db/log_writer.cc
|
|
|
|
|
db/malloc_stats.cc
|
|
|
|
|
db/memtable.cc
|
|
|
|
|
db/memtable_list.cc
|
|
|
|
|
db/merge_helper.cc
|
|
|
|
|
db/merge_operator.cc
|
|
|
|
|
db/output_validator.cc
|
|
|
|
|
db/periodic_task_scheduler.cc
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
8 years ago
|
|
|
db/range_del_aggregator.cc
|
Use only "local" range tombstones during Get (#4449)
Summary:
Previously, range tombstones were accumulated from every level, which
was necessary if a range tombstone in a higher level covered a key in a lower
level. However, RangeDelAggregator::AddTombstones's complexity is based on
the number of tombstones that are currently stored in it, which is wasteful in
the Get case, where we only need to know the highest sequence number of range
tombstones that cover the key from higher levels, and compute the highest covering
sequence number at the current level. This change introduces this optimization, and
removes the use of RangeDelAggregator from the Get path.
In the benchmark results, the following command was used to initialize the database:
```
./db_bench -db=/dev/shm/5k-rts -use_existing_db=false -benchmarks=filluniquerandom -write_buffer_size=1048576 -compression_type=lz4 -target_file_size_base=1048576 -max_bytes_for_level_base=4194304 -value_size=112 -key_size=16 -block_size=4096 -level_compaction_dynamic_level_bytes=true -num=5000000 -max_background_jobs=12 -benchmark_write_rate_limit=20971520 -range_tombstone_width=100 -writes_per_range_tombstone=100 -max_num_range_tombstones=50000 -bloom_bits=8
```
...and the following command was used to measure read throughput:
```
./db_bench -db=/dev/shm/5k-rts/ -use_existing_db=true -benchmarks=readrandom -disable_auto_compactions=true -num=5000000 -reads=100000 -threads=32
```
The filluniquerandom command was only run once, and the resulting database was used
to measure read performance before and after the PR. Both binaries were compiled with
`DEBUG_LEVEL=0`.
Readrandom results before PR:
```
readrandom : 4.544 micros/op 220090 ops/sec; 16.9 MB/s (63103 of 100000 found)
```
Readrandom results after PR:
```
readrandom : 11.147 micros/op 89707 ops/sec; 6.9 MB/s (63103 of 100000 found)
```
So it's actually slower right now, but this PR paves the way for future optimizations (see #4493).
----
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4449
Differential Revision: D10370575
Pulled By: abhimadan
fbshipit-source-id: 9a2e152be1ef36969055c0e9eb4beb0d96c11f4d
6 years ago
|
|
|
db/range_tombstone_fragmenter.cc
|
|
|
|
|
db/repair.cc
|
|
|
|
|
db/seqno_to_time_mapping.cc
|
|
|
|
|
db/snapshot_impl.cc
|
|
|
|
|
db/table_cache.cc
|
|
|
|
|
db/table_properties_collector.cc
|
|
|
|
|
db/transaction_log_impl.cc
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
5 years ago
|
|
|
db/trim_history_scheduler.cc
|
|
|
|
|
db/version_builder.cc
|
|
|
|
|
db/version_edit.cc
|
|
|
|
|
db/version_edit_handler.cc
|
|
|
|
|
db/version_set.cc
|
Define WAL related classes to be used in VersionEdit and VersionSet (#7164)
Summary:
`WalAddition`, `WalDeletion` are defined in `wal_version.h` and used in `VersionEdit`.
`WalAddition` is used to represent events of creating a new WAL (no size, just log number), or closing a WAL (with size).
`WalDeletion` is used to represent events of deleting or archiving a WAL, it means the WAL is no longer alive (won't be replayed during recovery).
`WalSet` is the set of alive WALs kept in `VersionSet`.
1. Why use `WalDeletion` instead of relying on `MinLogNumber` to identify outdated WALs
On recovery, we can compute `MinLogNumber()` based on the log numbers kept in MANIFEST, any log with number < MinLogNumber can be ignored. So it seems that we don't need to persist `WalDeletion` to MANIFEST, since we can ignore the WALs based on MinLogNumber.
But the `MinLogNumber()` is actually a lower bound, it does not exactly mean that logs starting from MinLogNumber must exist. This is because in a corner case, when a column family is empty and never flushed, its log number is set to the largest log number, but not persisted in MANIFEST. So let's say there are 2 column families, when creating the DB, the first WAL has log number 1, so it's persisted to MANIFEST for both column families. Then CF 0 is empty and never flushed, CF 1 is updated and flushed, so a new WAL with log number 2 is created and persisted to MANIFEST for CF 1. But CF 0's log number in MANIFEST is still 1. So on recovery, MinLogNumber is 1, but since log 1 only contains data for CF 1, and CF 1 is flushed, log 1 might have already been deleted from disk.
We can make `MinLogNumber()` be the exactly minimum log number that must exist, by persisting the most recent log number for empty column families that are not flushed. But if there are N such column families, then every time a new WAL is created, we need to add N records to MANIFEST.
In current design, a record is persisted to MANIFEST only when WAL is created, closed, or deleted/archived, so the number of WAL related records are bounded to 3x number of WALs.
2. Why keep `WalSet` in `VersionSet` instead of applying the `VersionEdit`s to `VersionStorageInfo`
`VersionEdit`s are originally designed to track the addition and deletion of SST files. The SST files are related to column families, each column family has a list of `Version`s, and each `Version` keeps the set of active SST files in `VersionStorageInfo`.
But WALs are a concept of DB, they are not bounded to specific column families. So logically it does not make sense to store WALs in a column family's `Version`s.
Also, `Version`'s purpose is to keep reference to SST / blob files, so that they are not deleted until there is no version referencing them. But a WAL is deleted regardless of version references.
So we keep the WALs in `VersionSet` for the purpose of writing out the DB state's snapshot when creating new MANIFESTs.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7164
Test Plan:
make version_edit_test && ./version_edit_test
make wal_edit_test && ./wal_edit_test
Reviewed By: ltamasi
Differential Revision: D22677936
Pulled By: cheng-chang
fbshipit-source-id: 5a3b6890140e572ffd79eb37e6e4c3c32361a859
4 years ago
|
|
|
db/wal_edit.cc
|
|
|
|
|
db/wal_manager.cc
|
|
|
|
|
db/wide/wide_column_serialization.cc
|
Add support for wide-column point lookups (#10540)
Summary:
The patch adds a new API `GetEntity` that can be used to perform
wide-column point lookups. It also extends the `Get` code path and
the `MemTable` / `MemTableList` and `Version` / `GetContext` logic
accordingly so that wide-column entities can be served from both
memtables and SSTs. If the result of a lookup is a wide-column entity
(`kTypeWideColumnEntity`), it is passed to the application in deserialized
form; if it is a plain old key-value (`kTypeValue`), it is presented as a
wide-column entity with a single default (anonymous) column.
(In contrast, regular `Get` returns plain old key-values as-is, and
returns the value of the default column for wide-column entities, see
https://github.com/facebook/rocksdb/issues/10483 .)
The result of `GetEntity` is a self-contained `PinnableWideColumns` object.
`PinnableWideColumns` contains a `PinnableSlice`, which either stores the
underlying data in its own buffer or holds on to a cache handle. It also contains
a `WideColumns` instance, which indexes the contents of the `PinnableSlice`,
so applications can access the values of columns efficiently.
There are several pieces of functionality which are currently not supported
for wide-column entities: there is currently no `MultiGetEntity` or wide-column
iterator; also, `Merge` and `GetMergeOperands` are not supported, and there
is no `GetEntity` implementation for read-only and secondary instances.
We plan to implement these in future PRs.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10540
Test Plan: `make check`
Reviewed By: akankshamahajan15
Differential Revision: D38847474
Pulled By: ltamasi
fbshipit-source-id: 42311a34ccdfe88b3775e847a5e2a5296e002b5b
2 years ago
|
|
|
db/wide/wide_columns.cc
|
|
|
|
|
db/write_batch.cc
|
|
|
|
|
db/write_batch_base.cc
|
|
|
|
|
db/write_controller.cc
|
|
|
|
|
db/write_thread.cc
|
|
|
|
|
env/composite_env.cc
|
|
|
|
|
env/env.cc
|
|
|
|
|
env/env_chroot.cc
|
|
|
|
|
env/env_encryption.cc
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
5 years ago
|
|
|
env/file_system.cc
|
|
|
|
|
env/file_system_tracer.cc
|
Make backups openable as read-only DBs (#8142)
Summary:
A current limitation of backups is that you don't know the
exact database state of when the backup was taken. With this new
feature, you can at least inspect the backup's DB state without
restoring it by opening it as a read-only DB.
Rather than add something like OpenAsReadOnlyDB to the BackupEngine API,
which would inhibit opening stackable DB implementations read-only
(if/when their APIs support it), we instead provide a DB name and Env
that can be used to open as a read-only DB.
Possible follow-up work:
* Add a version of GetBackupInfo for a single backup.
* Let CreateNewBackup return the BackupID of the newly-created backup.
Implementation details:
Refactored ChrootFileSystem to split off new base class RemapFileSystem,
which allows more general remapping of files. We use this base class to
implement BackupEngineImpl::RemapSharedFileSystem.
To minimize API impact, I decided to just add these fields `name_for_open`
and `env_for_open` to those set by GetBackupInfo when
include_file_details=true. Creating the RemapSharedFileSystem adds a bit
to the memory consumption, perhaps unnecessarily in some cases, but this
has been mitigated by (a) only initialize the RemapSharedFileSystem
lazily when GetBackupInfo with include_file_details=true is called, and
(b) using the existing `shared_ptr<FileInfo>` objects to hold most of the
mapping data.
To enhance API safety, RemapSharedFileSystem is wrapped by new
ReadOnlyFileSystem which rejects any attempts to write. This uncovered a
couple of places in which DB::OpenForReadOnly would write to the
filesystem, so I fixed these. Added a release note because this affects
logging.
Additional minor refactoring in backupable_db.cc to support the new
functionality.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8142
Test Plan:
new test (run with ASAN and UBSAN), added to stress test and
ran it for a while with amplified backup_one_in
Reviewed By: ajkr
Differential Revision: D27535408
Pulled By: pdillinger
fbshipit-source-id: 04666d310aa0261ef6b2385c43ca793ce1dfd148
4 years ago
|
|
|
env/fs_remap.cc
|
|
|
|
|
env/mock_env.cc
|
Experimental support for SST unique IDs (#8990)
Summary:
* New public header unique_id.h and function GetUniqueIdFromTableProperties
which computes a universally unique identifier based on table properties
of table files from recent RocksDB versions.
* Generation of DB session IDs is refactored so that they are
guaranteed unique in the lifetime of a process running RocksDB.
(SemiStructuredUniqueIdGen, new test included.) Along with file numbers,
this enables SST unique IDs to be guaranteed unique among SSTs generated
in a single process, and "better than random" between processes.
See https://github.com/pdillinger/unique_id
* In addition to public API producing 'external' unique IDs, there is a function
for producing 'internal' unique IDs, with functions for converting between the
two. In short, the external ID is "safe" for things people might do with it, and
the internal ID enables more "power user" features for the future. Specifically,
the external ID goes through a hashing layer so that any subset of bits in the
external ID can be used as a hash of the full ID, while also preserving
uniqueness guarantees in the first 128 bits (bijective both on first 128 bits
and on full 192 bits).
Intended follow-up:
* Use the internal unique IDs in cache keys. (Avoid conflicts with https://github.com/facebook/rocksdb/issues/8912) (The file offset can be XORed into
the third 64-bit value of the unique ID.)
* Publish the external unique IDs in FileStorageInfo (https://github.com/facebook/rocksdb/issues/8968)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8990
Test Plan:
Unit tests added, and checking of unique ids in stress test.
NOTE in stress test we do not generate nearly enough files to thoroughly
stress uniqueness, but the test trims off pieces of the ID to check for
uniqueness so that we can infer (with some assumptions) stronger
properties in the aggregate.
Reviewed By: zhichao-cao, mrambacher
Differential Revision: D31582865
Pulled By: pdillinger
fbshipit-source-id: 1f620c4c86af9abe2a8d177b9ccf2ad2b9f48243
3 years ago
|
|
|
env/unique_id_gen.cc
|
|
|
|
|
file/delete_scheduler.cc
|
|
|
|
|
file/file_prefetch_buffer.cc
|
|
|
|
|
file/file_util.cc
|
|
|
|
|
file/filename.cc
|
|
|
|
|
file/line_file_reader.cc
|
|
|
|
|
file/random_access_file_reader.cc
|
|
|
|
|
file/read_write_util.cc
|
|
|
|
|
file/readahead_raf.cc
|
|
|
|
|
file/sequence_file_reader.cc
|
|
|
|
|
file/sst_file_manager_impl.cc
|
|
|
|
|
file/writable_file_writer.cc
|
|
|
|
|
logging/auto_roll_logger.cc
|
|
|
|
|
logging/event_logger.cc
|
|
|
|
|
logging/log_buffer.cc
|
|
|
|
|
memory/arena.cc
|
|
|
|
|
memory/concurrent_arena.cc
|
|
|
|
|
memory/jemalloc_nodump_allocator.cc
|
Provide an allocator for new memory type to be used with RocksDB block cache (#6214)
Summary:
New memory technologies are being developed by various hardware vendors (Intel DCPMM is one such technology currently available). These new memory types require different libraries for allocation and management (such as PMDK and memkind). The high capacities available make it possible to provision large caches (up to several TBs in size), beyond what is achievable with DRAM.
The new allocator provided in this PR uses the memkind library to allocate memory on different media.
**Performance**
We tested the new allocator using db_bench.
- For each test, we vary the size of the block cache (relative to the size of the uncompressed data in the database).
- The database is filled sequentially. Throughput is then measured with a readrandom benchmark.
- We use a uniform distribution as a worst-case scenario.
The plot shows throughput (ops/s) relative to a configuration with no block cache and default allocator.
For all tests, p99 latency is below 500 us.
**Changes**
- Add MemkindKmemAllocator
- Add --use_cache_memkind_kmem_allocator db_bench option (to create an LRU block cache with the new allocator)
- Add detection of memkind library with KMEM DAX support
- Add test for MemkindKmemAllocator
**Minimum Requirements**
- kernel 5.3.12
- ndctl v67 - https://github.com/pmem/ndctl
- memkind v1.10.0 - https://github.com/memkind/memkind
**Memory Configuration**
The allocator uses the MEMKIND_DAX_KMEM memory kind. Follow the instructions on[ memkind’s GitHub page](https://github.com/memkind/memkind) to set up NVDIMM memory accordingly.
Note on memory allocation with NVDIMM memory exposed as system memory.
- The MemkindKmemAllocator will only allocate from NVDIMM memory (using memkind_malloc with MEMKIND_DAX_KMEM kind).
- The default allocator is not restricted to RAM by default. Based on NUMA node latency, the kernel should allocate from local RAM preferentially, but it’s a kernel decision. numactl --preferred/--membind can be used to allocate preferentially/exclusively from the local RAM node.
**Usage**
When creating an LRU cache, pass a MemkindKmemAllocator object as argument.
For example (replace capacity with the desired value in bytes):
```
#include "rocksdb/cache.h"
#include "memory/memkind_kmem_allocator.h"
NewLRUCache(
capacity /*size_t*/,
6 /*cache_numshardbits*/,
false /*strict_capacity_limit*/,
false /*cache_high_pri_pool_ratio*/,
std::make_shared<MemkindKmemAllocator>());
```
Refer to [RocksDB’s block cache documentation](https://github.com/facebook/rocksdb/wiki/Block-Cache) to assign the LRU cache as block cache for a database.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6214
Reviewed By: cheng-chang
Differential Revision: D19292435
fbshipit-source-id: 7202f47b769e7722b539c86c2ffd669f64d7b4e1
5 years ago
|
|
|
memory/memkind_kmem_allocator.cc
|
|
|
|
|
memory/memory_allocator.cc
|
|
|
|
|
memtable/alloc_tracker.cc
|
|
|
|
|
memtable/hash_linklist_rep.cc
|
|
|
|
|
memtable/hash_skiplist_rep.cc
|
|
|
|
|
memtable/skiplistrep.cc
|
|
|
|
|
memtable/vectorrep.cc
|
|
|
|
|
memtable/write_buffer_manager.cc
|
|
|
|
|
monitoring/histogram.cc
|
|
|
|
|
monitoring/histogram_windowing.cc
|
|
|
|
|
monitoring/in_memory_stats_history.cc
|
|
|
|
|
monitoring/instrumented_mutex.cc
|
|
|
|
|
monitoring/iostats_context.cc
|
|
|
|
|
monitoring/perf_context.cc
|
|
|
|
|
monitoring/perf_level.cc
|
|
|
|
|
monitoring/persistent_stats_history.cc
|
|
|
|
|
monitoring/statistics.cc
|
|
|
|
|
monitoring/thread_status_impl.cc
|
|
|
|
|
monitoring/thread_status_updater.cc
|
|
|
|
|
monitoring/thread_status_util.cc
|
|
|
|
|
monitoring/thread_status_util_debug.cc
|
|
|
|
|
options/cf_options.cc
|
|
|
|
|
options/configurable.cc
|
|
|
|
|
options/customizable.cc
|
|
|
|
|
options/db_options.cc
|
|
|
|
|
options/options.cc
|
|
|
|
|
options/options_helper.cc
|
|
|
|
|
options/options_parser.cc
|
|
|
|
|
port/stack_trace.cc
|
|
|
|
|
table/adaptive/adaptive_table_factory.cc
|
|
|
|
|
table/block_based/binary_search_index_reader.cc
|
|
|
|
|
table/block_based/block.cc
|
|
|
|
|
table/block_based/block_based_table_builder.cc
|
|
|
|
|
table/block_based/block_based_table_factory.cc
|
De-template block based table iterator (#6531)
Summary:
Right now block based table iterator is used as both of iterating data for block based table, and for the index iterator for partitioend index. This was initially convenient for introducing a new iterator and block type for new index format, while reducing code change. However, these two usage doesn't go with each other very well. For example, Prev() is never called for partitioned index iterator, and some other complexity is maintained in block based iterators, which is not needed for index iterator but maintainers will always need to reason about it. Furthermore, the template usage is not following Google C++ Style which we are following, and makes a large chunk of code tangled together. This commit separate the two iterators. Right now, here is what it is done:
1. Copy the block based iterator code into partitioned index iterator, and de-template them.
2. Remove some code not needed for partitioned index. The upper bound check and tricks are removed. We never tested performance for those tricks when partitioned index is enabled in the first place. It's unlikelyl to generate performance regression, as creating new partitioned index block is much rarer than data blocks.
3. Separate out the prefetch logic to a helper class and both classes call them.
This commit will enable future follow-ups. One direction is that we might separate index iterator interface for data blocks and index blocks, as they are quite different.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6531
Test Plan: build using make and cmake. And build release
Differential Revision: D20473108
fbshipit-source-id: e48011783b339a4257c204cc07507b171b834b0f
5 years ago
|
|
|
table/block_based/block_based_table_iterator.cc
|
|
|
|
|
table/block_based/block_based_table_reader.cc
|
|
|
|
|
table/block_based/block_builder.cc
|
De-template block based table iterator (#6531)
Summary:
Right now block based table iterator is used as both of iterating data for block based table, and for the index iterator for partitioend index. This was initially convenient for introducing a new iterator and block type for new index format, while reducing code change. However, these two usage doesn't go with each other very well. For example, Prev() is never called for partitioned index iterator, and some other complexity is maintained in block based iterators, which is not needed for index iterator but maintainers will always need to reason about it. Furthermore, the template usage is not following Google C++ Style which we are following, and makes a large chunk of code tangled together. This commit separate the two iterators. Right now, here is what it is done:
1. Copy the block based iterator code into partitioned index iterator, and de-template them.
2. Remove some code not needed for partitioned index. The upper bound check and tricks are removed. We never tested performance for those tricks when partitioned index is enabled in the first place. It's unlikelyl to generate performance regression, as creating new partitioned index block is much rarer than data blocks.
3. Separate out the prefetch logic to a helper class and both classes call them.
This commit will enable future follow-ups. One direction is that we might separate index iterator interface for data blocks and index blocks, as they are quite different.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6531
Test Plan: build using make and cmake. And build release
Differential Revision: D20473108
fbshipit-source-id: e48011783b339a4257c204cc07507b171b834b0f
5 years ago
|
|
|
table/block_based/block_prefetcher.cc
|
|
|
|
|
table/block_based/block_prefix_index.cc
|
|
|
|
|
table/block_based/data_block_hash_index.cc
|
|
|
|
|
table/block_based/data_block_footer.cc
|
Move the filter readers out of the block cache (#5504)
Summary:
Currently, when the block cache is used for the filter block, it is not
really the block itself that is stored in the cache but a FilterBlockReader
object. Since this object is not pure data (it has, for instance, pointers that
might dangle, including in one case a back pointer to the TableReader), it's not
really sharable. To avoid the issues around this, the current code erases the
cache entries when the TableReader is closed (which, BTW, is not sufficient
since a concurrent TableReader might have picked up the object in the meantime).
Instead of doing this, the patch moves the FilterBlockReader out of the cache
altogether, and decouples the filter reader object from the filter block.
In particular, instead of the TableReader owning, or caching/pinning the
FilterBlockReader (based on the customer's settings), with the change the
TableReader unconditionally owns the FilterBlockReader, which in turn
owns/caches/pins the filter block. This change also enables us to reuse the code
paths historically used for data blocks for filters as well.
Note:
Eviction statistics for filter blocks are temporarily broken. We plan to fix this in a
separate phase.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5504
Test Plan: make asan_check
Differential Revision: D16036974
Pulled By: ltamasi
fbshipit-source-id: 770f543c5fb4ed126fd1e04bfd3809cf4ff9c091
5 years ago
|
|
|
table/block_based/filter_block_reader_common.cc
|
|
|
|
|
table/block_based/filter_policy.cc
|
|
|
|
|
table/block_based/flush_block_policy.cc
|
|
|
|
|
table/block_based/full_filter_block.cc
|
|
|
|
|
table/block_based/hash_index_reader.cc
|
|
|
|
|
table/block_based/index_builder.cc
|
|
|
|
|
table/block_based/index_reader_common.cc
|
|
|
|
|
table/block_based/parsed_full_filter_block.cc
|
|
|
|
|
table/block_based/partitioned_filter_block.cc
|
De-template block based table iterator (#6531)
Summary:
Right now block based table iterator is used as both of iterating data for block based table, and for the index iterator for partitioend index. This was initially convenient for introducing a new iterator and block type for new index format, while reducing code change. However, these two usage doesn't go with each other very well. For example, Prev() is never called for partitioned index iterator, and some other complexity is maintained in block based iterators, which is not needed for index iterator but maintainers will always need to reason about it. Furthermore, the template usage is not following Google C++ Style which we are following, and makes a large chunk of code tangled together. This commit separate the two iterators. Right now, here is what it is done:
1. Copy the block based iterator code into partitioned index iterator, and de-template them.
2. Remove some code not needed for partitioned index. The upper bound check and tricks are removed. We never tested performance for those tricks when partitioned index is enabled in the first place. It's unlikelyl to generate performance regression, as creating new partitioned index block is much rarer than data blocks.
3. Separate out the prefetch logic to a helper class and both classes call them.
This commit will enable future follow-ups. One direction is that we might separate index iterator interface for data blocks and index blocks, as they are quite different.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6531
Test Plan: build using make and cmake. And build release
Differential Revision: D20473108
fbshipit-source-id: e48011783b339a4257c204cc07507b171b834b0f
5 years ago
|
|
|
table/block_based/partitioned_index_iterator.cc
|
|
|
|
|
table/block_based/partitioned_index_reader.cc
|
|
|
|
|
table/block_based/reader_common.cc
|
|
|
|
|
table/block_based/uncompression_dict_reader.cc
|
|
|
|
|
table/block_fetcher.cc
|
|
|
|
|
table/cuckoo/cuckoo_table_builder.cc
|
|
|
|
|
table/cuckoo/cuckoo_table_factory.cc
|
|
|
|
|
table/cuckoo/cuckoo_table_reader.cc
|
|
|
|
|
table/format.cc
|
|
|
|
|
table/get_context.cc
|
|
|
|
|
table/iterator.cc
|
|
|
|
|
table/merging_iterator.cc
|
|
|
|
|
table/meta_blocks.cc
|
|
|
|
|
table/persistent_cache_helper.cc
|
|
|
|
|
table/plain/plain_table_bloom.cc
|
|
|
|
|
table/plain/plain_table_builder.cc
|
|
|
|
|
table/plain/plain_table_factory.cc
|
|
|
|
|
table/plain/plain_table_index.cc
|
|
|
|
|
table/plain/plain_table_key_coding.cc
|
|
|
|
|
table/plain/plain_table_reader.cc
|
|
|
|
|
table/sst_file_dumper.cc
|
|
|
|
|
table/sst_file_reader.cc
|
|
|
|
|
table/sst_file_writer.cc
|
|
|
|
|
table/table_factory.cc
|
|
|
|
|
table/table_properties.cc
|
|
|
|
|
table/two_level_iterator.cc
|
Experimental support for SST unique IDs (#8990)
Summary:
* New public header unique_id.h and function GetUniqueIdFromTableProperties
which computes a universally unique identifier based on table properties
of table files from recent RocksDB versions.
* Generation of DB session IDs is refactored so that they are
guaranteed unique in the lifetime of a process running RocksDB.
(SemiStructuredUniqueIdGen, new test included.) Along with file numbers,
this enables SST unique IDs to be guaranteed unique among SSTs generated
in a single process, and "better than random" between processes.
See https://github.com/pdillinger/unique_id
* In addition to public API producing 'external' unique IDs, there is a function
for producing 'internal' unique IDs, with functions for converting between the
two. In short, the external ID is "safe" for things people might do with it, and
the internal ID enables more "power user" features for the future. Specifically,
the external ID goes through a hashing layer so that any subset of bits in the
external ID can be used as a hash of the full ID, while also preserving
uniqueness guarantees in the first 128 bits (bijective both on first 128 bits
and on full 192 bits).
Intended follow-up:
* Use the internal unique IDs in cache keys. (Avoid conflicts with https://github.com/facebook/rocksdb/issues/8912) (The file offset can be XORed into
the third 64-bit value of the unique ID.)
* Publish the external unique IDs in FileStorageInfo (https://github.com/facebook/rocksdb/issues/8968)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8990
Test Plan:
Unit tests added, and checking of unique ids in stress test.
NOTE in stress test we do not generate nearly enough files to thoroughly
stress uniqueness, but the test trims off pieces of the ID to check for
uniqueness so that we can infer (with some assumptions) stronger
properties in the aggregate.
Reviewed By: zhichao-cao, mrambacher
Differential Revision: D31582865
Pulled By: pdillinger
fbshipit-source-id: 1f620c4c86af9abe2a8d177b9ccf2ad2b9f48243
3 years ago
|
|
|
table/unique_id.cc
|
|
|
|
|
test_util/sync_point.cc
|
|
|
|
|
test_util/sync_point_impl.cc
|
|
|
|
|
test_util/testutil.cc
|
|
|
|
|
test_util/transaction_test_util.cc
|
Block cache simulator: Add pysim to simulate caches using reinforcement learning. (#5610)
Summary:
This PR implements cache eviction using reinforcement learning. It includes two implementations:
1. An implementation of Thompson Sampling for the Bernoulli Bandit [1].
2. An implementation of LinUCB with disjoint linear models [2].
The idea is that a cache uses multiple eviction policies, e.g., MRU, LRU, and LFU. The cache learns which eviction policy is the best and uses it upon a cache miss.
Thompson Sampling is contextless and does not include any features.
LinUCB includes features such as level, block type, caller, column family id to decide which eviction policy to use.
[1] Daniel J. Russo, Benjamin Van Roy, Abbas Kazerouni, Ian Osband, and Zheng Wen. 2018. A Tutorial on Thompson Sampling. Found. Trends Mach. Learn. 11, 1 (July 2018), 1-96. DOI: https://doi.org/10.1561/2200000070
[2] Lihong Li, Wei Chu, John Langford, and Robert E. Schapire. 2010. A contextual-bandit approach to personalized news article recommendation. In Proceedings of the 19th international conference on World wide web (WWW '10). ACM, New York, NY, USA, 661-670. DOI=http://dx.doi.org/10.1145/1772690.1772758
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5610
Differential Revision: D16435067
Pulled By: HaoyuHuang
fbshipit-source-id: 6549239ae14115c01cb1e70548af9e46d8dc21bb
5 years ago
|
|
|
tools/block_cache_analyzer/block_cache_trace_analyzer.cc
|
|
|
|
|
tools/dump/db_dump_tool.cc
|
|
|
|
|
tools/io_tracer_parser_tool.cc
|
|
|
|
|
tools/ldb_cmd.cc
|
|
|
|
|
tools/ldb_tool.cc
|
|
|
|
|
tools/sst_dump_tool.cc
|
RocksDB Trace Analyzer (#4091)
Summary:
A framework of trace analyzing for RocksDB
After collecting the trace by using the tool of [PR #3837](https://github.com/facebook/rocksdb/pull/3837). User can use the Trace Analyzer to interpret, analyze, and characterize the collected workload.
**Input:**
1. trace file
2. Whole keys space file
**Statistics:**
1. Access count of each operation (Get, Put, Delete, SingleDelete, DeleteRange, Merge) in each column family.
2. Key hotness (access count) of each one
3. Key space separation based on given prefix
4. Key size distribution
5. Value size distribution if appliable
6. Top K accessed keys
7. QPS statistics including the average QPS and peak QPS
8. Top K accessed prefix
9. The query correlation analyzing, output the number of X after Y and the corresponding average time
intervals
**Output:**
1. key access heat map (either in the accessed key space or whole key space)
2. trace sequence file (interpret the raw trace file to line base text file for future use)
3. Time serial (The key space ID and its access time)
4. Key access count distritbution
5. Key size distribution
6. Value size distribution (in each intervals)
7. whole key space separation by the prefix
8. Accessed key space separation by the prefix
9. QPS of each operation and each column family
10. Top K QPS and their accessed prefix range
**Test:**
1. Added the unit test of analyzing Get, Put, Delete, SingleDelete, DeleteRange, Merge
2. Generated the trace and analyze the trace
**Implemented but not tested (due to the limitation of trace_replay):**
1. Analyzing Iterator, supporting Seek() and SeekForPrev() analyzing
2. Analyzing the number of Key found by Get
**Future Work:**
1. Support execution time analyzing of each requests
2. Support cache hit situation and block read situation of Get
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4091
Differential Revision: D9256157
Pulled By: zhichao-cao
fbshipit-source-id: f0ceacb7eedbc43a3eee6e85b76087d7832a8fe6
6 years ago
|
|
|
tools/trace_analyzer_tool.cc
|
|
|
|
|
trace_replay/block_cache_tracer.cc
|
|
|
|
|
trace_replay/io_tracer.cc
|
|
|
|
|
trace_replay/trace_record_handler.cc
|
|
|
|
|
trace_replay/trace_record_result.cc
|
|
|
|
|
trace_replay/trace_record.cc
|
|
|
|
|
trace_replay/trace_replay.cc
|
Multi file concurrency in MultiGet using coroutines and async IO (#9968)
Summary:
This PR implements a coroutine version of batched MultiGet in order to concurrently read from multiple SST files in a level using async IO, thus reducing the latency of the MultiGet. The API from the user perspective is still synchronous and single threaded, with the RocksDB part of the processing happening in the context of the caller's thread. In Version::MultiGet, the decision is made whether to call synchronous or coroutine code.
A good way to review this PR is to review the first 4 commits in order - de773b3, 70c2f70, 10b50e1, and 377a597 - before reviewing the rest.
TODO:
1. Figure out how to build it in CircleCI (requires some dependencies to be installed)
2. Do some stress testing with coroutines enabled
No regression in synchronous MultiGet between this branch and main -
```
./db_bench -use_existing_db=true --db=/data/mysql/rocksdb/prefix_scan -benchmarks="readseq,multireadrandom" -key_size=32 -value_size=512 -num=5000000 -batch_size=64 -multiread_batched=true -use_direct_reads=false -duration=60 -ops_between_duration_checks=1 -readonly=true -adaptive_readahead=true -threads=16 -cache_size=10485760000 -async_io=false -multiread_stride=40000 -statistics
```
Branch - ```multireadrandom : 4.025 micros/op 3975111 ops/sec 60.001 seconds 238509056 operations; 2062.3 MB/s (14767808 of 14767808 found)```
Main - ```multireadrandom : 3.987 micros/op 4013216 ops/sec 60.001 seconds 240795392 operations; 2082.1 MB/s (15231040 of 15231040 found)```
More benchmarks in various scenarios are given below. The measurements were taken with ```async_io=false``` (no coroutines) and ```async_io=true``` (use coroutines). For an IO bound workload (with every key requiring an IO), the coroutines version shows a clear benefit, being ~2.6X faster. For CPU bound workloads, the coroutines version has ~6-15% higher CPU utilization, depending on how many keys overlap an SST file.
1. Single thread IO bound workload on remote storage with sparse MultiGet batch keys (~1 key overlap/file) -
No coroutines - ```multireadrandom : 831.774 micros/op 1202 ops/sec 60.001 seconds 72136 operations; 0.6 MB/s (72136 of 72136 found)```
Using coroutines - ```multireadrandom : 318.742 micros/op 3137 ops/sec 60.003 seconds 188248 operations; 1.6 MB/s (188248 of 188248 found)```
2. Single thread CPU bound workload (all data cached) with ~1 key overlap/file -
No coroutines - ```multireadrandom : 4.127 micros/op 242322 ops/sec 60.000 seconds 14539384 operations; 125.7 MB/s (14539384 of 14539384 found)```
Using coroutines - ```multireadrandom : 4.741 micros/op 210935 ops/sec 60.000 seconds 12656176 operations; 109.4 MB/s (12656176 of 12656176 found)```
3. Single thread CPU bound workload with ~2 key overlap/file -
No coroutines - ```multireadrandom : 3.717 micros/op 269000 ops/sec 60.000 seconds 16140024 operations; 139.6 MB/s (16140024 of 16140024 found)```
Using coroutines - ```multireadrandom : 4.146 micros/op 241204 ops/sec 60.000 seconds 14472296 operations; 125.1 MB/s (14472296 of 14472296 found)```
4. CPU bound multi-threaded (16 threads) with ~4 key overlap/file -
No coroutines - ```multireadrandom : 4.534 micros/op 3528792 ops/sec 60.000 seconds 211728728 operations; 1830.7 MB/s (12737024 of 12737024 found) ```
Using coroutines - ```multireadrandom : 4.872 micros/op 3283812 ops/sec 60.000 seconds 197030096 operations; 1703.6 MB/s (12548032 of 12548032 found) ```
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9968
Reviewed By: akankshamahajan15
Differential Revision: D36348563
Pulled By: anand1976
fbshipit-source-id: c0ce85a505fd26ebfbb09786cbd7f25202038696
3 years ago
|
|
|
util/async_file_reader.cc
|
Eliminate unnecessary (slow) block cache Ref()ing in MultiGet (#9899)
Summary:
When MultiGet() determines that multiple query keys can be
served by examining the same data block in block cache (one Lookup()),
each PinnableSlice referring to data in that data block needs to hold
on to the block in cache so that they can be released at arbitrary
times by the API user. Historically this is accomplished with extra
calls to Ref() on the Handle from Lookup(), with each PinnableSlice
cleanup calling Release() on the Handle, but this creates extra
contention on the block cache for the extra Ref()s and Release()es,
especially because they hit the same cache shard repeatedly.
In the case of merge operands (possibly more cases?), the problem was
compounded by doing an extra Ref()+eventual Release() for each merge
operand for a key reusing a block (which could be the same key!), rather
than one Ref() per key. (Note: the non-shared case with `biter` was
already one per key.)
This change optimizes MultiGet not to rely on these extra, contentious
Ref()+Release() calls by instead, in the shared block case, wrapping
the cache Release() cleanup in a refcounted object referenced by the
PinnableSlices, such that after the last wrapped reference is released,
the cache entry is Release()ed. Relaxed atomic refcounts should be
much faster than mutex-guarded Ref() and Release(), and much less prone
to a performance cliff when MultiGet() does a lot of block sharing.
Note that I did not use std::shared_ptr, because that would require an
extra indirection object (shared_ptr itself new/delete) in order to
associate a ref increment/decrement with a Cleanable cleanup entry. (If
I assumed it was the size of two pointers, I could do some hackery to
make it work without the extra indirection, but that's too fragile.)
Some details:
* Fixed (removed) extra block cache tracing entries in cases of cache
entry reuse in MultiGet, but it's likely that in some other cases traces
are missing (XXX comment inserted)
* Moved existing implementations for cleanable.h from iterator.cc to
new cleanable.cc
* Improved API comments on Cleanable
* Added a public SharedCleanablePtr class to cleanable.h in case others
could benefit from the same pattern (potentially many Cleanables and/or
smart pointers referencing a shared Cleanable)
* Add a typedef for MultiGetContext::Mask
* Some variable renaming for clarity
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9899
Test Plan:
Added unit tests for SharedCleanablePtr.
Greatly enhanced ability of existing tests to detect cache use-after-free.
* Release PinnableSlices from MultiGet as they are read rather than in
bulk (in db_test_util wrapper).
* In ASAN build, default to using a trivially small LRUCache for block_cache
so that entries are immediately erased when unreferenced. (Updated two
tests that depend on caching.) New ASAN testsuite running time seems
OK to me.
If I introduce a bug into my implementation where we skip the shared
cleanups on block reuse, ASAN detects the bug in
`db_basic_test *MultiGet*`. If I remove either of the above testing
enhancements, the bug is not detected.
Consider for follow-up work: manipulate or randomize ordering of
PinnableSlice use and release from MultiGet db_test_util wrapper. But in
typical cases, natural ordering gives pretty good functional coverage.
Performance test:
In the extreme (but possible) case of MultiGetting the same or adjacent keys
in a batch, throughput can improve by an order of magnitude.
`./db_bench -benchmarks=multireadrandom -db=/dev/shm/testdb -readonly -num=5 -duration=10 -threads=20 -multiread_batched -batch_size=200`
Before ops/sec, num=5: 1,384,394
Before ops/sec, num=500: 6,423,720
After ops/sec, num=500: 10,658,794
After ops/sec, num=5: 16,027,257
Also note that previously, with high parallelism, having query keys
concentrated in a single block was worse than spreading them out a bit. Now
concentrated in a single block is faster than spread out, which is hopefully
consistent with natural expectation.
Random query performance: with num=1000000, over 999 x 10s runs running before & after simultaneously (each -threads=12):
Before: multireadrandom [AVG 999 runs] : 1088699 (± 7344) ops/sec; 120.4 (± 0.8 ) MB/sec
After: multireadrandom [AVG 999 runs] : 1090402 (± 7230) ops/sec; 120.6 (± 0.8 ) MB/sec
Possibly better, possibly in the noise.
Reviewed By: anand1976
Differential Revision: D35907003
Pulled By: pdillinger
fbshipit-source-id: bbd244d703649a8ca12d476f2d03853ed9d1a17e
3 years ago
|
|
|
util/cleanable.cc
|
|
|
|
|
util/coding.cc
|
|
|
|
|
util/compaction_job_stats_impl.cc
|
|
|
|
|
util/comparator.cc
|
|
|
|
|
util/compression.cc
|
|
|
|
|
util/compression_context_cache.cc
|
Concurrent task limiter for compaction thread control (#4332)
Summary:
The PR is targeting to resolve the issue of:
https://github.com/facebook/rocksdb/issues/3972#issue-330771918
We have a rocksdb created with leveled-compaction with multiple column families (CFs), some of CFs are using HDD to store big and less frequently accessed data and others are using SSD.
When there are continuously write traffics going on to all CFs, the compaction thread pool is mostly occupied by those slow HDD compactions, which blocks fully utilize SSD bandwidth.
Since atomic write and transaction is needed across CFs, so splitting it to multiple rocksdb instance is not an option for us.
With the compaction thread control, we got 30%+ HDD write throughput gain, and also a lot smooth SSD write since less write stall happening.
ConcurrentTaskLimiter can be shared with multi-CFs across rocksdb instances, so the feature does not only work for multi-CFs scenarios, but also for multi-rocksdbs scenarios, who need disk IO resource control per tenant.
The usage is straight forward:
e.g.:
//
// Enable compaction thread limiter thru ColumnFamilyOptions
//
std::shared_ptr<ConcurrentTaskLimiter> ctl(NewConcurrentTaskLimiter("foo_limiter", 4));
Options options;
ColumnFamilyOptions cf_opt(options);
cf_opt.compaction_thread_limiter = ctl;
...
//
// Compaction thread limiter can be tuned or disabled on-the-fly
//
ctl->SetMaxOutstandingTask(12); // enlarge to 12 tasks
...
ctl->ResetMaxOutstandingTask(); // disable (bypass) thread limiter
ctl->SetMaxOutstandingTask(-1); // Same as above
...
ctl->SetMaxOutstandingTask(0); // full throttle (0 task)
//
// Sharing compaction thread limiter among CFs (to resolve multiple storage perf issue)
//
std::shared_ptr<ConcurrentTaskLimiter> ctl_ssd(NewConcurrentTaskLimiter("ssd_limiter", 8));
std::shared_ptr<ConcurrentTaskLimiter> ctl_hdd(NewConcurrentTaskLimiter("hdd_limiter", 4));
Options options;
ColumnFamilyOptions cf_opt_ssd1(options);
ColumnFamilyOptions cf_opt_ssd2(options);
ColumnFamilyOptions cf_opt_hdd1(options);
ColumnFamilyOptions cf_opt_hdd2(options);
ColumnFamilyOptions cf_opt_hdd3(options);
// SSD CFs
cf_opt_ssd1.compaction_thread_limiter = ctl_ssd;
cf_opt_ssd2.compaction_thread_limiter = ctl_ssd;
// HDD CFs
cf_opt_hdd1.compaction_thread_limiter = ctl_hdd;
cf_opt_hdd2.compaction_thread_limiter = ctl_hdd;
cf_opt_hdd3.compaction_thread_limiter = ctl_hdd;
...
//
// The limiter is disabled by default (or set to nullptr explicitly)
//
Options options;
ColumnFamilyOptions cf_opt(options);
cf_opt.compaction_thread_limiter = nullptr;
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4332
Differential Revision: D13226590
Pulled By: siying
fbshipit-source-id: 14307aec55b8bd59c8223d04aa6db3c03d1b0c1d
6 years ago
|
|
|
util/concurrent_task_limiter_impl.cc
|
|
|
|
|
util/crc32c.cc
|
|
|
|
|
util/dynamic_bloom.cc
|
|
|
|
|
util/hash.cc
|
|
|
|
|
util/murmurhash.cc
|
|
|
|
|
util/random.cc
|
|
|
|
|
util/rate_limiter.cc
|
Refine Ribbon configuration, improve testing, add Homogeneous (#7879)
Summary:
This change only affects non-schema-critical aspects of the production candidate Ribbon filter. Specifically, it refines choice of internal configuration parameters based on inputs. The changes are minor enough that the schema tests in bloom_test, some of which depend on this, are unaffected. There are also some minor optimizations and refactorings.
This would be a schema change for "smash" Ribbon, to fix some known issues with small filters, but "smash" Ribbon is not accessible in public APIs. Unit test CompactnessAndBacktrackAndFpRate updated to test small and medium-large filters. Run with --thoroughness=100 or so for much better detection power (not appropriate for continuous regression testing).
Homogenous Ribbon:
This change adds internally a Ribbon filter variant we call Homogeneous Ribbon, in collaboration with Stefan Walzer. The expected "result" value for every key is zero, instead of computed from a hash. Entropy for queries not to be false positives comes from free variables ("overhead") in the solution structure, which are populated pseudorandomly. Construction is slightly faster for not tracking result values, and never fails. Instead, FP rate can jump up whenever and whereever entries are packed too tightly. For small structures, we can choose overhead to make this FP rate jump unlikely, as seen in updated unit test CompactnessAndBacktrackAndFpRate.
Unlike standard Ribbon, Homogeneous Ribbon seems to scale to arbitrary number of keys when accepting an FP rate penalty for small pockets of high FP rate in the structure. For example, 64-bit ribbon with 8 solution columns and 10% allocated space overhead for slots seems to achieve about 10.5% space overhead vs. information-theoretic minimum based on its observed FP rate with expected pockets of degradation. (FP rate is close to 1/256.) If targeting a higher FP rate with fewer solution columns, Homogeneous Ribbon can be even more space efficient, because the penalty from degradation is relatively smaller. If targeting a lower FP rate, Homogeneous Ribbon is less space efficient, as more allocated overhead is needed to keep the FP rate impact of degradation relatively under control. The new OptimizeHomogAtScale tool in ribbon_test helps to find these optimal allocation overheads for different numbers of solution columns. And Ribbon widths, with 128-bit Ribbon apparently cutting space overheads in half vs. 64-bit.
Other misc item specifics:
* Ribbon APIs in util/ribbon_config.h now provide configuration data for not just 5% construction failure rate (95% success), but also 50% and 0.1%.
* Note that the Ribbon structure does not exhibit "threshold" behavior as standard Xor filter does, so there is a roughly fixed space penalty to cut construction failure rate in half. Thus, there isn't really an "almost sure" setting.
* Although we can extrapolate settings for large filters, we don't have a good formula for configuring smaller filters (< 2^17 slots or so), and efforts to summarize with a formula have failed. Thus, small data is hard-coded from updated FindOccupancy tool.
* Enhances ApproximateNumEntries for public API Ribbon using more precise data (new API GetNumToAdd), thus a more accurate but not perfect reversal of CalculateSpace. (bloom_test updated to expect the greater precision)
* Move EndianSwapValue from coding.h to coding_lean.h to keep Ribbon code easily transferable from RocksDB
* Add some missing 'const' to member functions
* Small optimization to 128-bit BitParity
* Small refactoring of BandingStorage in ribbon_alg.h to support Homogeneous Ribbon
* CompactnessAndBacktrackAndFpRate now has an "expand" test: on construction failure, a possible alternative to re-seeding hash functions is simply to increase the number of slots (allocated space overhead) and try again with essentially the same hash values. (Start locations will be different roundings of the same scaled hash values--because fastrange not mod.) This seems to be as effective or more effective than re-seeding, as long as we increase the number of slots (m) by roughly m += m/w where w is the Ribbon width. This way, there is effectively an expansion by one slot for each ribbon-width window in the banding. (This approach assumes that getting "bad data" from your hash function is as unlikely as it naturally should be, e.g. no adversary.)
* 32-bit and 16-bit Ribbon configurations are added to ribbon_test for understanding their behavior, e.g. with FindOccupancy. They are not considered useful at this time and not tested with CompactnessAndBacktrackAndFpRate.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7879
Test Plan: unit test updates included
Reviewed By: jay-zhuang
Differential Revision: D26371245
Pulled By: pdillinger
fbshipit-source-id: da6600d90a3785b99ad17a88b2a3027710b4ea3a
4 years ago
|
|
|
util/ribbon_config.cc
|
|
|
|
|
util/slice.cc
|
|
|
|
|
util/file_checksum_helper.cc
|
|
|
|
|
util/status.cc
|
|
|
|
|
util/string_util.cc
|
|
|
|
|
util/thread_local.cc
|
|
|
|
|
util/threadpool_imp.cc
|
|
|
|
|
util/xxhash.cc
|
|
|
|
|
utilities/agg_merge/agg_merge.cc
|
|
|
|
|
utilities/backup/backup_engine.cc
|
|
|
|
|
utilities/blob_db/blob_compaction_filter.cc
|
|
|
|
|
utilities/blob_db/blob_db.cc
|
|
|
|
|
utilities/blob_db/blob_db_impl.cc
|
|
|
|
|
utilities/blob_db/blob_db_impl_filesnapshot.cc
|
|
|
|
|
utilities/blob_db/blob_dump_tool.cc
|
|
|
|
|
utilities/blob_db/blob_file.cc
|
|
|
|
|
utilities/cache_dump_load.cc
|
|
|
|
|
utilities/cache_dump_load_impl.cc
|
|
|
|
|
utilities/cassandra/cassandra_compaction_filter.cc
|
|
|
|
|
utilities/cassandra/format.cc
|
|
|
|
|
utilities/cassandra/merge_operator.cc
|
|
|
|
|
utilities/checkpoint/checkpoint_impl.cc
|
|
|
|
|
utilities/compaction_filters.cc
|
|
|
|
|
utilities/compaction_filters/remove_emptyvalue_compactionfilter.cc
|
|
|
|
|
utilities/counted_fs.cc
|
|
|
|
|
utilities/debug.cc
|
|
|
|
|
utilities/env_mirror.cc
|
|
|
|
|
utilities/env_timed.cc
|
|
|
|
|
utilities/fault_injection_env.cc
|
|
|
|
|
utilities/fault_injection_fs.cc
|
|
|
|
|
utilities/fault_injection_secondary_cache.cc
|
|
|
|
|
utilities/leveldb_options/leveldb_options.cc
|
|
|
|
|
utilities/memory/memory_util.cc
|
|
|
|
|
utilities/merge_operators.cc
|
|
|
|
|
utilities/merge_operators/bytesxor.cc
|
|
|
|
|
utilities/merge_operators/max.cc
|
|
|
|
|
utilities/merge_operators/put.cc
|
New API to get all merge operands for a Key (#5604)
Summary:
This is a new API added to db.h to allow for fetching all merge operands associated with a Key. The main motivation for this API is to support use cases where doing a full online merge is not necessary as it is performance sensitive. Example use-cases:
1. Update subset of columns and read subset of columns -
Imagine a SQL Table, a row is encoded as a K/V pair (as it is done in MyRocks). If there are many columns and users only updated one of them, we can use merge operator to reduce write amplification. While users only read one or two columns in the read query, this feature can avoid a full merging of the whole row, and save some CPU.
2. Updating very few attributes in a value which is a JSON-like document -
Updating one attribute can be done efficiently using merge operator, while reading back one attribute can be done more efficiently if we don't need to do a full merge.
----------------------------------------------------------------------------------------------------
API :
Status GetMergeOperands(
const ReadOptions& options, ColumnFamilyHandle* column_family,
const Slice& key, PinnableSlice* merge_operands,
GetMergeOperandsOptions* get_merge_operands_options,
int* number_of_operands)
Example usage :
int size = 100;
int number_of_operands = 0;
std::vector<PinnableSlice> values(size);
GetMergeOperandsOptions merge_operands_info;
db_->GetMergeOperands(ReadOptions(), db_->DefaultColumnFamily(), "k1", values.data(), merge_operands_info, &number_of_operands);
Description :
Returns all the merge operands corresponding to the key. If the number of merge operands in DB is greater than merge_operands_options.expected_max_number_of_operands no merge operands are returned and status is Incomplete. Merge operands returned are in the order of insertion.
merge_operands-> Points to an array of at-least merge_operands_options.expected_max_number_of_operands and the caller is responsible for allocating it. If the status returned is Incomplete then number_of_operands will contain the total number of merge operands found in DB for key.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5604
Test Plan:
Added unit test and perf test in db_bench that can be run using the command:
./db_bench -benchmarks=getmergeoperands --merge_operator=sortlist
Differential Revision: D16657366
Pulled By: vjnadimpalli
fbshipit-source-id: 0faadd752351745224ee12d4ae9ef3cb529951bf
5 years ago
|
|
|
utilities/merge_operators/sortlist.cc
|
|
|
|
|
utilities/merge_operators/string_append/stringappend.cc
|
|
|
|
|
utilities/merge_operators/string_append/stringappend2.cc
|
|
|
|
|
utilities/merge_operators/uint64add.cc
|
|
|
|
|
utilities/object_registry.cc
|
|
|
|
|
utilities/option_change_migration/option_change_migration.cc
|
Add OptionsUtil::LoadOptionsFromFile() API
Summary:
This patch adds OptionsUtil::LoadOptionsFromFile() and
OptionsUtil::LoadLatestOptionsFromDB(), which allow developers
to construct DBOptions and ColumnFamilyOptions from a RocksDB
options file. Note that most pointer-typed options such as
merge_operator will not be constructed.
With this API, developers no longer need to remember all the
options in order to reopen an existing rocksdb instance like
the following:
DBOptions db_options;
std::vector<std::string> cf_names;
std::vector<ColumnFamilyOptions> cf_opts;
// Load primitive-typed options from an existing DB
OptionsUtil::LoadLatestOptionsFromDB(
dbname, &db_options, &cf_names, &cf_opts);
// Initialize necessary pointer-typed options
cf_opts[0].merge_operator.reset(new MyMergeOperator());
...
// Construct the vector of ColumnFamilyDescriptor
std::vector<ColumnFamilyDescriptor> cf_descs;
for (size_t i = 0; i < cf_opts.size(); ++i) {
cf_descs.emplace_back(cf_names[i], cf_opts[i]);
}
// Open the DB
DB* db = nullptr;
std::vector<ColumnFamilyHandle*> cf_handles;
auto s = DB::Open(db_options, dbname, cf_descs,
&handles, &db);
Test Plan:
Augment existing tests in column_family_test
options_test
db_test
Reviewers: igor, IslamAbdelRahman, sdong, anthony
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D49095
9 years ago
|
|
|
utilities/options/options_util.cc
|
|
|
|
|
utilities/persistent_cache/block_cache_tier.cc
|
|
|
|
|
utilities/persistent_cache/block_cache_tier_file.cc
|
|
|
|
|
utilities/persistent_cache/block_cache_tier_metadata.cc
|
|
|
|
|
utilities/persistent_cache/persistent_cache_tier.cc
|
|
|
|
|
utilities/persistent_cache/volatile_tier_impl.cc
|
|
|
|
|
utilities/simulator_cache/cache_simulator.cc
|
|
|
|
|
utilities/simulator_cache/sim_cache.cc
|
|
|
|
|
utilities/table_properties_collectors/compact_on_deletion_collector.cc
|
|
|
|
|
utilities/trace/file_trace_reader_writer.cc
|
|
|
|
|
utilities/trace/replayer_impl.cc
|
|
|
|
|
utilities/transactions/lock/lock_manager.cc
|
|
|
|
|
utilities/transactions/lock/point/point_lock_tracker.cc
|
|
|
|
|
utilities/transactions/lock/point/point_lock_manager.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/range_tree_lock_manager.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/range_tree_lock_tracker.cc
|
|
|
|
|
utilities/transactions/optimistic_transaction_db_impl.cc
|
|
|
|
|
utilities/transactions/optimistic_transaction.cc
|
|
|
|
|
utilities/transactions/pessimistic_transaction.cc
|
|
|
|
|
utilities/transactions/pessimistic_transaction_db.cc
|
|
|
|
|
utilities/transactions/snapshot_checker.cc
|
|
|
|
|
utilities/transactions/transaction_base.cc
|
|
|
|
|
utilities/transactions/transaction_db_mutex_impl.cc
|
Pessimistic Transactions
Summary:
Initial implementation of Pessimistic Transactions. This diff contains the api changes discussed in D38913. This diff is pretty large, so let me know if people would prefer to meet up to discuss it.
MyRocks folks: please take a look at the API in include/rocksdb/utilities/transaction[_db].h and let me know if you have any issues.
Also, you'll notice a couple of TODOs in the implementation of RollbackToSavePoint(). After chatting with Siying, I'm going to send out a separate diff for an alternate implementation of this feature that implements the rollback inside of WriteBatch/WriteBatchWithIndex. We can then decide which route is preferable.
Next, I'm planning on doing some perf testing and then integrating this diff into MongoRocks for further testing.
Test Plan: Unit tests, db_bench parallel testing.
Reviewers: igor, rven, sdong, yhchiang, yoshinorim
Reviewed By: sdong
Subscribers: hermanlee4, maykov, spetrunia, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D40869
10 years ago
|
|
|
utilities/transactions/transaction_util.cc
|
|
|
|
|
utilities/transactions/write_prepared_txn.cc
|
|
|
|
|
utilities/transactions/write_prepared_txn_db.cc
|
|
|
|
|
utilities/transactions/write_unprepared_txn.cc
|
|
|
|
|
utilities/transactions/write_unprepared_txn_db.cc
|
|
|
|
|
utilities/ttl/db_ttl_impl.cc
|
|
|
|
|
utilities/wal_filter.cc
|
|
|
|
|
utilities/write_batch_with_index/write_batch_with_index.cc
|
|
|
|
|
utilities/write_batch_with_index/write_batch_with_index_internal.cc)
|
|
|
|
|
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/concurrent_tree.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/keyrange.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/lock_request.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/locktree.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/manager.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/range_buffer.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/treenode.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/txnid_set.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/locktree/wfg.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/standalone_port.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/util/dbt.cc
|
|
|
|
|
utilities/transactions/lock/range/range_tree/lib/util/memarena.cc)
|
|
|
|
|
|
|
|
|
|
message(STATUS "ROCKSDB_PLUGINS: ${ROCKSDB_PLUGINS}")
|
|
|
|
|
if ( ROCKSDB_PLUGINS )
|
|
|
|
|
string(REPLACE " " ";" PLUGINS ${ROCKSDB_PLUGINS})
|
|
|
|
|
foreach (plugin ${PLUGINS})
|
|
|
|
|
add_subdirectory("plugin/${plugin}")
|
|
|
|
|
foreach (src ${${plugin}_SOURCES})
|
|
|
|
|
list(APPEND SOURCES plugin/${plugin}/${src})
|
|
|
|
|
set_source_files_properties(
|
|
|
|
|
plugin/${plugin}/${src}
|
|
|
|
|
PROPERTIES COMPILE_FLAGS "${${plugin}_COMPILE_FLAGS}")
|
|
|
|
|
endforeach()
|
|
|
|
|
foreach (path ${${plugin}_INCLUDE_PATHS})
|
|
|
|
|
include_directories(${path})
|
|
|
|
|
endforeach()
|
|
|
|
|
foreach (lib ${${plugin}_LIBS})
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS ${lib})
|
|
|
|
|
endforeach()
|
|
|
|
|
foreach (link_path ${${plugin}_LINK_PATHS})
|
|
|
|
|
link_directories(AFTER ${link_path})
|
|
|
|
|
endforeach()
|
|
|
|
|
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${${plugin}_CMAKE_SHARED_LINKER_FLAGS}")
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${${plugin}_CMAKE_EXE_LINKER_FLAGS}")
|
|
|
|
|
endforeach()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(HAVE_SSE42 AND NOT MSVC)
|
|
|
|
|
set_source_files_properties(
|
|
|
|
|
util/crc32c.cc
|
|
|
|
|
PROPERTIES COMPILE_FLAGS "-msse4.2 -mpclmul")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
util/crc32c_ppc.c
|
|
|
|
|
util/crc32c_ppc_asm.S)
|
|
|
|
|
endif(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
|
|
|
|
|
|
|
|
|
|
if(HAS_ARMV8_CRC)
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
util/crc32c_arm64.cc)
|
|
|
|
|
endif(HAS_ARMV8_CRC)
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
port/win/io_win.cc
|
|
|
|
|
port/win/env_win.cc
|
|
|
|
|
port/win/env_default.cc
|
|
|
|
|
port/win/port_win.cc
|
|
|
|
|
port/win/win_logger.cc
|
|
|
|
|
port/win/win_thread.cc)
|
|
|
|
|
if(WITH_XPRESS)
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
port/win/xpress_win.cc)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_JEMALLOC)
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
port/win/win_jemalloc.cc)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
else()
|
|
|
|
|
list(APPEND SOURCES
|
|
|
|
|
port/port_posix.cc
|
|
|
|
|
env/env_posix.cc
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
5 years ago
|
|
|
env/fs_posix.cc
|
|
|
|
|
env/io_posix.cc)
|
|
|
|
|
endif()
|
|
|
|
|
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
3 years ago
|
|
|
if(USE_FOLLY)
|
|
|
|
|
list(APPEND SOURCES
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
3 years ago
|
|
|
third-party/folly/folly/container/detail/F14Table.cpp
|
|
|
|
|
third-party/folly/folly/detail/Futex.cpp
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
3 years ago
|
|
|
third-party/folly/folly/lang/SafeAssert.cpp
|
|
|
|
|
third-party/folly/folly/lang/ToAscii.cpp
|
|
|
|
|
third-party/folly/folly/ScopeGuard.cpp
|
|
|
|
|
third-party/folly/folly/synchronization/AtomicNotification.cpp
|
|
|
|
|
third-party/folly/folly/synchronization/DistributedMutex.cpp
|
|
|
|
|
third-party/folly/folly/synchronization/ParkingLot.cpp)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(ROCKSDB_STATIC_LIB rocksdb${ARTIFACT_SUFFIX})
|
|
|
|
|
set(ROCKSDB_SHARED_LIB rocksdb-shared${ARTIFACT_SUFFIX})
|
|
|
|
|
|
|
|
|
|
option(ROCKSDB_BUILD_SHARED "Build shared versions of the RocksDB libraries" ON)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
set(SYSTEM_LIBS ${SYSTEM_LIBS} shlwapi.lib rpcrt4.lib)
|
|
|
|
|
else()
|
cross-platform compatibility improvements
Summary:
We've had a couple CockroachDB users fail to build RocksDB on exotic platforms, so I figured I'd try my hand at solving these issues upstream. The problems stem from a) `USE_SSE=1` being too aggressive about turning on SSE4.2, even on toolchains that don't support SSE4.2 and b) RocksDB attempting to detect support for thread-local storage based on OS, even though it can vary by compiler on the same OS.
See the individual commit messages for details. Regarding SSE support, this PR should change virtually nothing for non-CMake based builds. `make`, `PORTABLE=1 make`, `USE_SSE=1 make`, and `PORTABLE=1 USE_SSE=1 make` function exactly as before, except that SSE support will be automatically disabled when a simple SSE4.2-using test program fails to compile, as it does on OpenBSD. (OpenBSD's ports GCC supports SSE4.2, but its binutils do not, so `__SSE_4_2__` is defined but an SSE4.2-using program will fail to assemble.) A warning is emitted in this case. The CMake build is modified to support the same set of options, except that `USE_SSE` is spelled `FORCE_SSE42` because `USE_SSE` is rather useless now that we can automatically detect SSE support, and I figure changing options in the CMake build is less disruptive than changing the non-CMake build.
I've tested these changes on all the platforms I can get my hands on (macOS, Windows MSVC, Windows MinGW, and OpenBSD) and it all works splendidly. Let me know if there's anything you object to—I obviously don't mean to break any of your build pipelines in the process of fixing ours downstream.
Closes https://github.com/facebook/rocksdb/pull/2199
Differential Revision: D5054042
Pulled By: yiwu-arbug
fbshipit-source-id: 938e1fc665c049c02ae15698e1409155b8e72171
8 years ago
|
|
|
set(SYSTEM_LIBS ${CMAKE_THREAD_LIBS_INIT})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(ROCKSDB_PLUGIN_EXTERNS "")
|
|
|
|
|
set(ROCKSDB_PLUGIN_BUILTINS "")
|
|
|
|
|
message(STATUS "ROCKSDB PLUGINS TO BUILD ${ROCKSDB_PLUGINS}")
|
|
|
|
|
foreach(PLUGIN IN LISTS PLUGINS)
|
|
|
|
|
set(PLUGIN_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/plugin/${PLUGIN}/")
|
|
|
|
|
message("including rocksb plugin ${PLUGIN_ROOT}")
|
|
|
|
|
set(PLUGINMKFILE "${PLUGIN_ROOT}${PLUGIN}.mk")
|
|
|
|
|
if (NOT EXISTS ${PLUGINMKFILE})
|
|
|
|
|
message(FATAL_ERROR "Missing plugin makefile: ${PLUGINMKFILE}")
|
|
|
|
|
endif()
|
|
|
|
|
file(READ ${PLUGINMKFILE} PLUGINMK)
|
|
|
|
|
string(REGEX MATCH "SOURCES = ([^\n]*)" FOO ${PLUGINMK})
|
|
|
|
|
set(MK_SOURCES ${CMAKE_MATCH_1})
|
|
|
|
|
separate_arguments(MK_SOURCES)
|
|
|
|
|
foreach(MK_FILE IN LISTS MK_SOURCES)
|
|
|
|
|
list(APPEND SOURCES "${PLUGIN_ROOT}${MK_FILE}")
|
|
|
|
|
endforeach()
|
|
|
|
|
string(REGEX MATCH "_FUNC = ([^\n]*)" FOO ${PLUGINMK})
|
|
|
|
|
if (NOT ${CMAKE_MATCH_1} STREQUAL "")
|
|
|
|
|
string(APPEND ROCKSDB_PLUGIN_BUILTINS "{\"${PLUGIN}\", " ${CMAKE_MATCH_1} "},")
|
|
|
|
|
string(APPEND ROCKSDB_PLUGIN_EXTERNS "int " ${CMAKE_MATCH_1} "(ROCKSDB_NAMESPACE::ObjectLibrary&, const std::string&); ")
|
|
|
|
|
endif()
|
|
|
|
|
string(REGEX MATCH "_LIBS = ([^\n]*)" FOO ${PLUGINMK})
|
|
|
|
|
if (NOT ${CMAKE_MATCH_1} STREQUAL "")
|
|
|
|
|
list(APPEND THIRDPARTY_LIBS "${CMAKE_MATCH_1}")
|
|
|
|
|
endif()
|
|
|
|
|
message("THIRDPARTY_LIBS=${THIRDPARTY_LIBS}")
|
|
|
|
|
#TODO: We need to set any compile/link-time flags and add any link libraries
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
string(TIMESTAMP TS "%Y-%m-%d %H:%M:%S" UTC)
|
|
|
|
|
set(BUILD_DATE "${TS}" CACHE STRING "the time we first built rocksdb")
|
|
|
|
|
|
|
|
|
|
find_package(Git)
|
|
|
|
|
|
|
|
|
|
if(GIT_FOUND AND EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/.git")
|
|
|
|
|
execute_process(WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" OUTPUT_VARIABLE GIT_SHA COMMAND "${GIT_EXECUTABLE}" rev-parse HEAD )
|
|
|
|
|
execute_process(WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE GIT_MOD COMMAND "${GIT_EXECUTABLE}" diff-index HEAD --quiet)
|
|
|
|
|
execute_process(WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" OUTPUT_VARIABLE GIT_DATE COMMAND "${GIT_EXECUTABLE}" log -1 --date=format:"%Y-%m-%d %T" --format="%ad")
|
|
|
|
|
execute_process(WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" OUTPUT_VARIABLE GIT_TAG RESULT_VARIABLE rv COMMAND "${GIT_EXECUTABLE}" symbolic-ref -q --short HEAD OUTPUT_STRIP_TRAILING_WHITESPACE)
|
|
|
|
|
if (rv AND NOT rv EQUAL 0)
|
|
|
|
|
execute_process(WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" OUTPUT_VARIABLE GIT_TAG COMMAND "${GIT_EXECUTABLE}" describe --tags --exact-match OUTPUT_STRIP_TRAILING_WHITESPACE)
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
set(GIT_SHA 0)
|
|
|
|
|
set(GIT_MOD 1)
|
|
|
|
|
endif()
|
|
|
|
|
string(REGEX REPLACE "[^0-9a-fA-F]+" "" GIT_SHA "${GIT_SHA}")
|
|
|
|
|
string(REGEX REPLACE "[^0-9: /-]+" "" GIT_DATE "${GIT_DATE}")
|
|
|
|
|
|
|
|
|
|
set(BUILD_VERSION_CC ${CMAKE_BINARY_DIR}/build_version.cc)
|
|
|
|
|
configure_file(util/build_version.cc.in ${BUILD_VERSION_CC} @ONLY)
|
|
|
|
|
|
|
|
|
|
add_library(${ROCKSDB_STATIC_LIB} STATIC ${SOURCES} ${BUILD_VERSION_CC})
|
|
|
|
|
target_link_libraries(${ROCKSDB_STATIC_LIB} PRIVATE
|
|
|
|
|
${THIRDPARTY_LIBS} ${SYSTEM_LIBS})
|
|
|
|
|
|
|
|
|
|
if(ROCKSDB_BUILD_SHARED)
|
|
|
|
|
add_library(${ROCKSDB_SHARED_LIB} SHARED ${SOURCES} ${BUILD_VERSION_CC})
|
|
|
|
|
target_link_libraries(${ROCKSDB_SHARED_LIB} PRIVATE
|
|
|
|
|
${THIRDPARTY_LIBS} ${SYSTEM_LIBS})
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
|
|
|
|
|
COMPILE_DEFINITIONS "ROCKSDB_DLL;ROCKSDB_LIBRARY_EXPORTS")
|
|
|
|
|
if(MSVC)
|
|
|
|
|
set_target_properties(${ROCKSDB_STATIC_LIB} PROPERTIES
|
|
|
|
|
COMPILE_FLAGS "/Fd${CMAKE_CFG_INTDIR}/${ROCKSDB_STATIC_LIB}.pdb")
|
|
|
|
|
set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
|
|
|
|
|
COMPILE_FLAGS "/Fd${CMAKE_CFG_INTDIR}/${ROCKSDB_SHARED_LIB}.pdb")
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
|
|
|
|
|
LINKER_LANGUAGE CXX
|
|
|
|
|
VERSION ${rocksdb_VERSION}
|
|
|
|
|
SOVERSION ${rocksdb_VERSION_MAJOR}
|
|
|
|
|
OUTPUT_NAME "rocksdb${ARTIFACT_SUFFIX}")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(ROCKSDB_BUILD_SHARED AND NOT WIN32)
|
|
|
|
|
set(ROCKSDB_LIB ${ROCKSDB_SHARED_LIB})
|
|
|
|
|
else()
|
|
|
|
|
set(ROCKSDB_LIB ${ROCKSDB_STATIC_LIB})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_JNI "build with JNI" OFF)
|
|
|
|
|
# Tests are excluded from Release builds
|
|
|
|
|
CMAKE_DEPENDENT_OPTION(WITH_TESTS "build with tests" ON
|
|
|
|
|
"CMAKE_BUILD_TYPE STREQUAL Debug" OFF)
|
|
|
|
|
option(WITH_BENCHMARK_TOOLS "build with benchmarks" ON)
|
|
|
|
|
option(WITH_CORE_TOOLS "build with ldb and sst_dump" ON)
|
|
|
|
|
option(WITH_TOOLS "build with tools" ON)
|
|
|
|
|
|
|
|
|
|
if(WITH_TESTS OR WITH_BENCHMARK_TOOLS OR WITH_TOOLS OR WITH_JNI OR JNI)
|
|
|
|
|
include_directories(SYSTEM ${PROJECT_SOURCE_DIR}/third-party/gtest-1.8.1/fused-src)
|
|
|
|
|
endif()
|
|
|
|
|
if(WITH_JNI OR JNI)
|
|
|
|
|
message(STATUS "JNI library is enabled")
|
|
|
|
|
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/java)
|
|
|
|
|
else()
|
|
|
|
|
message(STATUS "JNI library is disabled")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Installation and packaging
|
|
|
|
|
if(WIN32)
|
|
|
|
|
option(ROCKSDB_INSTALL_ON_WINDOWS "Enable install target on Windows" OFF)
|
|
|
|
|
endif()
|
|
|
|
|
if(NOT WIN32 OR ROCKSDB_INSTALL_ON_WINDOWS)
|
|
|
|
|
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
|
|
|
|
|
if(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
|
|
|
|
|
# Change default installation prefix on Linux to /usr
|
|
|
|
|
set(CMAKE_INSTALL_PREFIX /usr CACHE PATH "Install path prefix, prepended onto install directories." FORCE)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include(GNUInstallDirs)
|
|
|
|
|
include(CMakePackageConfigHelpers)
|
|
|
|
|
|
|
|
|
|
set(package_config_destination ${CMAKE_INSTALL_LIBDIR}/cmake/rocksdb)
|
|
|
|
|
|
|
|
|
|
configure_package_config_file(
|
|
|
|
|
${CMAKE_CURRENT_LIST_DIR}/cmake/RocksDBConfig.cmake.in RocksDBConfig.cmake
|
|
|
|
|
INSTALL_DESTINATION ${package_config_destination}
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
write_basic_package_version_file(
|
|
|
|
|
RocksDBConfigVersion.cmake
|
|
|
|
|
VERSION ${rocksdb_VERSION}
|
|
|
|
|
COMPATIBILITY SameMajorVersion
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
configure_file(
|
|
|
|
|
${PROJECT_NAME}.pc.in
|
|
|
|
|
${PROJECT_NAME}.pc
|
|
|
|
|
@ONLY
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
install(DIRECTORY include/rocksdb COMPONENT devel DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")
|
|
|
|
|
|
|
|
|
|
foreach (plugin ${PLUGINS})
|
|
|
|
|
foreach (header ${${plugin}_HEADERS})
|
|
|
|
|
install(FILES plugin/${plugin}/${header} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/rocksdb/plugin/${plugin})
|
|
|
|
|
endforeach()
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
install(DIRECTORY "${PROJECT_SOURCE_DIR}/cmake/modules" COMPONENT devel DESTINATION ${package_config_destination})
|
|
|
|
|
|
|
|
|
|
install(
|
|
|
|
|
TARGETS ${ROCKSDB_STATIC_LIB}
|
|
|
|
|
EXPORT RocksDBTargets
|
|
|
|
|
COMPONENT devel
|
|
|
|
|
ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}"
|
|
|
|
|
INCLUDES DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if(ROCKSDB_BUILD_SHARED)
|
|
|
|
|
install(
|
|
|
|
|
TARGETS ${ROCKSDB_SHARED_LIB}
|
|
|
|
|
EXPORT RocksDBTargets
|
|
|
|
|
COMPONENT runtime
|
|
|
|
|
ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}"
|
|
|
|
|
RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}"
|
|
|
|
|
LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}"
|
|
|
|
|
INCLUDES DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
install(
|
|
|
|
|
EXPORT RocksDBTargets
|
|
|
|
|
COMPONENT devel
|
|
|
|
|
DESTINATION ${package_config_destination}
|
|
|
|
|
NAMESPACE RocksDB::
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
install(
|
|
|
|
|
FILES
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/RocksDBConfig.cmake
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/RocksDBConfigVersion.cmake
|
|
|
|
|
COMPONENT devel
|
|
|
|
|
DESTINATION ${package_config_destination}
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
install(
|
|
|
|
|
FILES
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc
|
|
|
|
|
COMPONENT devel
|
|
|
|
|
DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_ALL_TESTS "Build all test, rather than a small subset" ON)
|
|
|
|
|
|
|
|
|
|
if(WITH_TESTS OR WITH_BENCHMARK_TOOLS)
|
|
|
|
|
add_subdirectory(third-party/gtest-1.8.1/fused-src/gtest)
|
|
|
|
|
add_library(testharness STATIC
|
|
|
|
|
test_util/mock_time_env.cc
|
|
|
|
|
test_util/testharness.cc)
|
|
|
|
|
target_link_libraries(testharness gtest)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_TESTS)
|
|
|
|
|
set(TESTS
|
|
|
|
|
db/db_basic_test.cc
|
|
|
|
|
env/env_basic_test.cc
|
|
|
|
|
)
|
|
|
|
|
if(WITH_ALL_TESTS)
|
|
|
|
|
list(APPEND TESTS
|
|
|
|
|
cache/cache_reservation_manager_test.cc
|
|
|
|
|
cache/cache_test.cc
|
|
|
|
|
cache/compressed_secondary_cache_test.cc
|
|
|
|
|
cache/lru_cache_test.cc
|
|
|
|
|
db/blob/blob_counting_iterator_test.cc
|
|
|
|
|
db/blob/blob_file_addition_test.cc
|
|
|
|
|
db/blob/blob_file_builder_test.cc
|
|
|
|
|
db/blob/blob_file_cache_test.cc
|
|
|
|
|
db/blob/blob_file_garbage_test.cc
|
Introduce a blob file reader class (#7461)
Summary:
The patch adds a class called `BlobFileReader` that can be used to retrieve blobs
using the information available in blob references (e.g. blob file number, offset, and
size). This will come in handy when implementing blob support for `Get`, `MultiGet`,
and iterators, and also for compaction/garbage collection.
When a `BlobFileReader` object is created (using the factory method `Create`),
it first checks whether the specified file is potentially valid by comparing the file
size against the combined size of the blob file header and footer (files smaller than
the threshold are considered malformed). Then, it opens the file, and reads and verifies
the header and footer. The verification involves magic number/CRC checks
as well as checking for unexpected header/footer fields, e.g. incorrect column family ID
or TTL blob files.
Blobs can be retrieved using `GetBlob`. `GetBlob` validates the offset and compression
type passed by the caller (because of the presence of the header and footer, the
specified offset cannot be too close to the start/end of the file; also, the compression type
has to match the one in the blob file header), and retrieves and potentially verifies and
uncompresses the blob. In particular, when `ReadOptions::verify_checksums` is set,
`BlobFileReader` reads the blob record header as well (as opposed to just the blob itself)
and verifies the key/value size, the key itself, as well as the CRC of the blob record header
and the key/value pair.
In addition, the patch exposes the compression type from `BlobIndex` (both using an
accessor and via `DebugString`), and adds a blob file read latency histogram to
`InternalStats` that can be used with `BlobFileReader`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7461
Test Plan: `make check`
Reviewed By: riversand963
Differential Revision: D23999219
Pulled By: ltamasi
fbshipit-source-id: deb6b1160d251258b308d5156e2ec063c3e12e5e
4 years ago
|
|
|
db/blob/blob_file_reader_test.cc
|
|
|
|
|
db/blob/blob_garbage_meter_test.cc
|
|
|
|
|
db/blob/blob_source_test.cc
|
|
|
|
|
db/blob/db_blob_basic_test.cc
|
|
|
|
|
db/blob/db_blob_compaction_test.cc
|
|
|
|
|
db/blob/db_blob_corruption_test.cc
|
|
|
|
|
db/blob/db_blob_index_test.cc
|
|
|
|
|
db/column_family_test.cc
|
|
|
|
|
db/compact_files_test.cc
|
|
|
|
|
db/compaction/clipping_iterator_test.cc
|
|
|
|
|
db/compaction/compaction_job_stats_test.cc
|
|
|
|
|
db/compaction/compaction_job_test.cc
|
|
|
|
|
db/compaction/compaction_iterator_test.cc
|
|
|
|
|
db/compaction/compaction_picker_test.cc
|
|
|
|
|
db/compaction/compaction_service_test.cc
|
|
|
|
|
db/compaction/tiered_compaction_test.cc
|
|
|
|
|
db/comparator_db_test.cc
|
|
|
|
|
db/corruption_test.cc
|
|
|
|
|
db/cuckoo_table_db_test.cc
|
|
|
|
|
db/db_readonly_with_timestamp_test.cc
|
|
|
|
|
db/db_with_timestamp_basic_test.cc
|
|
|
|
|
db/db_block_cache_test.cc
|
|
|
|
|
db/db_bloom_filter_test.cc
|
|
|
|
|
db/db_compaction_filter_test.cc
|
|
|
|
|
db/db_compaction_test.cc
|
|
|
|
|
db/db_dynamic_level_test.cc
|
|
|
|
|
db/db_encryption_test.cc
|
|
|
|
|
db/db_flush_test.cc
|
|
|
|
|
db/db_inplace_update_test.cc
|
|
|
|
|
db/db_io_failure_test.cc
|
|
|
|
|
db/db_iter_test.cc
|
Change and clarify the relationship between Valid(), status() and Seek*() for all iterators. Also fix some bugs
Summary:
Before this PR, Iterator/InternalIterator may simultaneously have non-ok status() and Valid() = true. That state means that the last operation failed, but the iterator is nevertheless positioned on some unspecified record. Likely intended uses of that are:
* If some sst files are corrupted, a normal iterator can be used to read the data from files that are not corrupted.
* When using read_tier = kBlockCacheTier, read the data that's in block cache, skipping over the data that is not.
However, this behavior wasn't documented well (and until recently the wiki on github had misleading incorrect information). In the code there's a lot of confusion about the relationship between status() and Valid(), and about whether Seek()/SeekToLast()/etc reset the status or not. There were a number of bugs caused by this confusion, both inside rocksdb and in the code that uses rocksdb (including ours).
This PR changes the convention to:
* If status() is not ok, Valid() always returns false.
* Any seek operation resets status. (Before the PR, it depended on iterator type and on particular error.)
This does sacrifice the two use cases listed above, but siying said it's ok.
Overview of the changes:
* A commit that adds missing status checks in MergingIterator. This fixes a bug that actually affects us, and we need it fixed. `DBIteratorTest.NonBlockingIterationBugRepro` explains the scenario.
* Changes to lots of iterator types to make all of them conform to the new convention. Some bug fixes along the way. By far the biggest changes are in DBIter, which is a big messy piece of code; I tried to make it less big and messy but mostly failed.
* A stress-test for DBIter, to gain some confidence that I didn't break it. It does a few million random operations on the iterator, while occasionally modifying the underlying data (like ForwardIterator does) and occasionally returning non-ok status from internal iterator.
To find the iterator types that needed changes I searched for "public .*Iterator" in the code. Here's an overview of all 27 iterator types:
Iterators that didn't need changes:
* status() is always ok(), or Valid() is always false: MemTableIterator, ModelIter, TestIterator, KVIter (2 classes with this name anonymous namespaces), LoggingForwardVectorIterator, VectorIterator, MockTableIterator, EmptyIterator, EmptyInternalIterator.
* Thin wrappers that always pass through Valid() and status(): ArenaWrappedDBIter, TtlIterator, InternalIteratorFromIterator.
Iterators with changes (see inline comments for details):
* DBIter - an overhaul:
- It used to silently skip corrupted keys (`FindParseableKey()`), which seems dangerous. This PR makes it just stop immediately after encountering a corrupted key, just like it would for other kinds of corruption. Let me know if there was actually some deeper meaning in this behavior and I should put it back.
- It had a few code paths silently discarding subiterator's status. The stress test caught a few.
- The backwards iteration code path was expecting the internal iterator's set of keys to be immutable. It's probably always true in practice at the moment, since ForwardIterator doesn't support backwards iteration, but this PR fixes it anyway. See added DBIteratorTest.ReverseToForwardBug for an example.
- Some parts of backwards iteration code path even did things like `assert(iter_->Valid())` after a seek, which is never a safe assumption.
- It used to not reset status on seek for some types of errors.
- Some simplifications and better comments.
- Some things got more complicated from the added error handling. I'm open to ideas for how to make it nicer.
* MergingIterator - check status after every operation on every subiterator, and in some places assert that valid subiterators have ok status.
* ForwardIterator - changed to the new convention, also slightly simplified.
* ForwardLevelIterator - fixed some bugs and simplified.
* LevelIterator - simplified.
* TwoLevelIterator - changed to the new convention. Also fixed a bug that would make SeekForPrev() sometimes silently ignore errors from first_level_iter_.
* BlockBasedTableIterator - minor changes.
* BlockIter - replaced `SetStatus()` with `Invalidate()` to make sure non-ok BlockIter is always invalid.
* PlainTableIterator - some seeks used to not reset status.
* CuckooTableIterator - tiny code cleanup.
* ManagedIterator - fixed some bugs.
* BaseDeltaIterator - changed to the new convention and fixed a bug.
* BlobDBIterator - seeks used to not reset status.
* KeyConvertingIterator - some small change.
Closes https://github.com/facebook/rocksdb/pull/3810
Differential Revision: D7888019
Pulled By: al13n321
fbshipit-source-id: 4aaf6d3421c545d16722a815b2fa2e7912bc851d
7 years ago
|
|
|
db/db_iter_stress_test.cc
|
|
|
|
|
db/db_iterator_test.cc
|
Integrity protection for live updates to WriteBatch (#7748)
Summary:
This PR adds the foundation classes for key-value integrity protection and the first use case: protecting live updates from the source buffers added to `WriteBatch` through the destination buffer in `MemTable`. The width of the protection info is not yet configurable -- only eight bytes per key is supported. This PR allows users to enable protection by constructing `WriteBatch` with `protection_bytes_per_key == 8`. It does not yet expose a way for users to get integrity protection via other write APIs (e.g., `Put()`, `Merge()`, `Delete()`, etc.).
The foundation classes (`ProtectionInfo.*`) embed the coverage info in their type, and provide `Protect.*()` and `Strip.*()` functions to navigate between types with different coverage. For making bytes per key configurable (for powers of two up to eight) in the future, these classes are templated on the unsigned integer type used to store the protection info. That integer contains the XOR'd result of hashes with independent seeds for all covered fields. For integer fields, the hash is computed on the raw unadjusted bytes, so the result is endian-dependent. The most significant bytes are truncated when the hash value (8 bytes) is wider than the protection integer.
When `WriteBatch` is constructed with `protection_bytes_per_key == 8`, we hold a `ProtectionInfoKVOTC` (i.e., one that covers key, value, optype aka `ValueType`, timestamp, and CF ID) for each entry added to the batch. The protection info is generated from the original buffers passed by the user, as well as the original metadata generated internally. When writing to memtable, each entry is transformed to a `ProtectionInfoKVOTS` (i.e., dropping coverage of CF ID and adding coverage of sequence number), since at that point we know the sequence number, and have already selected a memtable corresponding to a particular CF. This protection info is verified once the entry is encoded in the `MemTable` buffer.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7748
Test Plan:
- an integration test to verify a wide variety of single-byte changes to the encoded `MemTable` buffer are caught
- add to stress/crash test to verify it works in variety of configs/operations without intentional corruption
- [deferred] unit tests for `ProtectionInfo.*` classes for edge cases like KV swap, `SliceParts` and `Slice` APIs are interchangeable, etc.
Reviewed By: pdillinger
Differential Revision: D25754492
Pulled By: ajkr
fbshipit-source-id: e481bac6c03c2ab268be41359730f1ceb9964866
4 years ago
|
|
|
db/db_kv_checksum_test.cc
|
|
|
|
|
db/db_log_iter_test.cc
|
|
|
|
|
db/db_memtable_test.cc
|
|
|
|
|
db/db_merge_operator_test.cc
|
New API to get all merge operands for a Key (#5604)
Summary:
This is a new API added to db.h to allow for fetching all merge operands associated with a Key. The main motivation for this API is to support use cases where doing a full online merge is not necessary as it is performance sensitive. Example use-cases:
1. Update subset of columns and read subset of columns -
Imagine a SQL Table, a row is encoded as a K/V pair (as it is done in MyRocks). If there are many columns and users only updated one of them, we can use merge operator to reduce write amplification. While users only read one or two columns in the read query, this feature can avoid a full merging of the whole row, and save some CPU.
2. Updating very few attributes in a value which is a JSON-like document -
Updating one attribute can be done efficiently using merge operator, while reading back one attribute can be done more efficiently if we don't need to do a full merge.
----------------------------------------------------------------------------------------------------
API :
Status GetMergeOperands(
const ReadOptions& options, ColumnFamilyHandle* column_family,
const Slice& key, PinnableSlice* merge_operands,
GetMergeOperandsOptions* get_merge_operands_options,
int* number_of_operands)
Example usage :
int size = 100;
int number_of_operands = 0;
std::vector<PinnableSlice> values(size);
GetMergeOperandsOptions merge_operands_info;
db_->GetMergeOperands(ReadOptions(), db_->DefaultColumnFamily(), "k1", values.data(), merge_operands_info, &number_of_operands);
Description :
Returns all the merge operands corresponding to the key. If the number of merge operands in DB is greater than merge_operands_options.expected_max_number_of_operands no merge operands are returned and status is Incomplete. Merge operands returned are in the order of insertion.
merge_operands-> Points to an array of at-least merge_operands_options.expected_max_number_of_operands and the caller is responsible for allocating it. If the status returned is Incomplete then number_of_operands will contain the total number of merge operands found in DB for key.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5604
Test Plan:
Added unit test and perf test in db_bench that can be run using the command:
./db_bench -benchmarks=getmergeoperands --merge_operator=sortlist
Differential Revision: D16657366
Pulled By: vjnadimpalli
fbshipit-source-id: 0faadd752351745224ee12d4ae9ef3cb529951bf
5 years ago
|
|
|
db/db_merge_operand_test.cc
|
|
|
|
|
db/db_options_test.cc
|
|
|
|
|
db/db_properties_test.cc
|
|
|
|
|
db/db_range_del_test.cc
|
|
|
|
|
db/db_rate_limiter_test.cc
|
|
|
|
|
db/db_secondary_test.cc
|
|
|
|
|
db/db_sst_test.cc
|
|
|
|
|
db/db_statistics_test.cc
|
|
|
|
|
db/db_table_properties_test.cc
|
|
|
|
|
db/db_tailing_iter_test.cc
|
|
|
|
|
db/db_test.cc
|
|
|
|
|
db/db_test2.cc
|
|
|
|
|
db/db_logical_block_size_cache_test.cc
|
|
|
|
|
db/db_universal_compaction_test.cc
|
|
|
|
|
db/db_wal_test.cc
|
|
|
|
|
db/db_with_timestamp_compaction_test.cc
|
|
|
|
|
db/db_write_buffer_manager_test.cc
|
|
|
|
|
db/db_write_test.cc
|
|
|
|
|
db/dbformat_test.cc
|
|
|
|
|
db/deletefile_test.cc
|
|
|
|
|
db/error_handler_fs_test.cc
|
|
|
|
|
db/obsolete_files_test.cc
|
|
|
|
|
db/external_sst_file_basic_test.cc
|
|
|
|
|
db/external_sst_file_test.cc
|
|
|
|
|
db/fault_injection_test.cc
|
|
|
|
|
db/file_indexer_test.cc
|
|
|
|
|
db/filename_test.cc
|
|
|
|
|
db/flush_job_test.cc
|
|
|
|
|
db/import_column_family_test.cc
|
|
|
|
|
db/listener_test.cc
|
|
|
|
|
db/log_test.cc
|
|
|
|
|
db/manual_compaction_test.cc
|
|
|
|
|
db/memtable_list_test.cc
|
|
|
|
|
db/merge_helper_test.cc
|
|
|
|
|
db/merge_test.cc
|
|
|
|
|
db/options_file_test.cc
|
|
|
|
|
db/perf_context_test.cc
|
|
|
|
|
db/periodic_task_scheduler_test.cc
|
|
|
|
|
db/plain_table_db_test.cc
|
|
|
|
|
db/seqno_time_test.cc
|
|
|
|
|
db/prefix_test.cc
|
Use only "local" range tombstones during Get (#4449)
Summary:
Previously, range tombstones were accumulated from every level, which
was necessary if a range tombstone in a higher level covered a key in a lower
level. However, RangeDelAggregator::AddTombstones's complexity is based on
the number of tombstones that are currently stored in it, which is wasteful in
the Get case, where we only need to know the highest sequence number of range
tombstones that cover the key from higher levels, and compute the highest covering
sequence number at the current level. This change introduces this optimization, and
removes the use of RangeDelAggregator from the Get path.
In the benchmark results, the following command was used to initialize the database:
```
./db_bench -db=/dev/shm/5k-rts -use_existing_db=false -benchmarks=filluniquerandom -write_buffer_size=1048576 -compression_type=lz4 -target_file_size_base=1048576 -max_bytes_for_level_base=4194304 -value_size=112 -key_size=16 -block_size=4096 -level_compaction_dynamic_level_bytes=true -num=5000000 -max_background_jobs=12 -benchmark_write_rate_limit=20971520 -range_tombstone_width=100 -writes_per_range_tombstone=100 -max_num_range_tombstones=50000 -bloom_bits=8
```
...and the following command was used to measure read throughput:
```
./db_bench -db=/dev/shm/5k-rts/ -use_existing_db=true -benchmarks=readrandom -disable_auto_compactions=true -num=5000000 -reads=100000 -threads=32
```
The filluniquerandom command was only run once, and the resulting database was used
to measure read performance before and after the PR. Both binaries were compiled with
`DEBUG_LEVEL=0`.
Readrandom results before PR:
```
readrandom : 4.544 micros/op 220090 ops/sec; 16.9 MB/s (63103 of 100000 found)
```
Readrandom results after PR:
```
readrandom : 11.147 micros/op 89707 ops/sec; 6.9 MB/s (63103 of 100000 found)
```
So it's actually slower right now, but this PR paves the way for future optimizations (see #4493).
----
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4449
Differential Revision: D10370575
Pulled By: abhimadan
fbshipit-source-id: 9a2e152be1ef36969055c0e9eb4beb0d96c11f4d
6 years ago
|
|
|
db/range_del_aggregator_test.cc
|
|
|
|
|
db/range_tombstone_fragmenter_test.cc
|
|
|
|
|
db/repair_test.cc
|
|
|
|
|
db/table_properties_collector_test.cc
|
|
|
|
|
db/version_builder_test.cc
|
|
|
|
|
db/version_edit_test.cc
|
|
|
|
|
db/version_set_test.cc
|
|
|
|
|
db/wal_manager_test.cc
|
Define WAL related classes to be used in VersionEdit and VersionSet (#7164)
Summary:
`WalAddition`, `WalDeletion` are defined in `wal_version.h` and used in `VersionEdit`.
`WalAddition` is used to represent events of creating a new WAL (no size, just log number), or closing a WAL (with size).
`WalDeletion` is used to represent events of deleting or archiving a WAL, it means the WAL is no longer alive (won't be replayed during recovery).
`WalSet` is the set of alive WALs kept in `VersionSet`.
1. Why use `WalDeletion` instead of relying on `MinLogNumber` to identify outdated WALs
On recovery, we can compute `MinLogNumber()` based on the log numbers kept in MANIFEST, any log with number < MinLogNumber can be ignored. So it seems that we don't need to persist `WalDeletion` to MANIFEST, since we can ignore the WALs based on MinLogNumber.
But the `MinLogNumber()` is actually a lower bound, it does not exactly mean that logs starting from MinLogNumber must exist. This is because in a corner case, when a column family is empty and never flushed, its log number is set to the largest log number, but not persisted in MANIFEST. So let's say there are 2 column families, when creating the DB, the first WAL has log number 1, so it's persisted to MANIFEST for both column families. Then CF 0 is empty and never flushed, CF 1 is updated and flushed, so a new WAL with log number 2 is created and persisted to MANIFEST for CF 1. But CF 0's log number in MANIFEST is still 1. So on recovery, MinLogNumber is 1, but since log 1 only contains data for CF 1, and CF 1 is flushed, log 1 might have already been deleted from disk.
We can make `MinLogNumber()` be the exactly minimum log number that must exist, by persisting the most recent log number for empty column families that are not flushed. But if there are N such column families, then every time a new WAL is created, we need to add N records to MANIFEST.
In current design, a record is persisted to MANIFEST only when WAL is created, closed, or deleted/archived, so the number of WAL related records are bounded to 3x number of WALs.
2. Why keep `WalSet` in `VersionSet` instead of applying the `VersionEdit`s to `VersionStorageInfo`
`VersionEdit`s are originally designed to track the addition and deletion of SST files. The SST files are related to column families, each column family has a list of `Version`s, and each `Version` keeps the set of active SST files in `VersionStorageInfo`.
But WALs are a concept of DB, they are not bounded to specific column families. So logically it does not make sense to store WALs in a column family's `Version`s.
Also, `Version`'s purpose is to keep reference to SST / blob files, so that they are not deleted until there is no version referencing them. But a WAL is deleted regardless of version references.
So we keep the WALs in `VersionSet` for the purpose of writing out the DB state's snapshot when creating new MANIFESTs.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7164
Test Plan:
make version_edit_test && ./version_edit_test
make wal_edit_test && ./wal_edit_test
Reviewed By: ltamasi
Differential Revision: D22677936
Pulled By: cheng-chang
fbshipit-source-id: 5a3b6890140e572ffd79eb37e6e4c3c32361a859
4 years ago
|
|
|
db/wal_edit_test.cc
|
|
|
|
|
db/wide/db_wide_basic_test.cc
|
|
|
|
|
db/wide/wide_column_serialization_test.cc
|
|
|
|
|
db/write_batch_test.cc
|
|
|
|
|
db/write_callback_test.cc
|
|
|
|
|
db/write_controller_test.cc
|
|
|
|
|
env/env_test.cc
|
|
|
|
|
env/io_posix_test.cc
|
|
|
|
|
env/mock_env_test.cc
|
|
|
|
|
file/delete_scheduler_test.cc
|
|
|
|
|
file/prefetch_test.cc
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
5 years ago
|
|
|
file/random_access_file_reader_test.cc
|
|
|
|
|
logging/auto_roll_logger_test.cc
|
|
|
|
|
logging/env_logger_test.cc
|
|
|
|
|
logging/event_logger_test.cc
|
|
|
|
|
memory/arena_test.cc
|
|
|
|
|
memory/memory_allocator_test.cc
|
|
|
|
|
memtable/inlineskiplist_test.cc
|
|
|
|
|
memtable/skiplist_test.cc
|
|
|
|
|
memtable/write_buffer_manager_test.cc
|
|
|
|
|
monitoring/histogram_test.cc
|
|
|
|
|
monitoring/iostats_context_test.cc
|
|
|
|
|
monitoring/statistics_test.cc
|
|
|
|
|
monitoring/stats_history_test.cc
|
|
|
|
|
options/configurable_test.cc
|
|
|
|
|
options/customizable_test.cc
|
|
|
|
|
options/options_settable_test.cc
|
|
|
|
|
options/options_test.cc
|
|
|
|
|
table/block_based/block_based_table_reader_test.cc
|
|
|
|
|
table/block_based/block_test.cc
|
|
|
|
|
table/block_based/data_block_hash_index_test.cc
|
|
|
|
|
table/block_based/full_filter_block_test.cc
|
|
|
|
|
table/block_based/partitioned_filter_block_test.cc
|
|
|
|
|
table/cleanable_test.cc
|
|
|
|
|
table/cuckoo/cuckoo_table_builder_test.cc
|
|
|
|
|
table/cuckoo/cuckoo_table_reader_test.cc
|
|
|
|
|
table/merger_test.cc
|
|
|
|
|
table/sst_file_reader_test.cc
|
|
|
|
|
table/table_test.cc
|
|
|
|
|
table/block_fetcher_test.cc
|
|
|
|
|
test_util/testutil_test.cc
|
|
|
|
|
trace_replay/block_cache_tracer_test.cc
|
|
|
|
|
trace_replay/io_tracer_test.cc
|
Block cache simulator: Add pysim to simulate caches using reinforcement learning. (#5610)
Summary:
This PR implements cache eviction using reinforcement learning. It includes two implementations:
1. An implementation of Thompson Sampling for the Bernoulli Bandit [1].
2. An implementation of LinUCB with disjoint linear models [2].
The idea is that a cache uses multiple eviction policies, e.g., MRU, LRU, and LFU. The cache learns which eviction policy is the best and uses it upon a cache miss.
Thompson Sampling is contextless and does not include any features.
LinUCB includes features such as level, block type, caller, column family id to decide which eviction policy to use.
[1] Daniel J. Russo, Benjamin Van Roy, Abbas Kazerouni, Ian Osband, and Zheng Wen. 2018. A Tutorial on Thompson Sampling. Found. Trends Mach. Learn. 11, 1 (July 2018), 1-96. DOI: https://doi.org/10.1561/2200000070
[2] Lihong Li, Wei Chu, John Langford, and Robert E. Schapire. 2010. A contextual-bandit approach to personalized news article recommendation. In Proceedings of the 19th international conference on World wide web (WWW '10). ACM, New York, NY, USA, 661-670. DOI=http://dx.doi.org/10.1145/1772690.1772758
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5610
Differential Revision: D16435067
Pulled By: HaoyuHuang
fbshipit-source-id: 6549239ae14115c01cb1e70548af9e46d8dc21bb
5 years ago
|
|
|
tools/block_cache_analyzer/block_cache_trace_analyzer_test.cc
|
|
|
|
|
tools/io_tracer_parser_test.cc
|
|
|
|
|
tools/ldb_cmd_test.cc
|
|
|
|
|
tools/reduce_levels_test.cc
|
|
|
|
|
tools/sst_dump_test.cc
|
RocksDB Trace Analyzer (#4091)
Summary:
A framework of trace analyzing for RocksDB
After collecting the trace by using the tool of [PR #3837](https://github.com/facebook/rocksdb/pull/3837). User can use the Trace Analyzer to interpret, analyze, and characterize the collected workload.
**Input:**
1. trace file
2. Whole keys space file
**Statistics:**
1. Access count of each operation (Get, Put, Delete, SingleDelete, DeleteRange, Merge) in each column family.
2. Key hotness (access count) of each one
3. Key space separation based on given prefix
4. Key size distribution
5. Value size distribution if appliable
6. Top K accessed keys
7. QPS statistics including the average QPS and peak QPS
8. Top K accessed prefix
9. The query correlation analyzing, output the number of X after Y and the corresponding average time
intervals
**Output:**
1. key access heat map (either in the accessed key space or whole key space)
2. trace sequence file (interpret the raw trace file to line base text file for future use)
3. Time serial (The key space ID and its access time)
4. Key access count distritbution
5. Key size distribution
6. Value size distribution (in each intervals)
7. whole key space separation by the prefix
8. Accessed key space separation by the prefix
9. QPS of each operation and each column family
10. Top K QPS and their accessed prefix range
**Test:**
1. Added the unit test of analyzing Get, Put, Delete, SingleDelete, DeleteRange, Merge
2. Generated the trace and analyze the trace
**Implemented but not tested (due to the limitation of trace_replay):**
1. Analyzing Iterator, supporting Seek() and SeekForPrev() analyzing
2. Analyzing the number of Key found by Get
**Future Work:**
1. Support execution time analyzing of each requests
2. Support cache hit situation and block read situation of Get
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4091
Differential Revision: D9256157
Pulled By: zhichao-cao
fbshipit-source-id: f0ceacb7eedbc43a3eee6e85b76087d7832a8fe6
6 years ago
|
|
|
tools/trace_analyzer_test.cc
|
|
|
|
|
util/autovector_test.cc
|
|
|
|
|
util/bloom_test.cc
|
|
|
|
|
util/coding_test.cc
|
|
|
|
|
util/crc32c_test.cc
|
|
|
|
|
util/defer_test.cc
|
|
|
|
|
util/dynamic_bloom_test.cc
|
RangeSync not to sync last 1MB of the file
Summary:
From other ones' investigation:
"sync_file_range() behavior highly depends on kernel version and filesystem.
xfs does neighbor page flushing outside of the specified ranges. For example, sync_file_range(fd, 8192, 16384) does not only trigger flushing page #3 to #4, but also flushing many more dirty pages (i.e. up to page#16)... Ranges of the sync_file_range() should be far enough from write() offset (at least 1MB)."
Test Plan: make all check
Reviewers: igor, rven, kradhakrishnan, yhchiang, IslamAbdelRahman, anthony
Reviewed By: anthony
Subscribers: yoshinorim, MarkCallaghan, sumeet, domas, dhruba, leveldb, ljin
Differential Revision: https://reviews.facebook.net/D15807
9 years ago
|
|
|
util/file_reader_writer_test.cc
|
|
|
|
|
util/filelock_test.cc
|
|
|
|
|
util/hash_test.cc
|
|
|
|
|
util/heap_test.cc
|
|
|
|
|
util/random_test.cc
|
|
|
|
|
util/rate_limiter_test.cc
|
|
|
|
|
util/repeatable_thread_test.cc
|
|
|
|
|
util/ribbon_test.cc
|
|
|
|
|
util/slice_test.cc
|
|
|
|
|
util/slice_transform_test.cc
|
|
|
|
|
util/timer_queue_test.cc
|
|
|
|
|
util/timer_test.cc
|
|
|
|
|
util/thread_list_test.cc
|
|
|
|
|
util/thread_local_test.cc
|
|
|
|
|
util/work_queue_test.cc
|
|
|
|
|
utilities/agg_merge/agg_merge_test.cc
|
|
|
|
|
utilities/backup/backup_engine_test.cc
|
|
|
|
|
utilities/blob_db/blob_db_test.cc
|
|
|
|
|
utilities/cassandra/cassandra_functional_test.cc
|
|
|
|
|
utilities/cassandra/cassandra_format_test.cc
|
|
|
|
|
utilities/cassandra/cassandra_row_merge_test.cc
|
|
|
|
|
utilities/cassandra/cassandra_serialize_test.cc
|
|
|
|
|
utilities/checkpoint/checkpoint_test.cc
|
|
|
|
|
utilities/env_timed_test.cc
|
|
|
|
|
utilities/memory/memory_test.cc
|
|
|
|
|
utilities/merge_operators/string_append/stringappend_test.cc
|
|
|
|
|
utilities/object_registry_test.cc
|
|
|
|
|
utilities/option_change_migration/option_change_migration_test.cc
|
|
|
|
|
utilities/options/options_util_test.cc
|
|
|
|
|
utilities/persistent_cache/hash_table_test.cc
|
|
|
|
|
utilities/persistent_cache/persistent_cache_test.cc
|
|
|
|
|
utilities/simulator_cache/cache_simulator_test.cc
|
|
|
|
|
utilities/simulator_cache/sim_cache_test.cc
|
|
|
|
|
utilities/table_properties_collectors/compact_on_deletion_collector_test.cc
|
|
|
|
|
utilities/transactions/optimistic_transaction_test.cc
|
Pessimistic Transactions
Summary:
Initial implementation of Pessimistic Transactions. This diff contains the api changes discussed in D38913. This diff is pretty large, so let me know if people would prefer to meet up to discuss it.
MyRocks folks: please take a look at the API in include/rocksdb/utilities/transaction[_db].h and let me know if you have any issues.
Also, you'll notice a couple of TODOs in the implementation of RollbackToSavePoint(). After chatting with Siying, I'm going to send out a separate diff for an alternate implementation of this feature that implements the rollback inside of WriteBatch/WriteBatchWithIndex. We can then decide which route is preferable.
Next, I'm planning on doing some perf testing and then integrating this diff into MongoRocks for further testing.
Test Plan: Unit tests, db_bench parallel testing.
Reviewers: igor, rven, sdong, yhchiang, yoshinorim
Reviewed By: sdong
Subscribers: hermanlee4, maykov, spetrunia, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D40869
10 years ago
|
|
|
utilities/transactions/transaction_test.cc
|
|
|
|
|
utilities/transactions/lock/point/point_lock_manager_test.cc
|
Support user-defined timestamps in write-committed txns (#9629)
Summary:
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9629
Pessimistic transactions use pessimistic concurrency control, i.e. locking. Keys are
locked upon first operation that writes the key or has the intention of writing. For example,
`PessimisticTransaction::Put()`, `PessimisticTransaction::Delete()`,
`PessimisticTransaction::SingleDelete()` will write to or delete a key, while
`PessimisticTransaction::GetForUpdate()` is used by application to indicate
to RocksDB that the transaction has the intention of performing write operation later
in the same transaction.
Pessimistic transactions support two-phase commit (2PC). A transaction can be
`Prepared()`'ed and then `Commit()`. The prepare phase is similar to a promise: once
`Prepare()` succeeds, the transaction has acquired the necessary resources to commit.
The resources include locks, persistence of WAL, etc.
Write-committed transaction is the default pessimistic transaction implementation. In
RocksDB write-committed transaction, `Prepare()` will write data to the WAL as a prepare
section. `Commit()` will write a commit marker to the WAL and then write data to the
memtables. While writing to the memtables, different keys in the transaction's write batch
will be assigned different sequence numbers in ascending order.
Until commit/rollback, the transaction holds locks on the keys so that no other transaction
can write to the same keys. Furthermore, the keys' sequence numbers represent the order
in which they are committed and should be made visible. This is convenient for us to
implement support for user-defined timestamps.
Since column families with and without timestamps can co-exist in the same database,
a transaction may or may not involve timestamps. Based on this observation, we add two
optional members to each `PessimisticTransaction`, `read_timestamp_` and
`commit_timestamp_`. If no key in the transaction's write batch has timestamp, then
setting these two variables do not have any effect. For the rest of this commit, we discuss
only the cases when these two variables are meaningful.
read_timestamp_ is used mainly for validation, and should be set before first call to
`GetForUpdate()`. Otherwise, the latter will return non-ok status. `GetForUpdate()` calls
`TryLock()` that can verify if another transaction has written the same key since
`read_timestamp_` till this call to `GetForUpdate()`. If another transaction has indeed
written the same key, then validation fails, and RocksDB allows this transaction to
refine `read_timestamp_` by increasing it. Note that a transaction can still use `Get()`
with a different timestamp to read, but the result of the read should not be used to
determine data that will be written later.
commit_timestamp_ must be set after finishing writing and before transaction commit.
This applies to both 2PC and non-2PC cases. In the case of 2PC, it's usually set after
prepare phase succeeds.
We currently require that the commit timestamp be chosen after all keys are locked. This
means we disallow the `TransactionDB`-level APIs if user-defined timestamp is used
by the transaction. Specifically, calling `PessimisticTransactionDB::Put()`,
`PessimisticTransactionDB::Delete()`, `PessimisticTransactionDB::SingleDelete()`,
etc. will return non-ok status because they specify timestamps before locking the keys.
Users are also prompted to use the `Transaction` APIs when they receive the non-ok status.
Reviewed By: ltamasi
Differential Revision: D31822445
fbshipit-source-id: b82abf8e230216dc89cc519564a588224a88fd43
3 years ago
|
|
|
utilities/transactions/write_committed_transaction_ts_test.cc
|
|
|
|
|
utilities/transactions/write_prepared_transaction_test.cc
|
|
|
|
|
utilities/transactions/write_unprepared_transaction_test.cc
|
|
|
|
|
utilities/transactions/lock/range/range_locking_test.cc
|
Snapshots with user-specified timestamps (#9879)
Summary:
In RocksDB, keys are associated with (internal) sequence numbers which denote when the keys are written
to the database. Sequence numbers in different RocksDB instances are unrelated, thus not comparable.
It is nice if we can associate sequence numbers with their corresponding actual timestamps. One thing we can
do is to support user-defined timestamp, which allows the applications to specify the format of custom timestamps
and encode a timestamp with each key. More details can be found at https://github.com/facebook/rocksdb/wiki/User-defined-Timestamp-%28Experimental%29.
This PR provides a different but complementary approach. We can associate rocksdb snapshots (defined in
https://github.com/facebook/rocksdb/blob/7.2.fb/include/rocksdb/snapshot.h#L20) with **user-specified** timestamps.
Since a snapshot is essentially an object representing a sequence number, this PR establishes a bi-directional mapping between sequence numbers and timestamps.
In the past, snapshots are usually taken by readers. The current super-version is grabbed, and a `rocksdb::Snapshot`
object is created with the last published sequence number of the super-version. You can see that the reader actually
has no good idea of what timestamp to assign to this snapshot, because by the time the `GetSnapshot()` is called,
an arbitrarily long period of time may have already elapsed since the last write, which is when the last published
sequence number is written.
This observation motivates the creation of "timestamped" snapshots on the write path. Currently, this functionality is
exposed only to the layer of `TransactionDB`. Application can tell RocksDB to create a snapshot when a transaction
commits, effectively associating the last sequence number with a timestamp. It is also assumed that application will
ensure any two snapshots with timestamps should satisfy the following:
```
snapshot1.seq < snapshot2.seq iff. snapshot1.ts < snapshot2.ts
```
If the application can guarantee that when a reader takes a timestamped snapshot, there is no active writes going on
in the database, then we also allow the user to use a new API `TransactionDB::CreateTimestampedSnapshot()` to create
a snapshot with associated timestamp.
Code example
```cpp
// Create a timestamped snapshot when committing transaction.
txn->SetCommitTimestamp(100);
txn->SetSnapshotOnNextOperation();
txn->Commit();
// A wrapper API for convenience
Status Transaction::CommitAndTryCreateSnapshot(
std::shared_ptr<TransactionNotifier> notifier,
TxnTimestamp ts,
std::shared_ptr<const Snapshot>* ret);
// Create a timestamped snapshot if caller guarantees no concurrent writes
std::pair<Status, std::shared_ptr<const Snapshot>> snapshot = txn_db->CreateTimestampedSnapshot(100);
```
The snapshots created in this way will be managed by RocksDB with ref-counting and potentially shared with
other readers. We provide the following APIs for readers to retrieve a snapshot given a timestamp.
```cpp
// Return the timestamped snapshot correponding to given timestamp. If ts is
// kMaxTxnTimestamp, then we return the latest timestamped snapshot if present.
// Othersise, we return the snapshot whose timestamp is equal to `ts`. If no
// such snapshot exists, then we return null.
std::shared_ptr<const Snapshot> TransactionDB::GetTimestampedSnapshot(TxnTimestamp ts) const;
// Return the latest timestamped snapshot if present.
std::shared_ptr<const Snapshot> TransactionDB::GetLatestTimestampedSnapshot() const;
```
We also provide two additional APIs for stats collection and reporting purposes.
```cpp
Status TransactionDB::GetAllTimestampedSnapshots(
std::vector<std::shared_ptr<const Snapshot>>& snapshots) const;
// Return timestamped snapshots whose timestamps fall in [ts_lb, ts_ub) and store them in `snapshots`.
Status TransactionDB::GetTimestampedSnapshots(
TxnTimestamp ts_lb,
TxnTimestamp ts_ub,
std::vector<std::shared_ptr<const Snapshot>>& snapshots) const;
```
To prevent the number of timestamped snapshots from growing infinitely, we provide the following API to release
timestamped snapshots whose timestamps are older than or equal to a given threshold.
```cpp
void TransactionDB::ReleaseTimestampedSnapshotsOlderThan(TxnTimestamp ts);
```
Before shutdown, RocksDB will release all timestamped snapshots.
Comparison with user-defined timestamp and how they can be combined:
User-defined timestamp persists every key with a timestamp, while timestamped snapshots maintain a volatile
mapping between snapshots (sequence numbers) and timestamps.
Different internal keys with the same user key but different timestamps will be treated as different by compaction,
thus a newer version will not hide older versions (with smaller timestamps) unless they are eligible for garbage collection.
In contrast, taking a timestamped snapshot at a certain sequence number and timestamp prevents all the keys visible in
this snapshot from been dropped by compaction. Here, visible means (seq < snapshot and most recent).
The timestamped snapshot supports the semantics of reading at an exact point in time.
Timestamped snapshots can also be used with user-defined timestamp.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9879
Test Plan:
```
make check
TEST_TMPDIR=/dev/shm make crash_test_with_txn
```
Reviewed By: siying
Differential Revision: D35783919
Pulled By: riversand963
fbshipit-source-id: 586ad905e169189e19d3bfc0cb0177a7239d1bd4
2 years ago
|
|
|
utilities/transactions/timestamped_snapshot_test.cc
|
|
|
|
|
utilities/ttl/ttl_test.cc
|
|
|
|
|
utilities/util_merge_operators_test.cc
|
|
|
|
|
utilities/write_batch_with_index/write_batch_with_index_test.cc
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(TESTUTIL_SOURCE
|
|
|
|
|
db/db_test_util.cc
|
|
|
|
|
db/db_with_timestamp_test_util.cc
|
|
|
|
|
monitoring/thread_status_updater_debug.cc
|
|
|
|
|
table/mock_table.cc
|
|
|
|
|
utilities/agg_merge/test_agg_merge.cc
|
|
|
|
|
utilities/cassandra/test_utils.cc
|
|
|
|
|
)
|
|
|
|
|
enable_testing()
|
|
|
|
|
add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND})
|
|
|
|
|
set(TESTUTILLIB testutillib${ARTIFACT_SUFFIX})
|
|
|
|
|
add_library(${TESTUTILLIB} STATIC ${TESTUTIL_SOURCE})
|
|
|
|
|
target_link_libraries(${TESTUTILLIB} ${ROCKSDB_LIB})
|
|
|
|
|
if(MSVC)
|
|
|
|
|
set_target_properties(${TESTUTILLIB} PROPERTIES COMPILE_FLAGS "/Fd${CMAKE_CFG_INTDIR}/testutillib${ARTIFACT_SUFFIX}.pdb")
|
|
|
|
|
endif()
|
|
|
|
|
set_target_properties(${TESTUTILLIB}
|
|
|
|
|
PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD_RELEASE 1
|
|
|
|
|
EXCLUDE_FROM_DEFAULT_BUILD_MINRELEASE 1
|
|
|
|
|
EXCLUDE_FROM_DEFAULT_BUILD_RELWITHDEBINFO 1
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
foreach(sourcefile ${TESTS})
|
|
|
|
|
get_filename_component(exename ${sourcefile} NAME_WE)
|
|
|
|
|
add_executable(${exename}${ARTIFACT_SUFFIX} ${sourcefile})
|
|
|
|
|
set_target_properties(${exename}${ARTIFACT_SUFFIX}
|
|
|
|
|
PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD_RELEASE 1
|
|
|
|
|
EXCLUDE_FROM_DEFAULT_BUILD_MINRELEASE 1
|
|
|
|
|
EXCLUDE_FROM_DEFAULT_BUILD_RELWITHDEBINFO 1
|
|
|
|
|
OUTPUT_NAME ${exename}${ARTIFACT_SUFFIX}
|
|
|
|
|
)
|
|
|
|
|
target_link_libraries(${exename}${ARTIFACT_SUFFIX} testutillib${ARTIFACT_SUFFIX} testharness gtest ${THIRDPARTY_LIBS} ${ROCKSDB_LIB})
|
|
|
|
|
if(NOT "${exename}" MATCHES "db_sanity_test")
|
|
|
|
|
gtest_discover_tests(${exename} DISCOVERY_TIMEOUT 120)
|
|
|
|
|
add_dependencies(check ${exename}${ARTIFACT_SUFFIX})
|
|
|
|
|
endif()
|
|
|
|
|
endforeach(sourcefile ${TESTS})
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
# C executables must link to a shared object
|
|
|
|
|
if(ROCKSDB_BUILD_SHARED)
|
|
|
|
|
set(ROCKSDB_LIB_FOR_C ${ROCKSDB_SHARED_LIB})
|
|
|
|
|
else()
|
|
|
|
|
set(ROCKSDB_LIB_FOR_C OFF)
|
|
|
|
|
endif()
|
|
|
|
|
else()
|
|
|
|
|
set(ROCKSDB_LIB_FOR_C ${ROCKSDB_LIB})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(ROCKSDB_LIB_FOR_C)
|
|
|
|
|
set(C_TESTS db/c_test.c)
|
|
|
|
|
add_executable(c_test db/c_test.c)
|
|
|
|
|
target_link_libraries(c_test ${ROCKSDB_LIB_FOR_C} testharness)
|
|
|
|
|
add_test(NAME c_test COMMAND c_test${ARTIFACT_SUFFIX})
|
|
|
|
|
add_dependencies(check c_test)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_BENCHMARK_TOOLS)
|
|
|
|
|
add_executable(db_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
tools/simulated_hybrid_file_system.cc
|
|
|
|
|
tools/db_bench.cc
|
|
|
|
|
tools/db_bench_tool.cc)
|
|
|
|
|
target_link_libraries(db_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${THIRDPARTY_LIBS})
|
|
|
|
|
|
|
|
|
|
add_executable(cache_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
cache/cache_bench.cc
|
|
|
|
|
cache/cache_bench_tool.cc)
|
|
|
|
|
target_link_libraries(cache_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(memtablerep_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
memtable/memtablerep_bench.cc)
|
|
|
|
|
target_link_libraries(memtablerep_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(range_del_aggregator_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
db/range_del_aggregator_bench.cc)
|
|
|
|
|
target_link_libraries(range_del_aggregator_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(table_reader_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
table/table_reader_bench.cc)
|
|
|
|
|
target_link_libraries(table_reader_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} testharness ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(filter_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
util/filter_bench.cc)
|
|
|
|
|
target_link_libraries(filter_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(hash_table_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
utilities/persistent_cache/hash_table_bench.cc)
|
|
|
|
|
target_link_libraries(hash_table_bench${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_TRACE_TOOLS "build with trace tools" ON)
|
Add support for wide-column point lookups (#10540)
Summary:
The patch adds a new API `GetEntity` that can be used to perform
wide-column point lookups. It also extends the `Get` code path and
the `MemTable` / `MemTableList` and `Version` / `GetContext` logic
accordingly so that wide-column entities can be served from both
memtables and SSTs. If the result of a lookup is a wide-column entity
(`kTypeWideColumnEntity`), it is passed to the application in deserialized
form; if it is a plain old key-value (`kTypeValue`), it is presented as a
wide-column entity with a single default (anonymous) column.
(In contrast, regular `Get` returns plain old key-values as-is, and
returns the value of the default column for wide-column entities, see
https://github.com/facebook/rocksdb/issues/10483 .)
The result of `GetEntity` is a self-contained `PinnableWideColumns` object.
`PinnableWideColumns` contains a `PinnableSlice`, which either stores the
underlying data in its own buffer or holds on to a cache handle. It also contains
a `WideColumns` instance, which indexes the contents of the `PinnableSlice`,
so applications can access the values of columns efficiently.
There are several pieces of functionality which are currently not supported
for wide-column entities: there is currently no `MultiGetEntity` or wide-column
iterator; also, `Merge` and `GetMergeOperands` are not supported, and there
is no `GetEntity` implementation for read-only and secondary instances.
We plan to implement these in future PRs.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10540
Test Plan: `make check`
Reviewed By: akankshamahajan15
Differential Revision: D38847474
Pulled By: ltamasi
fbshipit-source-id: 42311a34ccdfe88b3775e847a5e2a5296e002b5b
2 years ago
|
|
|
if(WITH_TRACE_TOOLS)
|
|
|
|
|
add_executable(block_cache_trace_analyzer_tool${ARTIFACT_SUFFIX}
|
|
|
|
|
tools/block_cache_analyzer/block_cache_trace_analyzer_tool.cc)
|
|
|
|
|
target_link_libraries(block_cache_trace_analyzer_tool${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
add_executable(trace_analyzer${ARTIFACT_SUFFIX}
|
|
|
|
|
tools/trace_analyzer.cc)
|
|
|
|
|
target_link_libraries(trace_analyzer${ARTIFACT_SUFFIX}
|
|
|
|
|
${ROCKSDB_LIB} ${GFLAGS_LIB})
|
|
|
|
|
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_CORE_TOOLS OR WITH_TOOLS)
|
|
|
|
|
add_subdirectory(tools)
|
|
|
|
|
add_custom_target(core_tools
|
|
|
|
|
DEPENDS ${core_tool_deps})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(WITH_TOOLS)
|
|
|
|
|
add_subdirectory(db_stress_tool)
|
|
|
|
|
add_custom_target(tools
|
|
|
|
|
DEPENDS ${tool_deps})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_EXAMPLES "build with examples" OFF)
|
|
|
|
|
if(WITH_EXAMPLES)
|
|
|
|
|
add_subdirectory(examples)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
option(WITH_BENCHMARK "build benchmark tests" OFF)
|
|
|
|
|
if(WITH_BENCHMARK)
|
|
|
|
|
add_subdirectory(${PROJECT_SOURCE_DIR}/microbench/)
|
|
|
|
|
endif()
|
