| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Tracks invocation count, latency and failures (although we don't
expect to see any failures in this pipeline, since the remove ops
logically happen atomically with the bucket iteration).
|
|
|
|
| |
By default the legacy behavior is used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous (legacy) behavior was to immediately async schedule a
full bucket deletion in the persistence backend, which incurs a very
disproportionate cost when documents are backed by many and/or
heavy indexes (such as HNSW). This risked swamping the backend with
tens to hundreds of thousands of concurrent document deletes.
New behavior splits deletion into three phases:
1. Metadata enumeration for all documents present in the bucket
2. Persistence-throttled async remove _per individual document_
that was returned in the iteration result. This blocks the
persistence thread (by design) if the throttling window is
not sufficiently large to accomodate all pending deletes.
3. Once all async removes have been ACKed, schedule the actual
`DeleteBucket` operation towards the backend. This will clean
up any remaining (cheap) tombstone entries as well as the meta
data store. Operation reply is sent as before once the delete
has completed.
|
|
|
|
|
|
| |
Identifiers of the form `_Uppercased` are considered reserved by
the standard. Not likely to cause ambiguity in practice, but it's
preferable to stay on the good side of the standard-gods.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Remnants of the "file per bucket on spinning disks" days and no
longer used for anything.
|
| |
|
| |
|
|
|
|
| |
use std::thread directly instead
|
|
|
|
|
|
| |
also add very simple ThreadPool class to run multiple threads at once
make an effort to only join once
|
|
|
|
|
|
|
|
|
|
| |
- also stop using std::jthread
- remove Active and Joinable interfaces
- remove stop, stopped and slumber
- remove currentThread
- make start function static
- override start for Runnable w/init or custom function
- explicit stop/slumber where needed
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After initialization, the node will immediately start communicating with the cluster
controller, exchanging host info. This host info contains a subset snapshot of the active
metrics, which includes the total bucket count, doc count etc. It is critical that
we must never report back host info _prior_ to having run at least one full sweep of
the bucket database, lest we risk transiently reporting zero buckets held by the
content node. Doing so could cause orchestration logic to perform operations based
on erroneous assumptions.
To avoid this, we explicitly force a full DB sweep and metric update prior to reporting
the node as up. Since this function is called prior to the CommunicationManager thread
being started, any CC health pings should also always happen after this init step.
|
|
|
|
|
|
|
|
| |
Remove '.sum' from metric names for storage node and also remove the average metrics for the same.
Remove '.sum' from distributor metrics set and remove distributor average metrics.
GC '.sum' from distributor metric names.
Remove '.alldisks' from metric names and update tests.
GC '.alldisks' from filestor metrics.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
proton.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds an operation throttler that is intended to provide global throttling
of async operations across all persistence stripe threads. A throttler
wraps a logical max pending window size of in-flight operations. Depending
on the throttler implementation, the window size may expand and shrink
dynamically. Exactly how and when this happens is unspecified.
Commit adds two throttler implementations:
* An unlimited throttler that is no-op and never blocks.
* A throttler built around the mbus `DynamicThrottlePolicy` and defers
all window decisions to it.
Current config default is to use the unlimited throttler. Config changes
require a process restart.
Offers both polling and (timed, non-timed) blocking calls for acquiring
a throttle token. If the returned token is valid, the caller may proceed
to invoke the asynchronous operation.
The window slot taken up by a valid throttle token is implicitly freed up
when the token is destroyed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only skip deactivating buckets if the entire _node_ is marked as
maintenance state, i.e. the node has maintenance state across all
bucket spaces provided in the bundle. Otherwise treat the state
transition as if the node goes down, deactivating all buckets.
Also ensure that the bucket deactivation logic above the SPI is
identical to that within Proton. This avoids bucket DBs getting
out of sync between the two.
|
|
|
|
| |
[run-systemtest]"
|
|
|
|
|
|
|
|
|
|
|
| |
Only skip deactivating buckets if the entire _node_ is marked as
maintenance state, i.e. the node has maintenance state across all
bucket spaces provided in the bundle. Otherwise treat the state
transition as if the node goes down, deactivating all buckets.
Also ensure that the bucket deactivation logic above the SPI is
identical to that within Proton. This avoids bucket DBs getting
out of sync between the two.
|
| |
|
|
|
|
|
|
|
| |
bucket doesn't exist:
* getBucketInfo() returns success with empty bucket info
* createIterator() returns success
* iterate() returns empty complete result.
|
| |
|
| |
|
|
|
|
| |
there are.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
nodes (proton) to the cluster controller.
This is more generic than explicit address space values for enum store and multi value.
This is used in the cluster controller to determine whether to block external feed.
|
|
|
|
|
|
|
|
| |
be reported back from bucket executor.
- Treat remapping as an error.
- For lidspace compaction job iterator is reset and will be recreated on next invocation.
- For bucketmove th ebucket is rechecked and either discarded or restarted.
|
| |
|
| |
|
|
|
|
| |
configurable.
|
|
|
|
| |
order… "
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
controller via the host info API.
|