* Add dir, hostname, and bind address to top level config since it applies to services other than meta
* Add enabled flags to example toml for data and meta services
* Wire up add/remove raft peers and meta servers to meta service
* Update DROP SERVER to be either DROP META SERVER or DROP DATA SERVER
* Bring over statement executor from old meta package
* Start meta service client implementation
* Update meta service test to use the client
* Wire up node ID/meta server storage information
currently we use /etc/lsb-release to detect debian,
but this file is only present on ubuntu.
/etc/debian_version is installed by default by debian and ubuntu
This commit enforces a limit on `RawMapper` so that it will not
produce more values than are specified by the LIMIT clause.
Previously the mapper would read up to the chunk size and the
values would be limited afterward.
We were closing the cursor when we read the last block which caused
the internal state to be cleared. In a group by query, we seeked multiple
times so depending on the group by interval and how the data was laid out
in the blocks, we woudl close the cursor and the last block would get skipped.
Fixes#5193
Add --pkgarch option to build.py to specify the packaging architecture which can be different to GOARCH.
Example: build for debian on raspberry pi. GOARCH will be arm but the packaging architecture on debian will be armhf (arm hard float). The --pkgarch option is passed to fpm to specify the required architecture which is reflected in the package manifest and also in the result filename.
This may be causing slow restart times for systems with many large TSM files.
What I believe is happening at startup in these cases is that multiple goroutines
are started to load each TSM file concurrently. The kernel appears to serialize
mmap calls from the same process so all of the goroutines end up getting blocked
on the actual mmap system call. MAP_POPULATE instruct the kernel to pre-fault the
page table for the files and triggers read-ahead of the pages. For larger, 2GB files,
this makes the mmap call more expensive and slower. When there are many of these files
and calls it is possible to fill all available memory with pagecache. In this case,
the OS will end up pre-faulting pages from one file and have to remove pages that it just
loaded from another files causing slowness. MAP_POPULATE may also be cause much more data
to be pre-faulted than necessary. To load a file, we just need to scan the index at the end
of the file. MAP_POPULATE is likely causing the whole file to be loaded when it won't actually
be accessed for a while (or at all).
Might fix issue #5311.
David Norton
Paul Dix
Cory LaNou
Jason Wilder
Jason Wilder
joelegasse
Jonathan A. Sternberg
Edd Robinson
Ross McDonald
Jonathan A. Sternberg
Ross McDonald
Prayag Verma
Alexandre Derumier
Ben Johnson
Marcus Geiger