mirror of
https://github.com/qdrant/landing_page.git
synced 2026-10-06 19:38:30 +02:00
142 lines
6.0 KiB
Markdown
142 lines
6.0 KiB
Markdown
---
|
|
title: Administration
|
|
weight: 10
|
|
aliases:
|
|
- ../administration
|
|
---
|
|
|
|
# Administration
|
|
|
|
Qdrant exposes administration tools which enable to modify at runtime the behavior of a qdrant instance without changing its configuration manually.
|
|
|
|
## Recovery mode
|
|
|
|
*Available as of v1.2.0*
|
|
|
|
Recovery mode can help in situations where Qdrant fails to start repeatedly.
|
|
When starting in recovery mode, Qdrant only loads collection metadata to prevent
|
|
going out of memory. This allows you to resolve out of memory situations, for
|
|
example, by deleting a collection. After resolving Qdrant can be restarted
|
|
normally to continue operation.
|
|
|
|
In recovery mode, collection operations are limited to
|
|
[deleting](/documentation/concepts/collections/#delete-collection) a
|
|
collection. That is because only collection metadata is loaded during recovery.
|
|
|
|
To enable recovery mode with the Qdrant Docker image you must set the
|
|
environment variable `QDRANT_ALLOW_RECOVERY_MODE=true`. The container will try
|
|
to start normally first, and restarts in recovery mode if initialisation fails
|
|
due to an out of memory error. This behavior is disabled by default.
|
|
|
|
If using a Qdrant binary, recovery mode can be enabled by setting a recovery
|
|
message in an environment variable, such as
|
|
`QDRANT__STORAGE__RECOVERY_MODE="My recovery message"`.
|
|
|
|
|
|
## Strict mode
|
|
|
|
*Available as of v1.13.0*
|
|
|
|
Strict mode is a feature to restrict certain type of operations on a collection in order to protect the Qdrant cluster.
|
|
|
|
The goal is to prevent inefficient usage patterns that could overload the system.
|
|
|
|
Strict mode ensures a more predictable and responsive service when you do not have control over the queries that are being executed.
|
|
|
|
Upon crossing a limit, the server will return a client side error with the information about the limit that was crossed.
|
|
|
|
The `strict_mode_config` can be enabled when [creating](#create-a-collection) a new collection, see [schema definitions](https://api.qdrant.tech/api-reference/collections/create-collection#request.body.strict_mode_config) for all the available `strict_mode_config` parameters.
|
|
|
|
As part of the config, the `enabled` field act as a toggle to enable or disable the strict mode dynamically.
|
|
|
|
It is possible to raise the default limits and/or disable strict mode entirely. Though, in order to ensure a stable cluster we strongly recommend to keep strict mode enabled using its default configuration. For disabling strict mode on an existing collection use:
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/disable/" >}}
|
|
|
|
### Disable retrieving via non indexed payload
|
|
|
|
Setting `unindexed_filtering_retrieve` to false prevents retrieving points by filtering on a non indexed payload key which can be very slow.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-retrieve/" >}}
|
|
|
|
Or turn it off later on an existing collection through the [collection update](#update-collection-parameters) API.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-retrieve-off/" >}}
|
|
|
|
### Disable updating via non indexed payload
|
|
|
|
Setting `unindexed_filtering_update` to false prevents updating points by filtering on a non indexed payload key which can be very slow.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-update/" >}}
|
|
|
|
### Maximum number of payload index count
|
|
|
|
Setting `max_payload_index_count` caps the maximum number of payload index that can exist on a collection.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-payload-index-count/" >}}
|
|
|
|
### Maximum query `limit` parameter
|
|
|
|
Retrieving large result set is expensive.
|
|
|
|
Setting `max_query_limit` caps the maximum number of points that can be retrieved in a single query.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-query-limit/" >}}
|
|
|
|
### Maximum `timeout` parameter
|
|
|
|
Long running operations are often symptomatic of a deeper issue.
|
|
|
|
Setting `max_timeout` caps the maximum value in seconds for the `timeout` parameter in all API operations.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-timeout/" >}}
|
|
|
|
### Maximum size of a filtering condition
|
|
|
|
Large filtering conditions are expensive to evaluate.
|
|
|
|
Setting `condition_max_size` caps the maximum number of element a filtering condition can have.
|
|
|
|
e.g. the number of elements in `MatchAny`
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/condition-max-size/" >}}
|
|
|
|
### Maximum number of conditions in a filter
|
|
|
|
A large number of filtering conditions are expensive to evaluate.
|
|
|
|
Setting `filter_max_conditions` caps the maximum number of conditions filters can have.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/filter-max-conditions/" >}}
|
|
|
|
### Maximum batch size when inserting vectors
|
|
|
|
Sending very large batch upserts can create internal congestion.
|
|
|
|
Setting `upsert_max_batchsize` caps the maximum size in bytes of a batch during vector upserts.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/upsert-max-batchsize/" >}}
|
|
|
|
### Maximum collection storage size
|
|
|
|
It is possible to set the maximum size of a collection in terms of vectors and/or payload storage size.
|
|
|
|
Setting `max_collection_vector_size_bytes` and/or `max_collection_payload_size_bytes` caps the maximum byte size of a collection.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-collection-storage-size-bytes/" >}}
|
|
|
|
### Maximum points count
|
|
|
|
Setting `max_points_count` caps the maximum number of points for a collection.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-points-count/" >}}
|
|
|
|
### Rate limiting
|
|
|
|
An extremely high rate of incoming requests can have a negative impact on the latency.
|
|
|
|
Setting `read_rate_limit` and/or `write_rate_limit` to cap the maximum number of operations per minute per replica.
|
|
|
|
When exceeding the maximum number of operations, the client will receive an HTTP 429 error code with a suggested delay before retrying.
|
|
|
|
{{< code-snippet path="/documentation/headless/snippets/strict-mode/rate-limiting/" >}} |