addToCache is called in a goroutine and can panic if the server is closed while opening. If
part of the open func errors, it returns an error and immediately calls close. close sets
p.cache to nil which causes the goroutine trying to initialized the cache to panic as well. The
goroutine should run under a write lock to avoid this race/panic.
If LoadMetadataIndex() tries to log an error, it causes a panic because the
logger is not set until Open() is called, which is after LoadMetaDataIndex() returns.
Instead, just set the logger up when the WAL is created.
From
516f0d1c90
"Note that we use a channel send here and not a close.
The race detector doesn't know that we're waiting for a timeout
and thinks that the waitgroup inside httptest.Server is added to
concurrently with us closing it. If we timed out immediately, we could close
the testserver before we entered the handler. We're not timing out immediately
and there's no way we would be done before we entered the handler, but the
race detector doesn't know this, so synchronize explicitly.
Writes could timeout and when adding new measurement names to the
index if the sort took a long time. The names slice was never
actually used (except a test) so keeping it in index wastes memory
and sort it wastes CPU and increases lock contention. The sorting
was happening while the shard held a write-lock.
Fixes#3869
If we've seeked a cursor, then we can be sure that there will be no
data between it and the point that was seeked to. Take advantage of
this fact to only seek when it would yield us a value that would be
different from the last.
In addition, only init the pointsheap when doing a raw query. For
aggregate queries, it is reinitialized on every time bucket, so no
need to seek through all the cursors
For a synthetic database where there was only entries for a tiny
slice of time, it cut queries from 112 seconds to 30 seconds doing
`select mean(value) from cpu where time > now - 2h group by time(1h)`
Unless a valid shell for the user running influxdb, the command su fails with
the error:
This account is currently not available.
The user shouldn't have a valid shell although the package creates influxdb
user with /bin/bash
The interaction of continuous query service, the meta-store loading
and initializing raft state, and syncing node info could cause a
deadlock in some instances. There was an extra read-lock taken by isLeader()
when it already had a read-lock. Removing this extra lock fixes the startup
deadlock.
Fixes#3607
This commit changes the default block size from 64KB to 4KB for
bz1. This was lowered because small blocks were being uncompressed,
merged, recompressed, and inserted for a large portion of updates.
This became slower and slower over time until it reached the 64KB
threshold. We moved to the 4KB threshold in order to lower the
impact of this recompression.
If 2 or more points during this map-and-reduce share the same timestamp,
the tie is broken by looking at the value. This ensures that these
functions operate in a deterministic manner.
This solution due to @jwilder
Since we already got a pointsHeapItem, let's just reuse it instead
of allocating a new one. This cuts allocated memory of a 1 million
points aggregate query from 4881.97MB to 4139.86MB
Some queries may be subject to race conditions. This variable allows the
test to request that a query is executed multiple times, increasing the
chance that any race will be exposed.
The buffer allocation in bz1 was unused and I'm fairly certain that it
was harmful to performance if used. For queries that run through a bz1
block, needing to hold on to a 64kb block is expensive. Better to churn
on the allocator and have the blocks be released when they are unused
than to have 64kb hanging around for each series regardless of size.
Thanks to @jwilder for brainstorming this issue with me.
Jason Wilder
Philip O'Toole
Philip O'Toole
Daniel Morsing
dgnorton
aviau
Swann Croiset
Sean Beckett
Paul Dix
Ben Johnson