# Раздел "Searchd" в конфигурации

Приведённые ниже настройки используются в разделе `searchd` файла конфигурации Manticore Search для управления поведением сервера. Ниже приведено краткое описание каждой настройки:

### access_plain_attrs

Эта настройка устанавливает глобальные значения по умолчанию для [access_plain_attrs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files). Она является необязательной, значение по умолчанию — `mmap_preread`.

Директива `access_plain_attrs` позволяет определить значение по умолчанию для [access_plain_attrs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files) для всех таблиц, управляемых данным экземпляром searchd. Директивы на уровне таблицы имеют более высокий приоритет и переопределяют это глобальное значение по умолчанию, обеспечивая более детальный контроль.

### access_blob_attrs

Эта настройка устанавливает глобальные значения по умолчанию для [access_blob_attrs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files). Она является необязательной, значение по умолчанию — `mmap_preread`.

Директива `access_blob_attrs` позволяет определить значение по умолчанию для [access_blob_attrs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files) для всех таблиц, управляемых данным экземпляром searchd. Директивы на уровне таблицы имеют более высокий приоритет и переопределяют это глобальное значение по умолчанию, обеспечивая более детальный контроль.

### access_doclists

Эта настройка устанавливает глобальные значения по умолчанию для [access_doclists](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files). Она является необязательной, значение по умолчанию — `file`.

Директива `access_doclists` позволяет определить значение по умолчанию для [access_doclists](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files) для всех таблиц, управляемых данным экземпляром searchd. Директивы на уровне таблицы имеют более высокий приоритет и переопределяют это глобальное значение по умолчанию, обеспечивая более детальный контроль.

### access_hitlists

Эта настройка устанавливает глобальные значения по умолчанию для [access_hitlists](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files). Она является необязательной, значение по умолчанию — `file`.

Директива `access_hitlists` позволяет определить значение по умолчанию для [access_hitlists](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files) для всех таблиц, управляемых данным экземпляром searchd. Директивы на уровне таблицы имеют более высокий приоритет и переопределяют это глобальное значение по умолчанию, обеспечивая более детальный контроль.

### access_dict

Эта настройка устанавливает глобальные значения по умолчанию для [access_dict](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files). Она является необязательной, значение по умолчанию — `mmap_preread`.

Директива `access_dict` позволяет определить значение по умолчанию для [access_dict](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Accessing-table-files) для всех таблиц, управляемых данным экземпляром searchd. Директивы на уровне таблицы имеют более высокий приоритет и переопределяют это глобальное значение по умолчанию, обеспечивая более детальный контроль.

### agent_connect_timeout

Эта настройка устанавливает глобальные значения по умолчанию для параметра [agent_connect_timeout](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent_connect_timeout).


### agent_query_timeout

Эта настройка устанавливает глобальные значения по умолчанию для параметра [agent_query_timeout](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent_query_timeout). Она может быть переопределена для отдельного запроса с помощью предложения `OPTION agent_query_timeout=XXX`.


### agent_retry_count

Эта настройка представляет собой целое число, которое указывает, сколько раз Manticore будет пытаться подключиться и выполнить запрос к удалённым агентам через распределённую таблицу, прежде чем сообщить о фатальной ошибке запроса. Значение по умолчанию — 0 (т.е. без повторных попыток). Это значение также можно установить для отдельного запроса с помощью предложения `OPTION retry_count=XXX`. Если указана опция для запроса, она переопределит значение, заданное в конфигурации.

Обратите внимание, что если в определении вашей распределённой таблицы используются [зеркала агентов](../Creating_a_cluster/Remote_nodes/Mirroring.md#Agent-mirrors), сервер будет выбирать другое зеркало для каждой попытки подключения в соответствии с выбранной [ha_strategy](../Creating_a_cluster/Remote_nodes/Load_balancing.md#ha_strategy). В этом случае значение `agent_retry_count` будет агрегировано для всех зеркал в наборе.

Например, если у вас есть 10 зеркал и установлено `agent_retry_count=5`, сервер выполнит до 50 повторных попыток, предполагая в среднем по 5 попыток для каждого из 10 зеркал (при опции `ha_strategy = roundrobin` так и будет).

Однако значение, указанное в качестве опции `retry_count` для [агента](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent), служит абсолютным ограничением. Другими словами, опция `[retry_count=2]` в определении агента всегда означает максимум 2 попытки, независимо от того, указали вы для агента 1 или 10 зеркал.

### agent_retry_delay

Эта настройка представляет собой целое число в миллисекундах (или [специальных суффиксах](../Server_settings/Special_suffixes.md)), которое указывает задержку перед повторной попыткой выполнения запроса к удалённому агенту в случае сбоя. Это значение актуально только при указании ненулевого значения [agent_retry_count](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md) или ненулевого значения `retry_count` для запроса. Значение по умолчанию — 500. Это значение также можно установить для отдельного запроса с помощью предложения `OPTION retry_delay=XXX`. Если указана опция для запроса, она переопределит значение, заданное в конфигурации.


### attr_flush_period

<!-- example conf attr_flush_period -->
При использовании [Update](../Data_creation_and_modification/Updating_documents/UPDATE.md) для изменения атрибутов документов в реальном времени, изменения сначала записываются в копию атрибутов в памяти. Эти обновления происходят в файле, отображённом в память, что означает, что ОС решает, когда записать изменения на диск. При нормальном завершении работы `searchd` (вызванном сигналом `SIGTERM`), все изменения принудительно записываются на диск.

Вы также можете указать `searchd` периодически записывать эти изменения обратно на диск, чтобы предотвратить потерю данных. Интервал между этими сбросами определяется параметром `attr_flush_period`, указываемым в секундах (или с использованием [специальных суффиксов](../Server_settings/Special_suffixes.md)).

По умолчанию значение равно 0, что отключает периодический сброс. Однако сброс всё равно произойдёт при нормальном завершении работы.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
attr_flush_period = 900 # persist updates to disk every 15 minutes
```
<!-- end -->

### auth

<!-- example conf auth -->
Включает [аутентификацию и авторизацию](../Security/Authentication_and_authorization.md). Необязательный параметр, по умолчанию пустой, что отключает аутентификацию.

В [режиме RT](../Read_this_first.md#Real-time-mode-vs-plain-mode) используйте `auth = 1`, чтобы включить аутентификацию. Manticore хранит данные аутентификации в `auth.json` внутри [data_dir](../Server_settings/Searchd.md#data_dir). Используйте `auth = 0` или не задавайте этот параметр, чтобы отключить аутентификацию.

В [plain mode](../Read_this_first.md#Real-time-mode-vs-plain-mode) задайте `auth` как путь к файлу аутентификации. Не используйте `auth = 1` в plain mode.

Если аутентификация включена, демон создаёт файл аутентификации, если его нет. До первого запуска допустимо отсутствие данных или пустое хранилище, включая файл нулевого размера, файл только с пробелами, пустой JSON-объект или пустые массивы users и permissions. Полный JSON аутентификации записывается после запуска. При старте демон отклоняет неверные пути, нечитаемые файлы, файлы с правами на чтение для группы или всех пользователей, некорректный JSON, дублирующиеся сохранённые секреты и неверную структуру auth-данных. Храните файл в секрете; файлы, создаваемые демоном, имеют режим `600`.

<!-- intro -->
##### RT mode:

<!-- request RT mode -->
```ini
searchd {
    data_dir = /var/lib/manticore
    auth = 1
}
```

<!-- request Disable -->
```ini
searchd {
    data_dir = /var/lib/manticore
    auth = 0
}
```

<!-- intro -->
##### Plain mode:

<!-- request Plain mode -->
```ini
searchd {
    auth = /path/to/auth.json
}
```
<!-- end -->

### auth_log_level

<!-- example conf auth_log_level -->
Управляет подробностью журнала аутентификации. Необязательный параметр, по умолчанию `info`.

События аутентификации записываются в отдельный файл журнала рядом с журналом демона. Если [log](../Server_settings/Searchd.md#log) равен `/var/log/manticore/searchd.log`, журнал аутентификации будет `/var/log/manticore/searchd.log.auth`.

Поддерживаемые значения:

* `disabled` - не записывать события аутентификации.
* `error` - записывать отказы в доступе и критические сбои.
* `warning` - записывать ошибки и неудачные попытки аутентификации.
* `info` - записывать предупреждения, успешные изменения управления аутентификацией и резервные копии данных аутентификации при присоединении к кластеру.
* `all` - записывать события уровня `info` и успешные пользовательские события аутентификации.
* `trace` - записывать все события уровня `all` плюс успешную внутреннюю транспортную аутентификацию, например аутентификацию Manticore Buddy и API между демонами.

Успешные проверки авторизации на разрешение не записываются на любом уровне. Отказы в доступе логируются, но проверки на разрешение могут выполняться для каждого запроса и засоряли бы журнал аутентификации даже в режиме `trace`.

Когда `JOIN CLUSTER` заменяет локальные данные аутентификации, при уровнях `info`, `all` и `trace` в `searchd.log.auth` записывается JSON-резервная копия прежних локальных auth-данных. Эта копия может содержать имена пользователей, salt, хэши паролей и bearer-хэши. Рассматривайте журнал аутентификации как чувствительные операционные данные и удаляйте из него конфиденциальные сведения перед передачей.

<!-- request Example -->
```ini
auth_log_level = warning
```
<!-- end -->

### auth_password_policy

<!-- example conf auth_password_policy -->
Управляет проверкой паролей для пользователей аутентификации. Необязательный параметр, по умолчанию `LOW`.

Поддерживаемые значения:

* `LOW` - требуется непустой пароль, соответствующий [auth_password_min_length](../Server_settings/Searchd.md#auth_password_min_length).
* `MEDIUM` - требования `LOW` плюс как минимум одна строчная буква, одна прописная буква, одна цифра и один неалфавитно-цифровой символ.

Политика применяется к `searchd --auth`, `CREATE USER` и `SET PASSWORD`.

<!-- request Example -->
```ini
auth_password_policy = MEDIUM
```
<!-- end -->

### auth_password_min_length

<!-- example conf auth_password_min_length -->
Задаёт минимальную длину пароля для пользователей аутентификации. Необязательный параметр, по умолчанию `8`.

Минимальная длина применяется к `searchd --auth`, `CREATE USER` и `SET PASSWORD`.

<!-- request Example -->
```ini
auth_password_min_length = 12
```
<!-- end -->

### auto_optimize

<!-- example conf auto_optimize -->
Эта настройка управляет автоматическим процессом [OPTIMIZE](../Securing_and_compacting_a_table/Compacting_a_table.md#OPTIMIZE-TABLE) для уплотнения таблицы.

По умолчанию уплотнение таблицы происходит автоматически. Вы можете изменить это поведение с помощью настройки `auto_optimize`:
* 0 для отключения автоматического уплотнения таблицы (вы всё равно можете вручную вызывать `OPTIMIZE`)
* 1 для включения автоматического уплотнения таблицы с порогом по умолчанию
* любое целое число больше 1 для включения автоматического уплотнения таблицы с умножением порога на это значение

По умолчанию порог равен количеству логических ядер ЦП, умноженному на 2.

Однако, если таблица имеет атрибуты с KNN-индексами, порог по умолчанию отличается. В этом случае он устанавливается как количество физических ядер ЦП, делённое на 2, с минимальным значением 1, для улучшения производительности KNN-поиска.

Если [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) не задан явно (ни на уровне сервера, ни на уровне таблицы), автоматическая компакция никогда не объединяет таблицу, пока в ней меньше 2 дисковых чанков, даже если вычисленный порог по умолчанию ниже (такое может происходить на серверах с малым числом ядер CPU, особенно для таблиц KNN). Чтобы разрешить автоматическую компакцию до одного дискового чанка, задайте `optimize_cutoff` явно как `1`.

Обратите внимание, что включение или отключение `auto_optimize` не мешает вам вручную запускать [OPTIMIZE TABLE](../Securing_and_compacting_a_table/Compacting_a_table.md#OPTIMIZE-TABLE).

<!-- intro -->
##### Пример:

<!-- request Disable -->
```ini
auto_optimize = 0 # disable automatic OPTIMIZE
```

<!-- request Throttle -->
```ini
auto_optimize = 2 # OPTIMIZE starts at 16 chunks (on 4 cpu cores server)
```

<!-- end -->

### parallel_chunk_merges

<!-- example conf parallel_chunk_merges -->
Эта настройка управляет тем, сколько заданий слияния дисковых чанков серверу разрешено выполнять параллельно во время [OPTIMIZE](../Securing_and_compacting_a_table/Compacting_a_table.md#OPTIMIZE-TABLE) для таблиц реального времени.

Это влияет только на слияние дисковых чанков (уплотнение), а не на параллелизм запросов.

Установите значение `1`, чтобы отключить параллельное слияние чанков (задания слияния будут выполняться одно за другим). Более высокие значения могут ускорить уплотнение на системах с быстрым хранилищем, но увеличат одновременный ввод-вывод на диск.

По умолчанию Manticore использует значение настройки [threads](../Server_settings/Searchd.md#threads) для этого расчёта; если `threads` не настроено, по умолчанию используется количество логических ЦП. Результирующее значение по умолчанию для `parallel_chunk_merges` равно `1`, когда `threads` равен `1`, `2` или `3`, и `2`, когда `threads` равен `4` или больше (то есть `max(1, min(2, threads/2))` с использованием целочисленного деления).

Это значение можно изменить во время выполнения с помощью `SET GLOBAL parallel_chunk_merges = N` и проверить через `SHOW VARIABLES`.

<!-- intro -->
##### Пример:

<!-- request Disable -->
```ini
parallel_chunk_merges = 1
```

<!-- request Increase -->
```ini
parallel_chunk_merges = 4
```

<!-- end -->

### merge_chunks_per_job

<!-- example conf merge_chunks_per_job -->
Эта настройка управляет тем, сколько дисковых чанков RT объединяется в одном задании OPTIMIZE (N-стороннее слияние). Если доступно меньше этого числа, задание объединит то, что может (минимум 2).

Более низкие значения позволяют планировать больше заданий параллельно; более высокие значения уменьшают количество заданий, но увеличивают размер каждого слияния.

По умолчанию `2`.

Это значение можно изменить во время выполнения с помощью `SET GLOBAL merge_chunks_per_job = N` и проверить через `SHOW VARIABLES`.

<!-- intro -->
##### Пример:

<!-- request Increase -->
```ini
merge_chunks_per_job = 4
```

<!-- end -->

### knn_parallel_build

<!-- example conf knn_parallel_build -->
Эта настройка управляет тем, сколько рабочих потоков используется для построения графа HNSW во время операций, интенсивных по HNSW, на таблицах, содержащих атрибут `float_vector` с KNN-индексом. Несколько путей используют этот регулятор:
* **Проход сохранения чанка (chunk-save store pass)**: когда RAM-чанк сбрасывается на диск, рабочие разделяют RAM-сегменты чанка между собой и добавляют векторы в целевой граф HNSW параллельно.
* **Проход слияния чанков (chunk-merge store pass)**: `OPTIMIZE TABLE` и авто-оптимизация строят граф HNSW целевого чанка параллельно, разделяя диапазон живых строк из всех входных чанков между рабочими.
* **Перестройка ALTER KNN**: `ALTER TABLE ... ADD COLUMN`/`DROP COLUMN` для атрибута `float_vector` и `ALTER TABLE ... REBUILD KNN` перестраивают граф HNSW параллельно для дисковых чанков.

Это влияет только на построение графа HNSW для таблиц с KNN-атрибутами.

Установите значение `1`, чтобы отключить параллельное построение KNN (все проходы сохранения выполняются последовательно). Более высокие значения ускоряют сохранение чанков, `OPTIMIZE` и перестройки ALTER на таблицах, где построение графа HNSW доминирует во времени выполнения операции.

Параллельное построение HNSW может вставлять векторы в порядке, отличном от последовательного пути, поэтому результирующий граф `.spknn` не гарантированно будет битово идентичен графу, построенному с `knn_parallel_build = 1`.

Обратите внимание: при [`parallel_chunk_merges`](../Server_settings/Searchd.md#parallel_chunk_merges) > 1 несколько слияний могут выполняться одновременно, и каждое из них использует до `knn_parallel_build` рабочих потоков.

По умолчанию Manticore выводит значение из настройки [threads](../Server_settings/Searchd.md#threads): `max(1, min(4, threads/4))`. То есть `1` (последовательно), когда `threads` меньше 8, `2`, когда `threads` <= 11, `3`, когда `threads` <= 15, и `4`, когда 16 или больше (ограничено 4 по умолчанию). Операторы с более крупными хостами, желающие большего параллелизма, могут установить значение явно.

Это значение можно изменить во время выполнения с помощью `SET GLOBAL knn_parallel_build = N` и проверить через `SHOW VARIABLES`.

<!-- intro -->
##### Пример:

<!-- request Disable -->
```ini
knn_parallel_build = 1
```

<!-- request Increase -->
```ini
knn_parallel_build = 4
```

<!-- end -->

### embeddings_threads

<!-- example conf embeddings_threads -->
Этот параметр ограничивает число потоков CPU, которые Manticore использует при преобразовании текста в векторы. Он применяется всякий раз, когда запускаются автоэмбеддинги: при вставке строк в таблицу, использующую `model_name`/`from`, когда `ALTER TABLE` перестраивает автоматически встроенный столбец `float_vector`, а также когда поиск `knn(<field>, '<text>', ...)` передает запрос в виде текста.

Фактическое число используемых потоков также ограничивается количеством свободных воркеров, поэтому на загруженном сервере будет использоваться меньше потоков, даже если предел высокий. Используйте этот параметр, чтобы один большой пакет эмбеддингов не лишал ресурсов параллельные поиски.

По умолчанию `4`. Установите `0`, чтобы снять ограничение, и тогда библиотека embeddings сама определит число потоков (по-прежнему с учетом количества свободных воркеров).

Это значение можно изменить во время работы с помощью `SET GLOBAL embeddings_threads = N` и просмотреть через `SHOW VARIABLES`. Для запросов `SELECT` с KNN его также можно переопределить для конкретного запроса через `OPTION embeddings_threads = N` (см. [поиск вектором KNN](../Searching/KNN.md#KNN-vector-search)).

<!-- intro -->
##### Пример:

<!-- request Default -->
```ini
embeddings_threads = 4
```

<!-- request Uncapped -->
```ini
embeddings_threads = 0
```

<!-- end -->

### auto_schema

<!-- example conf auto_schema -->
Manticore поддерживает автоматическое создание таблиц, которые ещё не существуют, но указаны в операторах INSERT. Эта функция включена по умолчанию. Чтобы отключить её, явно установите `auto_schema = 0` в вашей конфигурации. Чтобы снова включить, установите `auto_schema = -1` или удалите настройку `auto_schema` из конфигурации.

Имейте в виду, что HTTP-эндпоинт `/bulk` не поддерживает автоматическое создание таблиц.

> ПРИМЕЧАНИЕ: Функция [автоматической схемы](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema) требует наличия [Manticore Buddy](../Installation/Manticore_Buddy.md). Если она не работает, убедитесь, что Buddy установлен.

<!-- request Disable -->
```ini
auto_schema = 0 # disable automatic table creation
```

<!-- request Enable -->
```ini
auto_schema = 1 # enable automatic table creation
```

<!-- end -->

### binlog_flush

<!-- example conf binlog_flush -->
Эта настройка управляет режимом сброса/синхронизации транзакций бинарного лога. Она является опциональной, со значением по умолчанию 2 (сброс каждой транзакции, синхронизация каждую секунду).

Директива определяет, как часто бинарный лог будет сбрасываться в ОС и синхронизироваться на диск. Поддерживаются три режима:

*  0, сброс и синхронизация каждую секунду. Это обеспечивает наилучшую производительность, но до 1 секунды зафиксированных транзакций может быть потеряно в случае сбоя сервера или сбоя ОС/оборудования.
*  1, сброс и синхронизация каждой транзакции. Этот режим обеспечивает наихудшую производительность, но гарантирует сохранность данных каждой зафиксированной транзакции.
*  2, сброс каждой транзакции, синхронизация каждую секунду. Этот режим обеспечивает хорошую производительность и гарантирует сохранность каждой зафиксированной транзакции в случае сбоя сервера. Однако, в случае сбоя ОС/оборудования, может быть потеряно до 1 секунды зафиксированных транзакций.

Для тех, кто знаком с MySQL и InnoDB, эта директива похожа на `innodb_flush_log_at_trx_commit`. В большинстве случаев гибридный режим по умолчанию 2 обеспечивает хороший баланс скорости и безопасности, с полной защитой данных RT-таблиц от сбоев сервера и некоторой защитой от аппаратных сбоев.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
binlog_flush = 1 # ultimate safety, low speed
```
<!-- end -->

### binlog_common

<!-- example conf binlog_common -->
Эта настройка управляет тем, как управляются файлы бинарного лога. Она является опциональной, со значением по умолчанию 0 (отдельный файл для каждой таблицы).

Вы можете выбрать между двумя способами управления файлами бинарного лога:

* Отдельный файл для каждой таблицы (по умолчанию, `0`): Каждая таблица сохраняет свои изменения в собственном файле лога. Такая конфигурация хороша, если у вас много таблиц, которые обновляются в разное время. Она позволяет обновлять таблицы, не дожидаясь других. Кроме того, если возникнет проблема с файлом лога одной таблицы, это не затронет остальные.
* Один файл для всех таблиц (`1`): Все таблицы используют один и тот же файл бинарного лога. Этот метод упрощает управление файлами, потому что их меньше. Однако это может сохранять файлы дольше, чем необходимо, если одной таблице всё ещё нужно сохранять свои обновления. Эта настройка также может замедлить работу, если многие таблицы нуждаются в обновлении одновременно, потому что все изменения должны ждать записи в один файл.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
binlog_common = 1 # use a single binary log file for all tables
```
<!-- end -->

### binlog_max_log_size

<!-- example conf binlog_max_log_size -->
Эта настройка управляет максимальным размером файла бинарного лога. Она является опциональной, со значением по умолчанию 256 МБ.

Новый файл бинарного лога будет принудительно открыт, как только текущий файл достигнет этого ограничения по размеру. Это приводит к более мелкой гранулярности логов и может обеспечить более эффективное использование диска для бинарного лога при определённых пограничных нагрузках. Значение 0 означает, что файл бинарного лога не должен переоткрываться на основе размера.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
binlog_max_log_size = 16M
```
<!-- end -->


### binlog_path

<!-- example conf binlog_path -->
Эта настройка определяет путь для файлов бинарного лога (также известного как лог транзакций). Она является опциональной, со значением по умолчанию, соответствующим каталогу данных, настроенному во время сборки (например, `/var/lib/manticore/data/binlog.*` в Linux).

Бинарные логи используются для восстановления после сбоев данных RT-таблиц и для обновлений атрибутов обычных дисковых индексов, которые в противном случае хранились бы только в ОЗУ до сброса. Когда логирование включено, каждая транзакция, зафиксированная (COMMIT) в RT-таблице, записывается в файл лога. Затем логи автоматически воспроизводятся при запуске после некорректного завершения работы, восстанавливая залогированные изменения.

Директива `binlog_path` указывает расположение файлов бинарного лога. Она должна содержать только путь; `searchd` создаст и удалит несколько файлов `binlog.*` в каталоге по мере необходимости (включая файлы данных бинарного лога, метаданных, блокировок и т.д.).

Пустое значение отключает бинарное логирование, что повышает производительность, но подвергает данные RT-таблиц риску.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
binlog_path = # disable logging
binlog_path = /var/lib/manticore/data # /var/lib/manticore/data/binlog.001 etc will be created
```
<!-- end -->

### boolean_simplify

<!-- example conf boolean_simplify -->
Эта настройка управляет значением по умолчанию для опции поиска [boolean_simplify](../Searching/Options.md#boolean_simplify). Она является опциональной, со значением по умолчанию 1 (включено).

Когда установлено значение 1, сервер будет автоматически применять [оптимизацию булевых запросов](../Searching/Full_text_matching/Boolean_optimization.md) для улучшения производительности запросов. Когда установлено значение 0, запросы по умолчанию будут выполняться без оптимизации. Это значение по умолчанию может быть переопределено для каждого запроса с помощью соответствующей опции поиска `boolean_simplify`.

<!-- request Example -->
```ini
searchd {
    boolean_simplify = 0  # disable boolean optimization by default
}
```
<!-- end -->

### buddy_path

<!-- example conf buddy_path -->
Этот параметр определяет путь к бинарному файлу Manticore Buddy. Он является необязательным, со значением по умолчанию, заданным во время сборки, которое различается в разных операционных системах. Обычно вам не нужно изменять этот параметр. Однако он может быть полезен, если вы хотите запустить Manticore Buddy в режиме отладки, внести изменения в Manticore Buddy или реализовать новый плагин. В последнем случае вы можете выполнить `git clone` Buddy из https://github.com/manticoresoftware/manticoresearch-buddy, добавить новый плагин в директорию `./plugins/` и запустить `composer install --prefer-source` для упрощения разработки после перехода в исходный каталог Buddy.

Чтобы вы могли запустить `composer`, на вашей машине должна быть установлена PHP версии 8.2 или выше со следующими расширениями:

```
--enable-dom
--with-libxml
--enable-tokenizer
--enable-xml
--enable-xmlwriter
--enable-xmlreader
--enable-simplexml
--enable-phar
--enable-bcmath
--with-gmp
--enable-debug
--with-mysqli
--enable-mysqlnd
```

Вы также можете выбрать специальную версию `manticore-executor-dev` для Linux amd64, доступную в релизах, например: https://github.com/manticoresoftware/executor/releases/tag/v1.0.13

Если вы выберете этот путь, не забудьте связать dev-версию manticore executor с `/usr/bin/php`.

Чтобы отключить Manticore Buddy, установите значение пустым, как показано в примере.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
buddy_path = manticore-executor -n /usr/share/manticore/modules/manticore-buddy/src/main.php # use the default Manticore Buddy in Linux
buddy_path = manticore-executor -n /usr/share/manticore/modules/manticore-buddy/src/main.php --threads=1 # runs Buddy with a single worker
buddy_path = manticore-executor -n /opt/homebrew/share/manticore/modules/manticore-buddy/bin/manticore-buddy/src/main.php # use the default Manticore Buddy in MacOS arm64
buddy_path = manticore-executor -n /Users/username/manticoresearch-buddy/src/main.php # use Manticore Buddy from a non-default location
buddy_path = # disables Manticore Buddy
buddy_path = manticore-executor -n /Users/username/manticoresearch-buddy/src/main.php --skip=manticoresoftware/buddy-plugin-replace # --skip - skips plugins
buddy_path = manticore-executor -n /usr/share/manticore/modules/manticore-buddy/src/main.php --enable-plugin=manticoresoftware/buddy-plugin-show # runs Buddy with only the SHOW plugin
```
<!-- end -->

### client_timeout

<!-- example conf client_timeout -->
Этот параметр определяет максимальное время ожидания между запросами (в секундах или [специальных суффиксах](../Server_settings/Special_suffixes.md)) при использовании постоянных соединений. Он является необязательным, со значением по умолчанию пять минут.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
client_timeout = 1h
```
<!-- end -->


### collation_libc_locale

<!-- example conf collation_libc_locale -->
Локаль libc сервера. Необязательный параметр, по умолчанию C.

Определяет локаль libc, влияющую на сортировки на основе libc. Подробности смотрите в разделе [collations](../Searching/Collations.md).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
collation_libc_locale = fr_FR
```
<!-- end -->


### collation_server

<!-- example conf collation_server -->
Сортировка сервера по умолчанию. Необязательный параметр, по умолчанию libc_ci.

Определяет сортировку по умолчанию, используемую для входящих запросов. Сортировку можно переопределить для каждого запроса. Список доступных сортировок и другие подробности смотрите в разделе [collations](../Searching/Collations.md).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
collation_server = utf8_ci
```
<!-- end -->


### data_dir

<!-- example conf data_dir -->
При указании этот параметр включает [режим реального времени](../Creating_a_table/Local_tables.md#Online-schema-management-%28RT-mode%29), который является императивным способом управления схемой данных. Значение должно быть путем к директории, где вы хотите хранить все ваши таблицы, бинарные логи и всё остальное, необходимое для правильного функционирования Manticore Search в этом режиме.
Индексирование [обычных таблиц](../Creating_a_table/Local_tables/Plain_table.md) не разрешено, когда указан `data_dir`. Подробнее о разнице между режимом RT и обычным режимом читайте в [этом разделе](../Read_this_first.md#Real-time-table-vs-plain-table).

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
data_dir = /var/lib/manticore
```
<!-- end -->

### attr_autoconv_strict

<!-- example conf attr_autoconv_strict -->
Этот параметр управляет строгим режимом проверки для преобразований типов из строки в число во время операций INSERT и REPLACE. Необязательный параметр, по умолчанию 0 (нестрогий режим, обратно совместимый).

При установке в 1 (строгий режим) недопустимые преобразования строки в число (например, преобразование пустой строки `''` или нечисловой строки `'a'` в атрибут bigint) будут возвращать ошибки вместо тихого преобразования в 0. Это помогает выявлять проблемы с качеством данных на раннем этапе во время вставки данных.

При установке в 0 (нестрогий режим, по умолчанию) недопустимые преобразования будут тихо преобразовываться в 0, сохраняя обратную совместимость со старыми версиями.

Строгий режим проверяет следующие случаи:
* Пустые строки или строки, которые не могут быть преобразованы
* Строки с завершающими нечисловыми символами (например, `'123abc'`)
* Числовые значения, превышающие диапазоны типов (переполнение/недополнение)

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
attr_autoconv_strict = 1  # enable strict conversion mode
```
<!-- end -->

### diskchunk_flush_search_timeout

<!-- example conf diskchunk_flush_search_timeout -->
Таймаут для предотвращения автоматической сброски RAM-чанка, если в таблице нет поисковых запросов. Необязательный параметр, по умолчанию 30 секунд.

Время для проверки наличия поисковых запросов перед определением необходимости автоматической сброски.
Автоматическая сброска произойдет только если в таблице был хотя бы один поисковый запрос за последние `diskchunk_flush_search_timeout` секунд. Работает совместно с [diskchunk_flush_write_timeout](../Server_settings/Searchd.md#diskchunk_flush_write_timeout). Соответствующий [настройка на уровне таблицы](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#diskchunk_flush_search_timeout) имеет более высокий приоритет и переопределит это значение по умолчанию для всего экземпляра, обеспечивая более детальный контроль.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
diskchunk_flush_search_timeout = 120s
```
<!-- end -->

### diskchunk_flush_write_timeout

<!-- example conf diskchunk_flush_write_timeout -->
Время в секундах ожидания без записи перед автоматической сброской RAM-чанка на диск. Необязательный параметр, по умолчанию 1 секунда.

Если в RAM-чанке не происходит записи в течение `diskchunk_flush_write_timeout` секунд, чанк будет сброшен на диск. Работает совместно с [diskchunk_flush_search_timeout](../Server_settings/Searchd.md#diskchunk_flush_search_timeout). Чтобы отключить автоматическую сброску, явно установите `diskchunk_flush_write_timeout = -1` в вашей конфигурации. Соответствующий [настройка на уровне таблицы](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#diskchunk_flush_write_timeout) имеет более высокий приоритет и переопределит это значение по умолчанию для всего экземпляра, обеспечивая более детальный контроль.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
diskchunk_flush_write_timeout = 60s
```
<!-- end -->

### docstore_cache_size

<!-- example conf docstore_cache_size -->
Этот параметр задаёт максимальный размер блоков документов из хранилища документов, которые хранятся в памяти. Он является необязательным, значение по умолчанию — 16m (16 мегабайт).

Когда используется `stored_fields`, блоки документов считываются с диска и распаковываются. Поскольку каждый блок обычно содержит несколько документов, он может быть повторно использован при обработке следующего документа. Для этой цели блок хранится в кэше, общем для всего сервера. Кэш содержит распакованные блоки.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
docstore_cache_size = 8m
```
<!-- end -->

### engine

<!-- example conf engine -->
Движок хранения атрибутов по умолчанию, используемый при создании таблиц в режиме RT. Может быть `rowwise` (по умолчанию) или `columnar`.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
engine = columnar
```
<!-- end -->


### expansion_limit

<!-- example conf expansion_limit -->
Этот параметр определяет максимальное количество расширенных ключевых слов для одной подстановки (wildcard). Он является необязательным, значение по умолчанию — 0 (без ограничений).

При выполнении поиска по подстрокам в таблицах, созданных с включённым `dict = keywords`, одна подстановка может потенциально привести к тысячам или даже миллионам совпадающих ключевых слов (представьте себе сопоставление `a*` со всем Оксфордским словарём). Эта директива позволяет ограничить влияние таких расширений. Установка `expansion_limit = N` ограничивает расширения не более чем N наиболее частотными совпадающими ключевыми словами (для каждой подстановки в запросе).

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
expansion_limit = 16
```
<!-- end -->

### expansion_merge_threshold_docs

<!-- example conf expansion_merge_threshold_docs -->
Этот параметр определяет максимальное количество документов в расширенном ключевом слове, которое позволяет объединить все такие ключевые слова вместе. Он является необязательным, значение по умолчанию — 32.

При выполнении поиска по подстрокам в таблицах, созданных с включённым `dict = keywords`, одна подстановка может потенциально привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит того, сколько ключевых слов будет объединено вместе, чтобы ускорить сопоставление, но при этом используется больше памяти при поиске.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
expansion_merge_threshold_docs = 1024
```
<!-- end -->

### expansion_merge_threshold_hits

<!-- example conf expansion_merge_threshold_hits -->
Этот параметр определяет максимальное количество вхождений (hits) в расширенном ключевом слове, которое позволяет объединить все такие ключевые слова вместе. Он является необязательным, значение по умолчанию — 256.

При выполнении поиска по подстрокам в таблицах, созданных с включённым `dict = keywords`, одна подстановка может потенциально привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит того, сколько ключевых слов будет объединено вместе, чтобы ускорить сопоставление, но при этом используется больше памяти при поиске.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
expansion_merge_threshold_hits = 512
```
<!-- end -->

### expansion_phrase_limit

<!-- example conf expansion_phrase_limit -->
Этот параметр управляет максимальным количеством альтернативных вариантов фраз, генерируемых из-за операторов `OR` внутри операторов `PHRASE`, `PROXIMITY` и `QUORUM`. Он является необязательным, значение по умолчанию — 1024.

При использовании оператора `|` (OR) внутри оператора, похожего на фразу, общее количество расширенных комбинаций может расти экспоненциально в зависимости от количества указанных альтернатив. Этот параметр помогает предотвратить чрезмерное расширение запроса, ограничивая количество перестановок, рассматриваемых при обработке запроса.

Если количество сгенерированных вариантов превышает этот лимит, запрос либо:

- завершится с ошибкой (поведение по умолчанию)
- вернёт частичные результаты с предупреждением, если включён `expansion_phrase_warning`

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
expansion_phrase_limit = 4096
```
<!-- end -->

### expansion_phrase_warning

<!-- example conf expansion_phrase_warning -->
Этот параметр управляет поведением при превышении лимита расширения запроса, заданного `expansion_phrase_limit`.

По умолчанию запрос завершится с сообщением об ошибке. Когда `expansion_phrase_warning` установлен в 1, поиск продолжается с использованием частичного преобразования фразы (вплоть до настроенного лимита), и сервер возвращает пользователю предупреждающее сообщение вместе с набором результатов. Это позволяет запросам, которые слишком сложны для полного расширения, всё равно возвращать частичные результаты без полного сбоя.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
expansion_phrase_warning = 1
```
<!-- end -->

### grouping_in_utc

Этот параметр указывает, будет ли группировка по времени в API и SQL рассчитываться в локальном часовом поясе или в UTC. Он является необязательным, значение по умолчанию — 0 (означает 'локальный часовой пояс').

По умолчанию все выражения 'group by time' (например, группировка по дням, неделям, месяцам и годам в API, а также по дням, месяцам, годам, yearmonth, yearmonthday в SQL) выполняются с использованием локального времени. Например, если у вас есть документы с атрибутами времени `13:00 utc` и `15:00 utc`, при группировке они оба попадут в группы объектов в соответствии с настройкой вашего локального часового пояса. Если вы находитесь в `utc`, это будет один день, но если вы находитесь в `utc+10`, то эти документы будут сопоставлены с разными группами объектов `group by day` (поскольку 13:00 utc в часовом поясе UTC+10 — это 23:00 местного времени, а 15:00 — 01:00 следующего дня). Иногда такое поведение неприемлемо, и желательно сделать группировку по времени независимой от часового пояса. Вы можете запустить сервер с определённой глобальной переменной окружения TZ, но это повлияет не только на группировку, но и на временные метки в логах, что также может быть нежелательно. Включение этой опции (либо в конфигурации, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL) приведёт к тому, что все выражения группировки по времени будут рассчитываться в UTC, оставляя остальные зависящие от времени функции (например, логирование сервера) в локальном часовом поясе.


### timezone

Этот параметр задаёт часовой пояс, который будет использоваться функциями, связанными с датой/временем. По умолчанию используется локальный часовой пояс, но вы можете указать другой часовой пояс в формате IANA (например, `Europe/Amsterdam`).

Обратите внимание, что эта настройка не влияет на журналирование, которое всегда работает в локальной часовой зоне.

Также обратите внимание, что если используется `grouping_in_utc`, функция 'group by time' будет использовать UTC, в то время как другие функции, связанные с датой/время, будут использовать указанную часовую зону. В целом, не рекомендуется смешивать `grouping_in_utc` и `timezone`.

Вы можете настроить этот параметр либо в конфигурации, либо с помощью оператора [SET global](../Server_settings/Setting_variables_online.md#SET) в SQL.


### ha_period_karma

<!-- example conf ha_period_karma -->
Эта настройка определяет размер окна статистики агента-зеркала в секундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Она является опциональной, с дефолтным значением 60 секунд.

Для распределенной таблицы, содержащей агенты-зеркала (см. подробнее в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md), мастер отслеживает несколько различных счетчиков для каждого зеркала. Эти счетчики затем используются для переключения при сбоях и балансировки (мастер выбирает лучшее зеркало для использования на основе счетчиков). Счетчики аккумулируются в блоках продолжительностью `ha_period_karma` секунд.

После начала нового блока мастер может продолжать использовать аккумулированные значения из предыдущего блока до тех пор, пока новый блок заполнится наполовину. В результате, любая предыдущая история перестает влияет на выбор зеркала через максимум 1.5 раза от ha_period_karma секунд.

Хотя для выбора зеркала используется максимум два блока, для инструментальных целей хранятся до 15 последних блоков. Эти блокы можно просмотреть с помощью оператора [SHOW AGENT STATUS](../Node_info_and_management/Node_status.md#SHOW-AGENT-STATUS).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
ha_period_karma = 2m
```
<!-- end -->


### ha_ping_interval

<!-- example conf ha_ping_interval -->
Эта настройка определяет интервал между ping-командами для агентов-зеркалов в миллисекундах (или [special_suffixes](../Server_settings/Special_suffixes.md)). Она является опциональной, с дефолтным значением 1000 миллисекунд.

Для распределенной таблицы, содержащей агенты-зеркала (см. подробнее в [agent](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md)), мастер отправляет всем зеркалам ping команду в периоды бездействия. Это позволяет отслеживать текущий статус агента (жив или мертв, сетевой раундтрип, etc). Интервал между такими ping-командами определяется этой директивой. Чтобы отключить ping-команды, установите ha_ping_interval в 0.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
ha_ping_interval = 3s
```
<!-- end -->


### hostname_lookup

Опция `hostname_lookup` определяет стратегию обновления hostnames. По умолчанию IP адреса hostnames агентов кэшируются при запуске сервера, чтобы избежать чрезмерного обращения к DNS. Однако, в некоторых случаях, IP может меняться динамически (например, облачный хостинг) и может быть желательным не кэшировать IP. Установка этой опции в `request` отключает кэширование и выполняет запрос к DNS для каждого запроса. IP адреса также могут быть обновлены вручную с помощью команды [`FLUSH HOSTNAMES`](../Securing_and_compacting_a_table/Flushing_hostnames.md).

### jobs_queue_size

Настройка jobs_queue_size определяет, сколько "jobs" может находиться в очереди одновременно. По умолчанию она не ограничена.

В большинстве случаев "job" означает один запрос к одной локальной таблице (обычная таблица или дисковый чанк таблицы в режиме real-time). Например, если у вас есть распределенная таблица, состоящая из 2 локальных таблиц или таблица real-time с 2 дисковыми чанками, поисковый запрос к любой из них в основном поместит 2 jobs в очередь. Затем пул потоков (количество которых определяется [threads](../Server_settings/Searchd.md#threads) будет их обрабатывать. Однако, в некоторых случаях, если запрос слишком сложный, может быть создано больше jobs. Изменение этой настройки рекомендуется, когда [max_connections](../Server_settings/Searchd.md#max_connections) и [threads](../Server_settings/Searchd.md#threads) недостаточно для достижения баланса между желаемой производительностью.

### join_batch_size

Присоединения таблиц работают путем аккумулирования батча совпадений, которые являются результатами выполнения запроса на левой таблице. Затем этот батч обрабатывается как один запрос на правой таблице.

Эта опция позволяет регулировать размер батча. Дефолтное значение `1000`, и установка этой опции в `0` отключает батчирование.

Больший размер батча может улучшить производительность; однако, для некоторых запросов, это может привести к чрезмерному потреблению памяти.

<!-- example conf join_batch_size -->
<!-- intro -->
##### Конфигурация:

<!-- request Config -->
```ini
join_batch_size = 2000
```
<!-- end -->

### join_cache_size

Каждый запрос, выполняемый на правой таблице, определяется конкретными условиями JOIN ON, которые определяют набор результатов, полученный из правой таблицы.

Если есть только несколько уникальных условий JOIN ON, повторное использование результатов может быть более эффективным, чем многократное выполнение запросов на правой таблице. Для этого наборы результатов хранятся в кэше.

Эта опция позволяет настроить размер этого кэша. Дефолтное значение `20 MB`, и установка этой опции в 0 отключает кэширование.

Обратите внимание, что каждый поток поддерживает свой собственный кэш, поэтому при оценке общего использования памяти следует учитывать количество потоков, выполняющих запросы.

<!-- example conf join_cache_size -->
<!-- intro -->
##### Конфигурация:

<!-- request Config -->
```ini
join_cache_size = 10M
```
<!-- end -->

### listen_backlog

<!-- example conf listen_backlog -->
Настройка listen_backlog определяет длину backlog TCP listen для входящих соединений. Это особенно актуально для сборок Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает своего предела, новые входящие соединения будут отклонены.
Для сборок не Windows дефолтное значение должно работать нормально, и обычно нет необходимости корректировать эту настройку.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
listen_backlog = 20
```
<!-- end -->

### kibana_version_string

<!-- example conf kibana_version_string -->
Строка версии сервера для возврата Kibana или OpenSearch Dashboards. Опциональна — по умолчанию установлена `7.6.0`.

Некоторые версии Kibana и OpenSearch Dashboards ожидают, что сервер сообщит определённый номер версии и могут вести себя по-разному в зависимости от него. Чтобы обойти такие проблемы, вы можете использовать эту настройку, которая заставляет Manticore сообщать пользовательскую версию Kibana или OpenSearch Dashboards.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
kibana_version_string = 1.2.3
```
<!-- end -->

### listen

<!-- example conf listen -->
Эта настройка позволяет указать IP-адрес и порт или путь к Unix-доменному сокету, на которых Manticore будет принимать соединения.

Общий синтаксис для `listen`:

```ini
listen = ( address ":" port | port | path | address ":" port start - port end ) [ ":" protocol [ "_vip" ] [ "_readonly" ] ]
```

Вы можете указать:
* либо IP-адрес (или имя хоста) и номер порта
* либо только номер порта
* либо путь к Unix-сокету (не поддерживается в Windows)
* либо IP-адрес и диапазон портов

Если вы укажете номер порта, но не адрес, `searchd` будет слушать на всех сетевых интерфейсах. Unix-путь определяется по начальному слешу. Диапазон портов можно установить только для протокола репликации.

Вы также можете указать обработчик протокола (слушатель), который будет использоваться для соединений на этом сокете. Слушатели:

* **Не указан** - Manticore будет принимать соединения на этом порту от:
  - других агентов Manticore (т.е. удалённой распределённой таблицы)
  - клиентов через HTTP и HTTPS
  - [Manticore Buddy](https://manticoresearch.com/blog/manticoresearch-buddy-intro/). **Убедитесь, что у вас есть слушатель такого типа (или слушатель `http`, как упомянуто ниже), чтобы избежать ограничений в функциональности Manticore.**
* `mysql` - протокол MySQL для соединений от клиентов MySQL. Примечание:
  - Сжатый протокол также поддерживается.
  - Если включён [SSL](../Security/SSL.md#SSL), вы можете установить зашифрованное соединение.
* `replication` - протокол репликации, используемый для общения между узлами. Подробнее можно узнать в разделе [репликация](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md). Вы можете указать несколько слушателей репликации, но все они должны слушать на одном IP; могут различаться только порты. Когда вы определяете слушатель репликации с диапазоном портов (например, `listen = 192.168.0.1:9320-9328:replication`), Manticore не начинает немедленно слушать на этих портах. Вместо этого он займёт случайные свободные порты из указанного диапазона только тогда, когда вы начнёте использовать репликацию. Для корректной работы репликации требуется как минимум 2 порта в диапазоне.
* `http` - то же, что и **Не указан**. Manticore будет принимать соединения на этом порту от удалённых агентов и клиентов через HTTP и HTTPS.
* `https` - протокол HTTPS. Manticore будет принимать **только** HTTPS-соединения на этом порту. Подробнее можно узнать в разделе [SSL](../Security/SSL.md).
* `sphinx` - устаревший бинарный протокол. Используется для обслуживания соединений от удалённых клиентов [SphinxSE](../Extensions/SphinxSE.md). Некоторые реализации клиентов Sphinx API (пример - Java) требуют явного объявления слушателя.

Добавление суффикса `_vip` к клиентским протоколам (то есть ко всем, кроме `replication`, например `mysql_vip` или `http_vip` или просто `_vip`) принудительно создаёт выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае сильной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.

Суффикс `_readonly` устанавливает [режим только для чтения](../Security/Read_only.md) для слушателя и ограничивает его приём только запросов на чтение.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
listen = localhost
listen = localhost:5000 # listen for remote agents (binary API) and http/https requests on port 5000 at localhost
listen = 192.168.0.1:5000 # listen for remote agents (binary API) and http/https requests on port 5000 at 192.168.0.1
listen = /var/run/manticore/manticore.s # listen for binary API requests on unix socket
listen = /var/run/manticore/manticore.s:mysql # listen for mysql requests on unix socket
listen = 9312 # listen for remote agents (binary API) and http/https requests on port 9312 on any interface
listen = localhost:9306:mysql # listen for mysql requests on port 9306 at localhost
listen = localhost:9307:mysql_readonly # listen for mysql requests on port 9307 at localhost and accept only read queries
listen = 127.0.0.1:9308:http # listen for http requests as well as connections from remote agents (and binary API) on port 9308 at localhost
listen = 192.168.0.1:9320-9328:replication # listen for replication connections on ports 9320-9328 at 192.168.0.1
listen = 127.0.0.1:9443:https # listen for https requests (not http) on port 9443 at 127.0.0.1
listen = 127.0.0.1:9312:sphinx # listen for legacy Sphinx requests (e.g. from SphinxSE) on port 9312 at 127.0.0.1
```
<!-- end -->

Директив `listen` может быть несколько. `searchd` будет слушать клиентские соединения на всех указанных портах и сокетах. Конфигурация по умолчанию, предоставляемая в пакетах Manticore, определяет прослушивание на портах:
* `9308` и `9312` для соединений от удалённых агентов и клиентов, не основанных на MySQL
* и на порту `9306` для соединений MySQL.

Если вы вообще не укажете `listen` в конфигурации, Manticore будет ожидать соединений на:
* `127.0.0.1:9306` для клиентов MySQL
* `127.0.0.1:9312` для HTTP/HTTPS и соединений от других узлов Manticore и клиентов, основанных на бинарном API Manticore.

#### Прослушивание на привилегированных портах

По умолчанию Linux не позволит вам заставить Manticore слушать на порту ниже 1024 (например, `listen = 127.0.0.1:80:http` или `listen = 127.0.0.1:443:https`), если вы не запустите searchd от имени root. Если вы всё же хотите иметь возможность запускать Manticore так, чтобы он слушал на портах < 1024 под непривилегированным пользователем, рассмотрите один из следующих вариантов (любой из них должен работать):
* Выполните команду `setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd`
* Добавьте `AmbientCapabilities=CAP_NET_BIND_SERVICE` в systemd-юнит Manticore и перезагрузите демон (`systemctl daemon-reload`).

#### Технические детали о протоколе Sphinx API и TFO
<details>
Устаревший протокол Sphinx имеет 2 фазы: обмен рукопожатием и поток данных. Рукопожатие состоит из пакета в 4 байта от клиента и пакета в 4 байта от демона с единственной целью - клиент определяет, что удалённая сторона является настоящим демоном Sphinx, демон определяет, что удалённая сторона является настоящим клиентом Sphinx. Основной поток данных довольно прост: пусть обе стороны объявят свои рукопожатия, а противоположная сторона проверит их. Этот обмен короткими пакетами подразумевает использование специального флага `TCP_NODELAY`, который отключает алгоритм Nagle в TCP и объявляет, что TCP-соединение будет выполняться как диалог небольших пакетов.
Однако, строго не определено, кто говорит первым в этих переговорах. Исторически все клиенты, использующие бинарный API, говорят первыми: отправляют рукопожатие, затем читают 4 байта от демона, затем отправляют запрос и читают ответ от демона.
Когда мы улучшали совместимость протокола Sphinx, мы учитывали эти вещи:

1. Обычно связь мастер-агент устанавливается от известного клиента к известному хосту на известном порту. Поэтому маловероятно, что конечная точка предоставит некорректное рукопожатие. Таким образом, мы можем неявно предположить, что обе стороны являются валидными и действительно общаются по протоколу Sphinx.
2. Исходя из этого предположения, мы можем «склеить» рукопожатие с реальным запросом и отправить их в одном пакете. Если бэкенд представляет собой устаревший демон Sphinx, он просто прочитает этот склеенный пакет как 4 байта рукопожатия, а затем тело запроса. Поскольку они оба пришли в одном пакете, сокет бэкенда имеет -1 RTT, а буфер фронтенда продолжает работать обычным образом, несмотря на этот факт.
3. Продолжая предположение: поскольку пакет «запроса» довольно мал, а рукопожатие ещё меньше, давайте отправим оба в начальном TCP-пакете «SYN», используя современную технику TFO (TCP Fast Open). То есть: мы подключаемся к удалённому узлу со склеенным пакетом рукопожатия + тела. Демон принимает соединение и сразу же получает и рукопожатие, и тело в буфере сокета, так как они пришли в самом первом TCP-пакете «SYN». Это устраняет ещё один RTT.
4. Наконец, научим демон принимать это улучшение. Фактически, со стороны приложения это подразумевает НЕ использовать `TCP_NODELAY`. А со стороны системы — обеспечить, чтобы на стороне демона было активировано принятие TFO, а на стороне клиента — отправка TFO. По умолчанию в современных системах клиентский TFO уже активирован, поэтому вам нужно только настроить серверный TFO, чтобы всё работало.

Все эти улучшения без фактического изменения самого протокола позволили нам устранить 1,5 RTT протокола TCP из соединения. Что, если запрос и ответ могут быть размещены в одном TCP-пакете, сокращает всю сессию бинарного API с 3,5 RTT до 2 RTT — что делает сетевое согласование примерно в 2 раза быстрее.

Итак, все наши улучшения основаны на изначально неопределённом утверждении: «кто говорит первым». Если клиент говорит первым, мы можем применить все эти оптимизации и эффективно обработать подключение + рукопожатие + запрос в одном TFO-пакете. Более того, мы можем посмотреть на начало полученного пакета и определить реальный протокол. Вот почему вы можете подключиться к одному и тому же порту через API/http/https. Если демон должен говорить первым, все эти оптимизации невозможны, и мультипротокол также невозможен. Вот почему у нас есть выделенный порт для MySQL и мы не объединили его со всеми остальными протоколами в один порт. Внезапно среди всех клиентов один был написан с предположением, что демон должен отправить рукопожатие первым. То есть — нет возможности для всех описанных улучшений. Это плагин SphinxSE для mysql/mariadb. Поэтому специально для этого единственного клиента мы выделили определение протокола `sphinx` для работы наиболее устаревшим способом. А именно: обе стороны активируют `TCP_NODELAY` и обмениваются небольшими пакетами. Демон отправляет своё рукопожатие при подключении, затем клиент отправляет своё, и затем всё работает обычным образом. Это не очень оптимально, но просто работает. Если вы используете SphinxSE для подключения к Manticore — вам нужно выделить слушатель с явно указанным протоколом `sphinx`. Для других клиентов — избегайте использования этого слушателя, так как он медленнее. Если вы используете другие устаревшие клиенты Sphinx API — сначала проверьте, могут ли они работать с невыделенным мультипротокольным портом. Для связи мастер-агент использование невыделенного (мультипротокольного) порта и включение клиентского и серверного TFO работает хорошо и определённо сделает работу сетевого бэкенда быстрее, особенно если у вас очень лёгкие и быстрые запросы.
</details>

### listen_tfo

Эта настройка позволяет использовать флаг TCP_FASTOPEN для всех слушателей. По умолчанию она управляется системой, но может быть явно отключена установкой значения '0'.

Для общего понимания расширения TCP Fast Open обратитесь к [Википедии](https://en.wikipedia.org/wiki/TCP_Fast_Open). Вкратце, оно позволяет устранить один круговой обход TCP при установлении соединения.

На практике использование TFO во многих ситуациях может оптимизировать сетевую эффективность клиент-агент, как если бы использовались [постоянные агенты](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md), но без удержания активных соединений, а также без ограничения на максимальное количество соединений.

В современных ОС поддержка TFO обычно включена на системном уровне, но это лишь «возможность», а не правило. Linux (как самый прогрессивный) поддерживает её с 2011 года, начиная с ядер 3.7 (для серверной стороны). Windows поддерживает её с некоторых сборок Windows 10. Другие операционные системы (FreeBSD, MacOS) также в игре.

Для Linux система сервера проверяет переменную `/proc/sys/net/ipv4/tcp_fastopen` и ведёт себя в соответствии с ней. Бит 0 управляет клиентской стороной, бит 1 — слушателями. По умолчанию в системе этот параметр установлен в 1, т.е. клиенты включены, слушатели отключены.

### log

<!-- example conf log -->
Настройка log указывает имя файла журнала, в который будут записываться все события времени выполнения `searchd`. Если не указано, имя по умолчанию — 'searchd.log'.

В качестве имени файла также можно использовать 'syslog'. В этом случае события будут отправляться демону syslog. Чтобы использовать опцию syslog, необходимо сконфигурировать Manticore с опцией `-–with-syslog` во время сборки.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
log = /var/log/searchd.log
```
<!-- end -->


### max_batch_queries

<!-- example conf max_batch_queries -->
Ограничивает количество запросов в пакете. Необязательный параметр, по умолчанию равен 32.

Заставляет searchd выполнять проверку корректности количества запросов, отправленных в одном пакете при использовании [многозапросов](../Searching/Multi-queries.md). Установите значение 0, чтобы пропустить проверку.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_batch_queries = 256
```
<!-- end -->

### max_connections

<!-- example max_connections -->
Максимальное количество одновременных клиентских подключений. По умолчанию не ограничено. Обычно это заметно только при использовании любого вида постоянных соединений, таких как сессии cli mysql или постоянные удаленные подключения от удаленных распределенных таблиц. При превышении лимита вы все равно можете подключиться к серверу, используя [VIP-подключение](../Connecting_to_the_server/MySQL_protocol.md#VIP-connection). VIP-подключения не учитываются в лимите.

<!-- request Example -->
```ini
max_connections = 10
```

<!-- end -->

### max_threads_per_query

<!-- example max_threads_per_query -->
Глобальное ограничение на количество потоков, которое может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра процессора, не оставляя места для других операций. Например, `call pq` для достаточно большой таблицы перколяции может использовать все потоки в течение десятков секунд. Установка `max_threads_per_query` в, скажем, половину от [threads](../Server_settings/Searchd.md#threads) гарантирует, что вы сможете запустить пару таких операций `call pq` параллельно.

Вы также можете установить эту настройку как переменную сессии или глобальную переменную во время выполнения.

Кроме того, вы можете управлять поведением для каждого запроса с помощью опции [threads OPTION](../Searching/Options.md#threads).

<!-- intro -->
##### Пример:
<!-- request Example -->

```ini
max_threads_per_query = 4
```

<!-- end -->

### max_filters

<!-- example conf max_filters -->
Максимально допустимое количество фильтров на запрос. Эта настройка используется только для внутренних проверок корректности и не влияет напрямую на использование оперативной памяти или производительность. Необязательная, значение по умолчанию — 256.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_filters = 1024
```
<!-- end -->


### max_filter_values

<!-- example conf max_filter_values -->
Максимально допустимое количество значений на фильтр. Эта настройка используется только для внутренних проверок корректности и не влияет напрямую на использование оперативной памяти или производительность. Необязательная, значение по умолчанию — 4096.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_filter_values = 16384
```
<!-- end -->


### max_open_files

<!-- example conf max_open_files -->
Максимальное количество файлов, которое серверу разрешено открывать, называется "мягким лимитом". Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может потребовать установки высокого значения этого лимита, так как каждый дисковый чанк может занимать десяток или более файлов. Например, таблица реального времени с 1000 чанков может потребовать одновременного открытия тысяч файлов. Если вы столкнулись с ошибкой 'Too many open files' в логах, попробуйте изменить эту опцию, так как это может помочь решить проблему.

Также существует "жесткий лимит", который не может быть превышен с помощью этой опции. Этот лимит определяется системой и может быть изменен в файле `/etc/security/limits.conf` в Linux. В других операционных системах могут быть другие подходы, поэтому обратитесь к вашим руководствам для получения дополнительной информации.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_open_files = 10000
```
<!-- end -->

<!-- example conf max_open_files max -->
Помимо прямых числовых значений, вы можете использовать волшебное слово 'max', чтобы установить лимит равным доступному текущему жесткому лимиту.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_open_files = max
```
<!-- end -->


### max_packet_size

<!-- example conf max_packet_size -->
Максимально допустимый размер сетевого пакета. Эта настройка ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удаленных агентов в распределенной среде. Используется только для внутренних проверок корректности, не влияет напрямую на использование оперативной памяти или производительность. Необязательная, значение по умолчанию — 128M.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
max_packet_size = 32M
```
<!-- end -->


### mysql_version_string

<!-- example conf mysql_version_string -->
Строка версии сервера, возвращаемая по протоколу MySQL. Необязательная, значение по умолчанию — пустая строка (возвращает версию Manticore).

Некоторые привередливые клиентские библиотеки MySQL зависят от определенного формата номера версии, используемого MySQL, и более того, иногда выбирают другой путь выполнения на основе сообщаемого номера версии (а не указанных флагов возможностей). Например, Python MySQLdb 1.2.2 выбрасывает исключение, когда номер версии не в формате X.Y.ZZ; MySQL .NET connector 6.3.x внутренне завершается с ошибкой на номерах версий 1.x в сочетании с определенной комбинацией флагов и т.д. Чтобы обойти это, вы можете использовать директиву `mysql_version_string` и заставить `searchd` сообщать другую версию клиентам, подключающимся по протоколу MySQL. (По умолчанию он сообщает свою собственную версию.)


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
mysql_version_string = 5.0.37
```
<!-- end -->


### net_workers

Количество сетевых потоков, по умолчанию 1.

Эта настройка полезна при чрезвычайно высокой частоте запросов, когда одного потока недостаточно для управления всеми входящими запросами.


### net_wait_tm

Управляет интервалом активного цикла сетевого потока. Значение по умолчанию -1, может быть установлено в -1, 0 или положительное целое число.

В случаях, когда сервер настроен как чистый мастер и просто маршрутизирует запросы агентам, важно обрабатывать запросы без задержек и не позволять сетевому потоку спать. Для этого существует активный цикл. После входящего запроса сетевой поток использует опрос CPU в течение `10 * net_wait_tm` миллисекунд, если `net_wait_tm` является положительным числом, или опрашивает только с помощью CPU, если `net_wait_tm` равен `0`. Также активный цикл может быть отключен с помощью `net_wait_tm = -1` — в этом случае поллер устанавливает таймаут на фактический таймаут агентов при системном вызове опроса.

> **ВНИМАНИЕ:** Активный цикл CPU фактически нагружает ядро процессора, поэтому установка этого значения в любое значение, отличное от значения по умолчанию, вызовет заметное использование CPU даже при простое сервера.


### net_throttle_accept

Определяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что должно подходить большинству пользователей. Это тонкая настройка для управления пропускной способностью сетевого цикла в сценариях высокой нагрузки.


### net_throttle_action

Определяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что должно подходить большинству пользователей. Это тонкая настройка для управления пропускной способностью сетевого цикла в сценариях высокой нагрузки.

### network_timeout

<!-- example conf network_timeout -->
Таймаут чтения/записи запросов сетевого клиента, в секундах (или [специальные суффиксы](../Server_settings/Special_suffixes.md)). Необязательный параметр, по умолчанию 5 секунд. `searchd` принудительно закроет соединение с клиентом, который не успел отправить запрос или прочитать результат в течение этого таймаута.

Также обратите внимание на параметр [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet). Этот параметр изменяет поведение `network_timeout` с применения ко всему `запросу` или `результату` на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объем данных, этот параметр может оказаться бесценным для поддержания активных операций.

<!-- request Example -->

```ini
network_timeout = 10s
```
<!-- end -->

### node_address

<!-- example conf node_address -->
Эта настройка позволяет указать сетевой адрес узла. По умолчанию он устанавливается на адрес репликации [listen](../Server_settings/Searchd.md#listen). Это верно в большинстве случаев; однако бывают ситуации, когда его необходимо указать вручную:

* Узел за брандмауэром
* Включен трансляция сетевых адресов (NAT)
* Развертывания в контейнерах, такие как Docker или облачные развертывания
* Кластеры с узлами более чем в одном регионе


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
node_address = 10.101.0.10
```
<!-- end -->

### not_terms_only_allowed

<!-- example conf not_terms_only_allowed -->
Эта настройка определяет, разрешать ли запросы, содержащие только оператор полнотекстового поиска [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator). Необязательный параметр, по умолчанию 0 (запросы только с оператором NOT завершаются ошибкой).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
not_terms_only_allowed = 1
```
<!-- end -->

### optimize_cutoff

<!-- example conf optimize_cutoff -->
Устанавливает пороговое значение по умолчанию для уплотнения таблицы. Подробнее читайте здесь - [Количество оптимизированных дисковых чанков](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Эту настройку можно переопределить с помощью опции для каждого запроса [cutoff](../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks). Её также можно изменить динамически с помощью [SET GLOBAL](../Server_settings/Setting_variables_online.md#SET).

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
optimize_cutoff = 4
```
<!-- end -->

### persistent_connections_limit

<!-- example conf persistent_connections_limit -->
Эта настройка определяет максимальное количество одновременных постоянных соединений с удаленными [постоянными агентами](../Creating_a_table/Creating_a_distributed_table/Creating_a_local_distributed_table.md). Каждый раз при подключении к агенту, определенному в `agent_persistent`, мы пытаемся повторно использовать существующее соединение (если оно есть) или подключиться и сохранить соединение для будущего использования. Однако в некоторых случаях имеет смысл ограничить количество таких постоянных соединений. Эта директива определяет лимит. Она влияет на количество соединений с хостом каждого агента во всех распределенных таблицах.

Рекомендуется установить значение равным или меньшим, чем опция [max_connections](../Server_settings/Searchd.md#max_connections) в конфигурации агента.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
persistent_connections_limit = 29 # assume that each host of agents has max_connections = 30 (or 29).
```
<!-- end -->


### pid_file

<!-- example conf pid_file -->
`pid_file` — это опция конфигурации, которая указывает путь к файлу, хранящему идентификатор процесса (PID) сервера `searchd`.

Файл PID создается и блокируется при запуске и содержит идентификатор основного процесса сервера, пока сервер работает. Файл удаляется при остановке сервера. Этот файл позволяет Manticore выполнять внутренние задачи, такие как:

* Проверка, запущен ли уже экземпляр `searchd`.
* Остановка процесса `searchd`.
* Инициирование ротации таблиц.

Файл PID также может использоваться внешними скриптами автоматизации.

**Требования:**
`pid_file` является необязательным, если `searchd` запускается с опциями `--console`, `--nodetach` или `--systemd`, или если автоматически обнаружено управление systemd. Во всех остальных случаях эта настройка обязательна. Она также требуется, если используется опция командной строки `--pidfile`.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
pid_file = /run/manticore/searchd.pid
```
<!-- end -->

### preopen_tables

<!-- example conf preopen_tables -->
Директива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки для каждой таблицы [preopen](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#Other-performance-related-settings). Если установлено значение 0, настройки для каждой таблицы могут вступить в силу, и они будут по умолчанию равны 0.

Предварительное открытие таблиц может предотвратить гонки между поисковыми запросами и ротациями, которые могут иногда вызывать сбои запросов. Однако это также использует больше файловых дескрипторов. В большинстве сценариев рекомендуется предварительно открывать таблицы.

Вот пример конфигурации:

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
preopen_tables = 1
```
<!-- end -->

### pseudo_sharding

<!-- example conf pseudo_sharding -->
Опция конфигурации pseudo_sharding включает распараллеливание поисковых запросов к локальным обычным и реального времени таблицам, независимо от того, запрашиваются ли они напрямую или через распределенную таблицу. Эта функция будет автоматически распараллеливать запросы до количества потоков, указанного в `searchd.threads` # потоков.

Обратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:
* высокая параллельность запросов
* физическое шардирование любого вида:
  - распределенная таблица из нескольких обычных/реального времени таблиц
  - таблица реального времени, состоящая из слишком большого количества дисковых чанков

тогда включение pseudo_sharding может не дать никаких преимуществ и даже привести к небольшому снижению пропускной способности. Если вы отдаете приоритет более высокой пропускной способности, а не меньшей задержке, рекомендуется отключить эту опцию.

Включено по умолчанию.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
pseudo_sharding = 0
```
<!-- end -->


### replication_connect_timeout

Директива `replication_connect_timeout` определяет время ожидания для подключения к удалённому узлу. По умолчанию значение считается в миллисекундах, но оно может иметь [другой суффикс](../Server_settings/Special_suffixes.md). Значение по умолчанию — 1000 (1 секунда).

При подключении к удалённому узлу Manticore будет ожидать успешного завершения соединения максимум указанное время. Если время ожидания достигнуто, но соединение не установлено, и включены `retries`, будет предпринята повторная попытка.


### replication_query_timeout

Директива `replication_query_timeout` устанавливает время, которое searchd будет ожидать завершения запроса на удалённом узле. Значение по умолчанию — 3000 миллисекунд (3 секунды), но оно может быть `суффиксировано` для указания другой единицы времени.

После установления соединения Manticore будет ожидать завершения запроса на удалённом узле максимум `replication_query_timeout`. Обратите внимание, что это время ожидания отдельно от `replication_connect_timeout`, и общая возможная задержка, вызванная удалённым узлом, будет суммой обоих значений.


### replication_retry_count

Эта настройка представляет собой целое число, которое указывает, сколько раз Manticore попытается подключиться и выполнить запрос к удалённому узлу во время репликации перед сообщением о критической ошибке запроса. Значение по умолчанию — 3.


### replication_retry_delay

Эта настройка представляет собой целое число в миллисекундах (или [специальные суффиксы](../Server_settings/Special_suffixes.md)), которое указывает задержку перед повторной попыткой запроса к удалённому узлу в случае сбоя во время репликации. Это значение имеет смысл только при указании ненулевого значения. Значение по умолчанию — 500.

### qcache_max_bytes

<!-- example conf qcache_max_bytes -->
Эта конфигурация устанавливает максимальный объём памяти, выделяемой для кэшированных наборов результатов, в байтах. Значение по умолчанию — 16777216, что соответствует 16 мегабайтам. Если значение установлено в 0, кэш запросов отключен. Для получения дополнительной информации о кэше запросов обратитесь к разделу [кэш запросов](../Searching/Query_cache.md).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
qcache_max_bytes = 16777216
```
<!-- end -->


### qcache_thresh_msec

Целое число, в миллисекундах. Минимальный порог фактического времени выполнения для кэширования результата запроса. По умолчанию 3000, или 3 секунды. 0 означает кэшировать всё. Для подробностей обратитесь к разделу [кэш запросов](../Searching/Query_cache.md). Это значение также может быть выражено с использованием временных [специальных суффиксов](../Server_settings/Special_suffixes.md), но используйте их осторожно и не путайтесь с названием самого значения, содержащим '_msec'.


### qcache_ttl_sec

Целое число, в секундах. Период действия для кэшированного набор результатов. По умолчанию 60, или 1 минута. Минимально возможное значение — 1 секунда. Для подробностей обратитесь к разделу [кэш запросов](../Searching/Query_cache.md). Это значение также может быть выражено с использованием временных [специальных суффиксов](../Server_settings/Special_suffixes.md), но используйте их осторожно и не путайтесь с названием самого значения, содержащим '_sec'.


### query_log_format

<!-- example conf query_log_format -->
Формат журнала запросов. Опционально, допустимые значения: `plain` и `sphinxql`, по умолчанию `sphinxql`.

Режим `sphinxql` записывает корректные SQL-запросы. Режим `plain` записывает запросы в формате простого текста (в основном подходит для случаев чисто полнотекстового поиска). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также может быть изменён динамически с использованием синтаксиса `SET GLOBAL query_log_format=sphinxql`. Для подробностей обратитесь к разделу [Журналирование запросов](../Logging/Query_logging.md).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
query_log_format = sphinxql
```
<!-- end -->

### query_log_min_msec

Предел (в миллисекундах), который предотвращает запись запроса в журнал запросов. Опционально, по умолчанию 0 (все запросы записываются в журнал запросов). Эта директива указывает, что будут записываться только запросы с временем выполнения, превышающим указанный предел (это значение также может быть выражено с использованием временных [специальных суффиксов](../Server_settings/Special_suffixes.md), но используйте их осторожно и не путайтесь с названием самого значения, содержащим `_msec`).

### query_log

<!-- example conf query_log -->
Имя файла журнала запросов. Опционально, по умолчанию пустое (не записывать запросы). Все поисковые запросы (такие как SELECT ... но не INSERT/REPLACE/UPDATE запросы) будут записываться в этот файл. Формат описана в разделе [Журналирование запросов](../Logging/Query_logging.md). В случае формата 'plain' можно использовать 'syslog' как путь к файлу журнала. В этом случае все поисковые запросы будут отправляться демону syslog с приоритетом `LOG_INFO`, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть сконфигурирован с `-–with-syslog` при сборке.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
query_log = /var/log/query.log
```
<!-- end -->


### query_log_mode

<!-- example conf query_log_mode -->
Директива `query_log_mode` позволяет установить разные права доступа для файлов журнала searchd и запросов. По умолчанию эти файлы журнала создаются с правами 600, что означает, что только пользователь, под которым работает сервер, и пользователи root могут читать файлы журнала.
Эта директива может быть полезной, если вы хотите разрешить другим пользователям читать файлы журнала, например, решениям мониторинга, работающим под пользователями без прав root.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
query_log_mode  = 666
```
<!-- end -->

### read_buffer_docs

<!-- example conf read_buffer_docs -->
Директива `read_buffer_docs` управляет размером буфера чтения для списков документов для каждого ключевого слова. Для каждого вхождения ключевого слова в каждом поисковом запросе есть два связанных буфера чтения: один для списка документов и один для списка совпадений. Эта настройка позволяет управлять размером буфера списка документов.

Больший размер буфера может увеличить использование памяти на запрос, но возможно уменьшить время I/O. Логично устанавливать большие значения для медленных хранилищ, но для хранилищ с высокой производительностью IOPS эксперименты следует проводить в области низких значений.

Значение по умолчанию — 256K, минимальное значение — 8K. Вы также можете установить [read_buffer_docs](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_docs) для каждой таблицы отдельно, что переопределит любые настройки на уровне конфигурации сервера.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
read_buffer_docs = 128K
```
<!-- end -->


### read_buffer_hits

<!-- example conf read_buffer_hits -->
Директива read_buffer_hits задает размер буфера чтения на ключевое слово для списков совпадений (hit lists) в поисковых запросах. По умолчанию размер составляет 256K, минимальное значение — 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка совпадений. Увеличение размера буфера может повысить использование оперативной памяти на запрос, но сократить время ввода-вывода. Для медленных систем хранения имеет смысл использовать буферы большего размера, в то время как для хранилищ с высокой производительностью IOPS следует экспериментировать в области низких значений.

Эту настройку также можно указать для каждой таблицы отдельно с помощью опции read_buffer_hits в [read_buffer_hits](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#read_buffer_hits), что переопределит настройку на уровне сервера.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
read_buffer_hits = 128K
```
<!-- end -->

### read_unhinted

<!-- example conf read_unhinted -->
Размер чтения без предварительного указания размера (unhinted read). Необязательный параметр, значение по умолчанию — 32K, минимальное — 1K.

При выполнении запросов некоторые операции чтения заранее точно знают, какой объем данных необходимо прочитать, но в настоящее время некоторые этого не знают. Наиболее заметно, что размер списка совпадений в настоящее время неизвестен заранее. Эта настройка позволяет контролировать, сколько данных читать в таких случаях. Она влияет на время ввода-вывода для списков совпадений, уменьшая его для списков, размер которых превышает значение read_unhinted, но увеличивая для списков меньшего размера. Она **не** влияет на использование оперативной памяти, так как буфер чтения уже будет выделен. Поэтому она не должна быть больше, чем read_buffer.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
read_unhinted = 32K
```
<!-- end -->

### reset_network_timeout_on_packet

<!-- example conf reset_network_timeout_on_packet -->
Уточняет поведение сетевых таймаутов (таких как `network_timeout` и `agent_query_timeout`).

Если установлено значение 0, таймауты ограничивают максимальное время на отправку всего запроса/запроса.
Если установлено значение 1 (по умолчанию), таймауты ограничивают максимальное время между сетевыми активностями.

При репликации узлу может потребоваться отправить большой файл (например, 100 ГБ) другому узлу. Предположим, сеть может передавать данные со скоростью 1 ГБ/с, пакетами по 4-5 МБ каждый. Для передачи всего файла потребуется 100 секунд. Таймаут по умолчанию в 5 секунд позволит передать только 5 ГБ до разрыва соединения. Увеличение таймаута может быть обходным решением, но оно не масштабируется (например, следующий файл может быть 150 ГБ, что снова приведет к сбою). Однако при значении `reset_network_timeout_on_packet` по умолчанию, равном 1, таймаут применяется не ко всей передаче, а к отдельным пакетам. Пока передача продолжается (и данные фактически принимаются по сети в течение периода таймаута), соединение остается активным. Если передача зависнет, так что между пакетами произойдет таймаут, соединение будет разорвано.

Обратите внимание, что если вы настраиваете распределенную таблицу, каждый узел — как мастер, так и агенты — должен быть настроен. На стороне мастера затрагивается `agent_query_timeout`; на агентах актуален `network_timeout`.

<!-- intro -->

##### Пример:

<!-- request Example -->

```ini
reset_network_timeout_on_packet = 0
```

<!-- end -->


### rt_flush_period

<!-- example conf rt_flush_period -->
Период проверки сброса RAM-чанков RT-таблиц на диск, в секундах (или с [специальными суффиксами](../Server_settings/Special_suffixes.md)). Необязательный параметр, значение по умолчанию — 10 часов.

Активно обновляемые RT-таблицы, которые полностью помещаются в RAM-чанки, все равно могут приводить к постоянному росту бинарных логов (binlogs), влияя на использование диска и время восстановления после сбоя. С помощью этой директивы поисковый сервер выполняет периодические проверки на сброс, и подходящие RAM-чанки могут быть сохранены, что позволяет выполнить последующую очистку бинарных логов. Подробнее см. в разделе [Бинарное логирование](../Logging/Binary_logging.md).

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
rt_flush_period = 3600 # 1 hour
```
<!-- end -->


### rt_merge_iops

<!-- example conf rt_merge_iops -->
Максимальное количество операций ввода-вывода (в секунду), которое разрешено запускать потоку слияния RT-чанков. Необязательный параметр, значение по умолчанию — 0 (без ограничений).

Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов `OPTIMIZE`. Гарантируется, что все операции оптимизации RT-таблиц не будут генерировать больше операций ввода-вывода в секунду (IOPS), чем установленный лимит. Ограничение rt_merge_iops может уменьшить снижение производительности поиска, вызванное слиянием.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
rt_merge_iops = 40
```
<!-- end -->

### rt_merge_maxiosize

<!-- example conf rt_merge_maxiosize -->
Максимальный размер операции ввода-вывода, которую разрешено запускать потоку слияния RT-чанков. Необязательный параметр, значение по умолчанию — 0 (без ограничений).

Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов `OPTIMIZE`. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции ввода-вывода в отношении ограничения [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops). Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
rt_merge_maxiosize = 1M
```
<!-- end -->


### seamless_rotate

<!-- example conf seamless_rotate -->
Предотвращает простои `searchd` при ротации таблиц с огромными объемами данных, требующими предварительного кэширования. Необязательный параметр, значение по умолчанию — 1 (включить бесшовную ротацию). В системах Windows бесшовная ротация по умолчанию отключена.

Таблицы могут содержать некоторые данные, которые необходимо предварительно кэшировать в оперативной памяти. В настоящее время файлы `.spa`, `.spb`, `.spi` и `.spm` полностью предварительно кэшируются (они содержат данные атрибутов, данные атрибутов типа blob, таблицу ключевых слов и карту удаленных строк соответственно.) Без бесшовной ротации ротация таблицы пытается использовать как можно меньше оперативной памяти и работает следующим образом:

1. Новые запросы временно отклоняются (с кодом ошибки "retry");
2. `searchd` ожидает завершения всех текущих выполняемых запросов;
3. Старая таблица освобождается, и её файлы переименовываются;
4. Файлы новой таблицы переименовываются, и выделяется необходимая оперативная память;
5. Данные атрибутов и словаря новой таблицы предзагружаются в оперативную память;
6. `searchd` возобновляет обслуживание запросов из новой таблицы.

Однако, если данных атрибутов или словаря много, то этап предзагрузки может занять заметное время — до нескольких минут в случае предзагрузки файлов размером 1–5+ ГБ.

При включённом бесшовном ротации процесс работает следующим образом:

1. Выделяется оперативная память для хранения новой таблицы;
2. Данные атрибутов и словаря новой таблицы асинхронно предзагружаются в оперативную память;
3. В случае успеха старая таблица освобождается, и файлы обеих таблиц переименовываются;
4. В случае сбоя новая таблица освобождается;
5. В любой момент времени запросы обслуживаются либо из старой, либо из новой копии таблицы.

Бесшовная ротация достигается ценой более высокого пикового использования памяти во время ротации (поскольку данные `.spa/.spb/.spi/.spm` как старой, так и новой копии должны находиться в оперативной памяти во время предзагрузки новой копии). Среднее использование остаётся прежним.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
seamless_rotate = 1
```
<!-- end -->

### secondary_index_block_cache
<!-- example conf secondary_index_block_cache -->

Эта опция задаёт размер блочного кэша, используемого вторичными индексами. Она является необязательной, по умолчанию составляет 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений.
В объединённых запросах этот процесс повторяется для каждого пакета строк из левой таблицы, и каждый пакет может перечитывать одни и те же метаданные в рамках одного объединённого запроса. Это может серьёзно повлиять на производительность. Кэш блоков метаданных хранит эти блоки в памяти, чтобы они
могли быть повторно использованы последующими пакетами.

Кэш используется только в объединённых запросах и не влияет на необъединённые запросы. Обратите внимание, что ограничение размера кэша применяется для каждого атрибута и каждого вторичного индекса. Каждый атрибут в пределах каждого дискового чанка работает в рамках этого ограничения. В худшем случае общее использование памяти
можно оценить, умножив лимит на количество дисковых чанков и количество атрибутов, используемых в объединённых запросах.

Установка `secondary_index_block_cache = 0` отключает кэш.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
secondary_index_block_cache = 16M
```

<!-- end -->

### secondary_indexes
<!-- example conf secondary_indexes -->

Эта опция включает/отключает использование вторичных индексов для поисковых запросов. Она является необязательной, по умолчанию установлена в 1 (включено). Обратите внимание, что для индексации её включать не нужно, так как она всегда включена, пока установлена [Manticore Columnar Library](https://github.com/manticoresoftware/columnar). Последняя также требуется для использования индексов при поиске. Доступны три режима:

* `0`: Отключить использование вторичных индексов при поиске. Их можно включить для отдельных запросов с помощью [анализаторных подсказок](../Searching/Options.md#Query-optimizer-hints)
* `1`: Включить использование вторичных индексов при поиске. Их можно отключить для отдельных запросов с помощью [анализаторных подсказок](../Searching/Options.md#Query-optimizer-hints)
* `force`: То же, что и включение, но любые ошибки при загрузке вторичных индексов будут сообщены, и весь индекс не будет загружен в демон.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
secondary_indexes = 1
```

<!-- end -->

### server_id

<!-- example conf server_id -->
Целое число, которое служит идентификатором сервера, используемым как начальное значение для генерации уникального короткого UUID для узлов, являющихся частью репликационного кластера. server_id должен быть уникальным среди узлов кластера и находиться в диапазоне от 0 до 127. Если server_id не задан, он вычисляется как хэш MAC-адреса и пути к PID-файлу, или в качестве начального значения для короткого UUID будет использовано случайное число.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
server_id = 1
```
<!-- end -->


### shutdown_timeout

<!-- example conf shutdown_timeout -->
Время ожидания для `searchd --stopwait` в секундах (или с [специальными суффиксами](../Server_settings/Special_suffixes.md)). Необязательный параметр, по умолчанию 60 секунд.

При запуске `searchd --stopwait` ваш сервер должен выполнить некоторые действия перед остановкой, такие как завершение запросов, сброс RAM-чанков RT, сброс атрибутов и обновление binlog. Эти задачи требуют некоторого времени. `searchd --stopwait` будет ждать до `shutdown_time` секунд, пока сервер завершит свою работу. Подходящее время зависит от размера вашей таблицы и нагрузки.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
shutdown_timeout = 3m # wait for up to 3 minutes
```
<!-- end -->


### shutdown_token

SHA1-хэш пароля, необходимого для вызова команды 'shutdown' из VIP-подключения Manticore SQL. Без него [отладочная](../Reporting_bugs.md#DEBUG) подкоманда 'shutdown' никогда не приведёт к остановке сервера. Обратите внимание, что такое простое хеширование не следует считать надёжной защитой, поскольку мы не используем хэш с солью или какую-либо современную хэш-функцию. Это предназначено как предохранительная мера для служебных демонов в локальной сети.

### skiplist_cache_size

<!-- example conf skiplist_cache_size -->
Эта настройка задаёт максимальный размер кэша в оперативной памяти для распакованных списков пропуска (skiplists). Необязательный параметр, по умолчанию 64M.

Списки пропуска используются для ускорения поиска в больших списках документов. Их кэширование позволяет избежать многократной распаковки одних и тех же данных списков пропуска в разных запросах. Установите эту опцию в `0`, чтобы отключить кэширование.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
skiplist_cache_size = 128M
```
<!-- end -->

### snippets_file_prefix

<!-- example conf snippets_file_prefix -->
Префикс, добавляемый к локальным именам файлов при генерации сниппетов. Необязательный параметр, по умолчанию — текущая рабочая папка.

Этот префикс можно использовать при распределённой генерации сниппетов вместе с опциями `load_files` или `load_files_scattered`.

Обратите внимание, что это префикс, а **не** путь! Это означает, что если префикс установлен в "server1", а запрос ссылается на "file23", `searchd` попытается открыть "server1file23" (всё это без кавычек). Поэтому, если вам нужен путь, вы должны включить завершающий слэш.

После построения окончательного пути к файлу сервер разворачивает все относительные директории и сравнивает конечный результат со значением `snippet_file_prefix`. Если результат не начинается с префикса, такой файл будет отклонён с сообщением об ошибке.

Например, если вы установите его в `/mnt/data`, и кто-то вызовет генерацию сниппета с файлом `../../../etc/passwd` в качестве источника, он получит сообщение об ошибке:

`Файл '/mnt/data/../../../etc/passwd' выходит за пределы области '/mnt/data/'`

вместо содержимого файла.

Также, при неустановленном параметре и чтении `/etc/passwd`, фактически будет прочитан /daemon/working/folder/etc/passwd, поскольку значение по умолчанию для параметра — рабочая папка сервера.

Также обратите внимание, что это локальная опция; она никак не влияет на агентов. Таким образом, вы можете безопасно установить префикс на главном сервере. Запросы, перенаправленные агентам, не будут затронуты настройкой главного сервера. Однако они будут затронуты собственными настройками агента.

Это может быть полезно, например, когда места хранения документов (будь то локальное хранилище или точки монтирования NAS) не согласованы между серверами.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
snippets_file_prefix = /mnt/common/server1/
```
<!-- end -->

> **ВНИМАНИЕ:** Если вы всё ещё хотите получить доступ к файлам из корня файловой системы, вы должны явно установить `snippets_file_prefix` в пустое значение (строкой `snippets_file_prefix=`), или в корень (строкой `snippets_file_prefix=/`).


### sphinxql_state

<!-- example conf sphinxql_state -->
Путь к файлу, в котором будет сериализовано текущее состояние SQL.

При запуске сервера этот файл воспроизводится. При соответствующих изменениях состояния (например, SET GLOBAL) этот файл автоматически перезаписывается. Это может предотвратить трудно диагностируемую проблему: если вы загружаете UDF-функции, но Manticore падает, то при (автоматическом) перезапуске ваши UDF и глобальные переменные больше не будут доступны. Использование постоянного состояния помогает обеспечить корректное восстановление без таких сюрпризов.

`sphinxql_state` нельзя использовать для выполнения произвольных команд, таких как `CREATE TABLE`.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
sphinxql_state = uservars.sql
```
<!-- end -->


### sphinxql_timeout

<!-- example conf sphinxql_timeout -->
Максимальное время ожидания между запросами (в секундах или с [специальными суффиксами](../Server_settings/Special_suffixes.md)) при использовании SQL-интерфейса. Необязательный параметр, по умолчанию 15 минут.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
sphinxql_timeout = 15m
```
<!-- end -->


### ssl_ca

<!-- example conf ssl_ca -->
Путь к файлу сертификата центра сертификации (CA) SSL (также известному как корневой сертификат). Необязательный параметр, по умолчанию пуст. Если не пуст, сертификат в `ssl_cert` должен быть подписан этим корневым сертификатом.

Сервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.

<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
ssl_ca = keys/ca-cert.pem
```
<!-- end -->


### ssl_cert

<!-- example conf ssl_cert -->
Путь к SSL-сертификату сервера. Необязательный параметр, по умолчанию пуст.

Сервер использует этот сертификат в качестве самоподписанного открытого ключа для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
ssl_cert = keys/server-cert.pem
```
<!-- end -->


### ssl_key

<!-- example conf ssl_key -->
Путь к ключу SSL-сертификата. Необязательный параметр, по умолчанию пуст.

Сервер использует этот закрытый ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
ssl_key = keys/server-key.pem
```
<!-- end -->


### subtree_docs_cache

<!-- example conf subtree_docs_cache -->
Максимальный размер кэша документов общего поддерева на запрос. Необязательный параметр, по умолчанию 0 (отключено).

Эта настройка ограничивает использование оперативной памяти оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько оперативной памяти будет потрачено на кэширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
subtree_docs_cache = 8M
```
<!-- end -->


### subtree_hits_cache

<!-- example conf subtree_hits_cache -->
Максимальный размер кэша вхождений общего поддерева на запрос. Необязательный параметр, по умолчанию 0 (отключено).

Эта настройка ограничивает использование оперативной памяти оптимизатором общего поддерева (см. [мультизапросы](../Searching/Multi-queries.md)). Максимум столько оперативной памяти будет потрачено на кэширование вхождений ключевых слов (хитов) для каждого запроса. Установка лимита в 0 отключает оптимизатор.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
subtree_hits_cache = 16M
```
<!-- end -->

### threads

<!-- example threads -->
Количество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт это количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разделены на подзадачи и выполняться параллельно, например:

* Поиск в таблице реального времени
* Поиск в распределённой таблице, состоящей из локальных таблиц
* Вызов перколяционного запроса
* и другие

По умолчанию значение равно количеству ядер ЦП на сервере. Manticore создаёт потоки при запуске и сохраняет их до остановки. Каждая подзадача может использовать один из потоков, когда он ей нужен. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.

В случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше, чем количество ядер ЦП.

<!-- request Example -->
```ini
threads = 10
```

<!-- end -->

### thread_stack

<!-- example conf thread_stack -->
Максимальный размер стека для задачи (корутины, один поисковый запрос может вызвать несколько задач/корутин). Необязательный параметр, по умолчанию 128K.

Каждая задача имеет свой собственный стек размером 128K. При выполнении запроса проверяется, сколько стека ему требуется. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этой настройкой.

Установка значения на достаточно высоком уровне поможет обрабатывать очень глубокие запросы, не подразумевая, что общее потребление оперативной памяти вырастет слишком сильно. Например, установка значения в 1G не означает, что каждая новая задача будет занимать 1G оперативной памяти, но если мы видим, что ей требуется, скажем, 100M стека, мы просто выделяем 100M для задачи. Другие задачи в то же время будут выполняться со своим стандартным стеком в 128K. Таким же образом мы можем выполнять даже более сложные запросы, которым требуется 500M. И только если мы **увидим** внутренне, что задаче требуется более 1G стека, мы завершим её с ошибкой и сообщим о слишком низком значении `thread_stack`.

Однако на практике даже запрос, которому требуется 16M стека, часто оказывается слишком сложным для разбора и потребляет слишком много времени и ресурсов для обработки. Таким образом, демон обработает его, но ограничение таких запросов настройкой `thread_stack` выглядит вполне разумным.


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
thread_stack = 8M
```
<!-- end -->


### unlink_old

<!-- example conf unlink_old -->
Определяет, удалять ли копии таблиц `.old` при успешной ротации. Необязательный параметр, значение по умолчанию — 1 (удалять).


<!-- intro -->
##### Пример:

<!-- request Example -->

```ini
unlink_old = 0
```
<!-- end -->


### watchdog

<!-- example conf watchdog -->
Наблюдатель за потоковым сервером. Необязательный параметр, значение по умолчанию — 1 (наблюдатель включен).

Когда запрос Manticore завершается аварийно, он может привести к падению всего сервера. При включенной функции наблюдателя `searchd` также поддерживает отдельный легковесный процесс, который отслеживает основной процесс сервера и автоматически перезапускает его в случае аномального завершения.

<!-- request Example -->

```ini
watchdog = 0 # disable watchdog
```
<!-- end -->
<!-- proofread -->
