Ниже приведены настройки, которые используются в разделе searchd файла конфигурации Manticore Search для управления поведением сервера. Ниже приведено краткое описание каждой настройки:
Эта настройка задает значения по умолчанию для всего экземпляра для access_plain_attrs. Она является необязательной, значение по умолчанию — mmap_preread.
Директива access_plain_attrs позволяет определить значение по умолчанию для access_plain_attrs для всех таблиц, управляемых этим экземпляром searchd. Директивы для отдельных таблиц имеют более высокий приоритет и переопределяют это значение по умолчанию, обеспечивая более тонкий контроль.
Эта настройка задает значения по умолчанию для всего экземпляра для access_blob_attrs. Она является необязательной, значение по умолчанию — mmap_preread.
Директива access_blob_attrs позволяет определить значение по умолчанию для access_blob_attrs для всех таблиц, управляемых этим экземпляром searchd. Директивы для отдельных таблиц имеют более высокий приоритет и переопределяют это значение по умолчанию, обеспечивая более тонкий контроль.
Эта настройка задает значения по умолчанию для всего экземпляра для access_doclists. Она является необязательной, значение по умолчанию — file.
Директива access_doclists позволяет определить значение по умолчанию для access_doclists для всех таблиц, управляемых этим экземпляром searchd. Директивы для отдельных таблиц имеют более высокий приоритет и переопределяют это значение по умолчанию, обеспечивая более тонкий контроль.
Эта настройка задает значения по умолчанию для всего экземпляра для access_hitlists. Она является необязательной, значение по умолчанию — file.
Директива access_hitlists позволяет определить значение по умолчанию для access_hitlists для всех таблиц, управляемых этим экземпляром searchd. Директивы для отдельных таблиц имеют более высокий приоритет и переопределяют это значение по умолчанию, обеспечивая более тонкий контроль.
Эта настройка задает значения по умолчанию для всего экземпляра для access_dict. Она является необязательной, значение по умолчанию — mmap_preread.
Директива access_dict позволяет определить значение по умолчанию для access_dict для всех таблиц, управляемых этим экземпляром searchd. Директивы для отдельных таблиц имеют более высокий приоритет и переопределяют это значение по умолчанию, обеспечивая более тонкий контроль.
Эта настройка задает значения по умолчанию для всего экземпляра для параметра agent_connect_timeout.
Эта настройка задает значения по умолчанию для всего экземпляра для параметра agent_query_timeout. Она может быть переопределена для каждого запроса с помощью клаузы OPTION agent_query_timeout=XXX.
Эта настройка — целое число, которое указывает, сколько раз Manticore попытается подключиться и выполнить запрос к удалённым агентам через распределённую таблицу, прежде чем сообщить о фатальной ошибке запроса. Значение по умолчанию — 0 (т.е. без повторных попыток). Вы также можете задать это значение для каждого запроса с помощью клаузы OPTION retry_count=XXX. Если задана опция для конкретного запроса, она переопределит значение, указанное в конфигурации.
Обратите внимание, что если вы используете agent mirrors в определении вашей распределённой таблицы, сервер будет выбирать другой зеркальный агент для каждой попытки подключения в соответствии с выбранной стратегией ha_strategy. В этом случае agent_retry_count будет суммироваться для всех зеркал в наборе.
Например, если у вас 10 зеркал и установлено agent_retry_count=5, сервер будет пытаться до 50 раз, предполагая в среднем 5 попыток для каждого из 10 зеркал (при опции ha_strategy = roundrobin это будет так).
Однако значение, указанное в опции retry_count для агента, служит абсолютным лимитом. Другими словами, опция [retry_count=2] в определении агента всегда означает максимум 2 попытки, независимо от того, указали ли вы 1 или 10 зеркал для агента.
Эта настройка — целое число в миллисекундах (или special_suffixes), которое задает задержку перед повторной попыткой запроса к удалённому агенту в случае сбоя. Это значение актуально только при ненулевом agent_retry_count или ненулевом значении retry_count для конкретного запроса. Значение по умолчанию — 500. Вы также можете задать это значение для каждого запроса с помощью клаузы OPTION retry_delay=XXX. Если задана опция для конкретного запроса, она переопределит значение, указанное в конфигурации.
При использовании Update для изменения атрибутов документа в реальном времени, изменения сначала записываются в копию атрибутов в памяти. Эти обновления происходят в файле с отображением в память, что означает, что ОС решает, когда записывать изменения на диск. При нормальном завершении работы searchd (инициируемом сигналом SIGTERM) все изменения принудительно записываются на диск.
Вы также можете указать searchd периодически записывать эти изменения на диск, чтобы предотвратить потерю данных. Интервал между этими сбросами определяется параметром attr_flush_period, указанным в секундах (или special_suffixes).
По умолчанию значение равно 0, что отключает периодический сброс. Однако сброс все равно происходит при нормальном завершении работы.
- Example
attr_flush_period = 900 # persist updates to disk every 15 minutesЭтот параметр управляет автоматическим процессом OPTIMIZE для сжатия таблицы.
По умолчанию сжатие таблицы происходит автоматически. Вы можете изменить это поведение с помощью параметра auto_optimize:
- 0 — отключить автоматическое сжатие таблицы (вы все еще можете вызвать
OPTIMIZEвручную) - 1 — явно включить его
- включить с умножением порога оптимизации на 2.
По умолчанию OPTIMIZE выполняется до тех пор, пока количество дисковых чанков не станет меньше или равно количеству логических ядер CPU, умноженному на 2.
Однако, если в таблице есть атрибуты с KNN индексами, этот порог отличается. В этом случае он устанавливается равным количеству физических ядер CPU, деленному на 2, для улучшения производительности KNN поиска.
Обратите внимание, что переключение auto_optimize в положение вкл/выкл не мешает вам запускать OPTIMIZE TABLE вручную.
- Disable
- Throttle
auto_optimize = 0 # disable automatic OPTIMIZEauto_optimize = 2 # OPTIMIZE starts at 16 chunks (on 4 cpu cores server)Manticore поддерживает автоматическое создание таблиц, которые еще не существуют, но указаны в операторах INSERT. Эта функция включена по умолчанию. Чтобы отключить её, явно установите auto_schema = 0 в вашей конфигурации. Чтобы снова включить, установите auto_schema = 1 или удалите параметр auto_schema из конфигурации.
Имейте в виду, что HTTP-эндпоинт /bulk не поддерживает автоматическое создание таблиц.
ПРИМЕЧАНИЕ: Функциональность авто-схемы требует Manticore Buddy. Если она не работает, убедитесь, что Buddy установлен.
- Disable
- Enable
auto_schema = 0 # disable automatic table creationauto_schema = 1 # enable automatic table creationЭтот параметр управляет режимом сброса/синхронизации транзакций бинарного лога. Он необязателен, значение по умолчанию — 2 (сброс каждой транзакции, синхронизация каждую секунду).
Директива определяет, как часто бинарный лог будет сбрасываться в ОС и синхронизироваться на диск. Поддерживаются три режима:
- 0 — сброс и синхронизация каждую секунду. Это обеспечивает лучшую производительность, но при сбое сервера или ОС/аппаратном сбое можно потерять до 1 секунды подтвержденных транзакций.
- 1 — сброс и синхронизация каждой транзакции. Этот режим обеспечивает худшую производительность, но гарантирует сохранение данных каждой подтвержденной транзакции.
- 2 — сброс каждой транзакции, синхронизация каждую секунду. Этот режим обеспечивает хорошую производительность и гарантирует сохранение каждой подтвержденной транзакции при сбое сервера. Однако при сбое ОС/аппаратном сбое можно потерять до 1 секунды подтвержденных транзакций.
Для тех, кто знаком с MySQL и InnoDB, эта директива похожа на innodb_flush_log_at_trx_commit. В большинстве случаев режим 2 по умолчанию обеспечивает хороший баланс скорости и безопасности, с полной защитой данных RT таблиц от сбоев сервера и частичной защитой от аппаратных сбоев.
- Example
binlog_flush = 1 # ultimate safety, low speedЭтот параметр управляет тем, как управляются файлы бинарного лога. Он необязателен, значение по умолчанию — 0 (отдельный файл для каждой таблицы).
Вы можете выбрать один из двух способов управления файлами бинарного лога:
- Отдельный файл для каждой таблицы (по умолчанию,
0): каждая таблица сохраняет свои изменения в собственном лог-файле. Эта настройка хороша, если у вас много таблиц, которые обновляются в разное время. Это позволяет обновлять таблицы без ожидания других. Также, если возникает проблема с лог-файлом одной таблицы, это не влияет на другие. - Один файл для всех таблиц (
1): все таблицы используют один и тот же файл бинарного лога. Этот метод упрощает управление файлами, так как их меньше. Однако это может привести к тому, что файлы будут храниться дольше, если одна таблица все еще должна сохранить свои обновления. Эта настройка также может замедлить работу, если много таблиц нужно обновить одновременно, так как все изменения должны ждать записи в один файл.
- Example
binlog_common = 1 # use a single binary log file for all tablesЭтот параметр управляет максимальным размером файла бинарного лога. Он необязателен, значение по умолчанию — 256 МБ.
Новый файл binlog будет принудительно открыт, как только текущий файл достигнет этого предела размера. Это приводит к более мелкой гранулярности логов и может привести к более эффективному использованию диска binlog при определенных пограничных нагрузках. Значение 0 означает, что файл binlog не должен переоткрываться по размеру.
- Example
binlog_max_log_size = 16MЭтот параметр определяет путь для файлов бинарного лога (также известного как журнал транзакций). Он необязателен, значение по умолчанию — каталог данных, настроенный во время сборки (например, /var/lib/manticore/data/binlog.* в Linux).
Двоичные логи используются для восстановления данных таблицы RT после сбоев и для обновления атрибутов простых дисковых индексов, которые в противном случае хранились бы только в ОЗУ до сброса. Когда ведение логов включено, каждая транзакция, зафиксированная (COMMIT) в таблице RT, записывается в файл журнала. Логи затем автоматически воспроизводятся при запуске после некорректного завершения работы, восстанавливая записанные изменения.
Директива binlog_path указывает расположение файлов двоичных логов. Она должна содержать только путь; searchd будет создавать и удалять несколько файлов binlog.* в каталоге по мере необходимости (включая данные binlog, метаданные и файлы блокировок и т.д.).
Пустое значение отключает двоичное логирование, что улучшает производительность, но подвергает данные таблицы RT риску.
- Example
binlog_path = # disable logging
binlog_path = /var/lib/manticore/data # /var/lib/manticore/data/binlog.001 etc will be createdЭтот параметр управляет значением по умолчанию для опции поиска boolean_simplify. Он необязателен, значение по умолчанию — 1 (включено).
При установке в 1 сервер автоматически применит оптимизацию булевых запросов для улучшения производительности запросов. При установке в 0 запросы будут выполняться без оптимизации по умолчанию. Это значение по умолчанию можно переопределить для каждого запроса с помощью соответствующей опции поиска boolean_simplify.
- Example
searchd {
boolean_simplify = 0 # disable boolean optimization by default
}Этот параметр определяет путь к бинарному файлу 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 с /usr/bin/php.
Чтобы отключить Manticore Buddy, установите значение в пустое, как показано в примере.
- Example
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Этот параметр определяет максимальное время ожидания между запросами (в секундах или с использованием special_suffixes) при использовании постоянных соединений. Он необязателен, значение по умолчанию — пять минут.
- Example
client_timeout = 1hЛокаль libc сервера. Необязательный параметр, по умолчанию C.
Определяет локаль libc, влияющую на сортировки, основанные на libc. Подробнее см. в разделе collations.
- Example
collation_libc_locale = fr_FRСортировка сервера по умолчанию. Необязательный параметр, по умолчанию libc_ci.
Определяет сортировку по умолчанию, используемую для входящих запросов. Сортировку можно переопределить для каждого запроса. Список доступных сортировок и другие детали см. в разделе collations.
- Example
collation_server = utf8_ciПри указании этот параметр включает режим реального времени, который является императивным способом управления схемой данных. Значение должно быть путем к каталогу, в котором вы хотите хранить все ваши таблицы, двоичные логи и все остальное, необходимое для корректной работы Manticore Search в этом режиме.
Индексация простых таблиц не разрешена при указании data_dir. Подробнее о различиях между режимом RT и простым режимом читайте в этом разделе.
- Example
data_dir = /var/lib/manticoreТаймаут для предотвращения автоматического сброса RAM-чанка, если в таблице нет поисковых запросов. Необязательный параметр, по умолчанию 30 секунд.
Время проверки наличия поисков перед решением о необходимости автоматического сброса.
Автоматический сброс произойдет только если в таблице был хотя бы один поиск за последние diskchunk_flush_search_timeout секунд. Работает совместно с diskchunk_flush_write_timeout. Соответствующая настройка на уровне таблицы имеет более высокий приоритет и переопределит это значение по умолчанию, обеспечивая более тонкий контроль.
- Example
diskchunk_flush_search_timeout = 120sВремя в секундах ожидания без записи перед автоматическим сбросом RAM-чанка на диск. Необязательный параметр, по умолчанию 1 секунда.
Если в течение diskchunk_flush_write_timeout секунд в RAM-чанк не происходит запись, чанк будет сброшен на диск. Работает совместно с diskchunk_flush_search_timeout. Чтобы отключить авто-сброс, явно установите diskchunk_flush_write_timeout = -1 в вашей конфигурации. Соответствующая настройка для каждой таблицы имеет более высокий приоритет и переопределит это значение по умолчанию для всего экземпляра, обеспечивая более тонкий контроль.
- Example
diskchunk_flush_write_timeout = 60sЭта настройка задает максимальный размер блоков документов из хранилища документов, которые удерживаются в памяти. Опционально, значение по умолчанию — 16m (16 мегабайт).
Когда используется stored_fields, блоки документов читаются с диска и распаковываются. Поскольку каждый блок обычно содержит несколько документов, он может быть повторно использован при обработке следующего документа. Для этой цели блок удерживается в кэше на уровне сервера. Кэш хранит распакованные блоки.
- Example
docstore_cache_size = 8mДвижок хранения атрибутов по умолчанию, используемый при создании таблиц в режиме RT. Может быть rowwise (по умолчанию) или columnar.
- Example
engine = columnarЭта настройка определяет максимальное количество расширенных ключевых слов для одного подстановочного знака. Опционально, значение по умолчанию — 0 (без ограничений).
При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов (например, сопоставление a* со всем словарем Оксфорда). Эта директива позволяет ограничить влияние таких расширений. Установка expansion_limit = N ограничивает расширения не более чем N наиболее частыми совпадающими ключевыми словами (для каждого подстановочного знака в запросе).
- Example
expansion_limit = 16Эта настройка определяет максимальное количество документов в расширенном ключевом слове, при котором возможно объединение всех таких ключевых слов вместе. Опционально, значение по умолчанию — 32.
При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит количества ключевых слов, которые будут объединены для ускорения сопоставления, но при этом используется больше памяти в поиске.
- Example
expansion_merge_threshold_docs = 1024Эта настройка определяет максимальное количество попаданий в расширенном ключевом слове, при котором возможно объединение всех таких ключевых слов вместе. Опционально, значение по умолчанию — 256.
При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит количества ключевых слов, которые будут объединены для ускорения сопоставления, но при этом используется больше памяти в поиске.
- Example
expansion_merge_threshold_hits = 512Эта настройка контролирует максимальное количество альтернативных вариантов фраз, сгенерированных из-за операторов OR внутри операторов PHRASE, PROXIMITY и QUORUM. Опционально, значение по умолчанию — 1024.
При использовании оператора | (OR) внутри операторов, похожих на фразы, общее количество расширенных комбинаций может расти экспоненциально в зависимости от количества указанных альтернатив. Эта настройка помогает предотвратить чрезмерное расширение запроса, ограничивая количество перестановок, рассматриваемых при обработке запроса.
Если количество сгенерированных вариантов превышает этот лимит, запрос либо:
- завершится с ошибкой (поведение по умолчанию)
- вернет частичные результаты с предупреждением, если включен
expansion_phrase_warning
- Example
expansion_phrase_limit = 4096Эта настройка контролирует поведение при превышении лимита расширения запроса, определенного expansion_phrase_limit.
По умолчанию запрос завершится с сообщением об ошибке. При установке expansion_phrase_warning в 1 поиск продолжается с использованием частичной трансформации фразы (до настроенного лимита), и сервер возвращает пользователю предупреждающее сообщение вместе с результатами. Это позволяет запросам, слишком сложным для полного расширения, возвращать частичные результаты без полного сбоя.
- Example
expansion_phrase_warning = 1Эта настройка определяет, будет ли группировка по времени в API и SQL рассчитываться в локальном часовом поясе или в UTC. Опционально, значение по умолчанию — 0 (означает «локальный часовой пояс»).
По умолчанию все выражения 'group by time' (например, group by day, week, month и year в API, а также group by day, month, year, 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 в SQL) приведёт к тому, что все выражения группировки времени будут вычисляться в UTC, при этом остальные функции, зависящие от времени (например, логирование сервера), останутся в локальном часовом поясе.
Этот параметр задаёт часовой пояс, который будет использоваться функциями, связанными с датой и временем. По умолчанию используется локальный часовой пояс, но вы можете указать другой часовой пояс в формате IANA (например, Europe/Amsterdam).
Обратите внимание, что этот параметр не влияет на логирование, которое всегда работает в локальном часовом поясе.
Также обратите внимание, что если используется grouping_in_utc, функция 'group by time' всё равно будет использовать UTC, в то время как другие функции, связанные с датой и временем, будут использовать указанный часовой пояс. В целом не рекомендуется смешивать grouping_in_utc и timezone.
Вы можете настроить эту опцию либо в конфиге, либо с помощью оператора SET global в SQL.
Этот параметр задаёт размер окна статистики зеркал агентов в секундах (или с использованием special_suffixes). Он необязателен, значение по умолчанию — 60 секунд.
Для распределённой таблицы с зеркалами агентов (подробнее см. в agent) мастер отслеживает несколько различных счётчиков для каждого зеркала. Эти счётчики затем используются для переключения и балансировки (мастер выбирает лучшее зеркало на основе счётчиков). Счётчики накапливаются блоками по ha_period_karma секунд.
После начала нового блока мастер может продолжать использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. В результате, любая предыдущая история перестаёт влиять на выбор зеркала максимум через 1.5 раза ha_period_karma секунд.
Хотя для выбора зеркала используется максимум два блока, до 15 последних блоков сохраняются для целей инструментирования. Эти блоки можно просмотреть с помощью оператора SHOW AGENT STATUS.
- Example
ha_period_karma = 2mЭтот параметр задаёт интервал между пингами зеркал агентов в миллисекундах (или с использованием special_suffixes). Он необязателен, значение по умолчанию — 1000 миллисекунд.
Для распределённой таблицы с зеркалами агентов (подробнее см. в agent) мастер отправляет всем зеркалам команду пинга в периоды простоя. Это необходимо для отслеживания текущего статуса агента (жив или мёртв, время сетевого отклика и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите ha_ping_interval в 0.
- Example
ha_ping_interval = 3sОпция hostname_lookup определяет стратегию обновления имён хостов. По умолчанию IP-адреса имён хостов агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к DNS. Однако в некоторых случаях IP может динамически меняться (например, в облачном хостинге), и может быть желательно не кэшировать IP. Установка этой опции в значение request отключает кэширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновить вручную с помощью команды FLUSH HOSTNAMES.
Параметр jobs_queue_size определяет, сколько "заданий" может находиться в очереди одновременно. По умолчанию ограничений нет.
В большинстве случаев "задание" означает один запрос к одной локальной таблице (обычной таблице или дисковому чанку таблицы реального времени). Например, если у вас есть распределённая таблица, состоящая из 2 локальных таблиц, или таблица реального времени с 2 дисковыми чанками, поисковый запрос к любой из них обычно создаст 2 задания в очереди. Затем пул потоков (размер которого задаётся параметром threads) обрабатывает их. Однако в некоторых случаях, если запрос слишком сложный, может создаваться больше заданий. Рекомендуется изменять этот параметр, когда max_connections и threads недостаточны для достижения баланса между желаемой производительностью.
Объединения таблиц работают путём накопления партии совпадений, которые являются результатами запроса, выполненного по левой таблице. Эта партия затем обрабатывается как единый запрос к правой таблице.
Эта опция позволяет настроить размер партии. Значение по умолчанию — 1000, установка этого параметра в 0 отключает пакетную обработку.
Больший размер партии может улучшить производительность; однако для некоторых запросов это может привести к чрезмерному потреблению памяти.
join_batch_size = 2000Каждый запрос, выполняемый по правой таблице, определяется конкретными условиями JOIN ON, которые определяют набор результатов, извлекаемых из правой таблицы.
Если существует всего несколько уникальных условий JOIN ON, повторное использование результатов может быть более эффективным, чем многократное выполнение запросов к правой таблице. Для этого наборы результатов сохраняются в кэше.
Этот параметр позволяет настроить размер этого кэша. Значение по умолчанию — 20 MB, а установка этого параметра в 0 отключает кэширование.
Обратите внимание, что каждый поток поддерживает свой собственный кэш, поэтому при оценке общего использования памяти следует учитывать количество потоков, выполняющих запросы.
join_cache_size = 10MПараметр listen_backlog определяет длину очереди TCP listen backlog для входящих соединений. Это особенно актуально для сборок под Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает предела, новые входящие соединения будут отклоняться. Для сборок не под Windows значение по умолчанию обычно подходит, и обычно нет необходимости настраивать этот параметр.
- Example
listen_backlog = 20Строка версии сервера, возвращаемая Kibana или OpenSearch Dashboards. Необязательно — по умолчанию установлено 7.6.0.
Некоторые версии Kibana и OpenSearch Dashboards ожидают, что сервер будет сообщать конкретный номер версии, и могут вести себя по-разному в зависимости от него. Чтобы обойти такие проблемы, вы можете использовать этот параметр, который заставляет Manticore сообщать Kibana или OpenSearch Dashboards пользовательскую версию.
- Example
kibana_version_string = 1.2.3Этот параметр позволяет указать IP-адрес и порт или путь к Unix-доменному сокету, на которых Manticore будет принимать соединения.
Общий синтаксис для listen:
listen = ( address ":" port | port | path | address ":" port start - port end ) [ ":" protocol [ "_vip" ] [ "_readonly" ] ]Вы можете указать:
- либо IP-адрес (или имя хоста) и номер порта
- либо только номер порта
- либо путь к Unix-сокету (не поддерживается в Windows)
- либо IP-адрес и диапазон портов
Если вы указываете номер порта, но не адрес, searchd будет слушать на всех сетевых интерфейсах. Путь Unix определяется ведущим слэшем. Диапазон портов можно задать только для протокола репликации.
Вы также можете указать обработчик протокола (listener), который будет использоваться для соединений на этом сокете. Слушатели:
- Не указан — Manticore будет принимать соединения на этом порту от:
- других агентов Manticore (например, удалённой распределённой таблицы)
- клиентов через HTTP и HTTPS
- Manticore Buddy. Убедитесь, что у вас есть слушатель такого типа (или
httpслушатель, как указано ниже), чтобы избежать ограничений в функциональности Manticore.
mysql— протокол MySQL для соединений от клиентов MySQL. Обратите внимание:- Поддерживается также сжатый протокол.
- Если включён SSL, можно установить зашифрованное соединение.
replication— протокол репликации, используемый для связи узлов. Подробнее см. в разделе репликация. Можно указать несколько слушателей репликации, но они все должны слушать на одном IP; различаться могут только порты. При определении слушателя репликации с диапазоном портов (например,listen = 192.168.0.1:9320-9328:replication) Manticore не начинает слушать эти порты сразу. Вместо этого он будет брать случайные свободные порты из указанного диапазона только при начале использования репликации. Для корректной работы репликации в диапазоне должно быть не менее 2 портов.http— то же, что и Не указан. Manticore будет принимать соединения на этом порту от удалённых агентов и клиентов через HTTP и HTTPS.https— протокол HTTPS. Manticore будет принимать только HTTPS-соединения на этом порту. Подробнее см. в разделе SSL.sphinx— устаревший бинарный протокол. Используется для обслуживания соединений от удалённых клиентов SphinxSE. Некоторые реализации клиентов Sphinx API (например, Java) требуют явного указания слушателя.
Добавление суффикса _vip к протоколам клиентов (то есть ко всем, кроме replication, например mysql_vip или http_vip или просто _vip) заставляет создавать выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае сильной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.
Суффикс _readonly устанавливает режим только для чтения для слушателя и ограничивает его приём только запросами на чтение.
- Example
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Может быть несколько директив listen. searchd будет слушать клиентские соединения на всех указанных портах и сокетах. Конфигурация по умолчанию, поставляемая в пакетах Manticore, определяет прослушивание на портах:
9308и9312для соединений от удалённых агентов и клиентов, не основанных на MySQL- и на порту
9306для MySQL-соединений.
Если вы вообще не укажете listen в конфигурации, Manticore будет ждать соединений на:
127.0.0.1:9306для клиентов MySQL127.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).
This setting allows the TCP_FASTOPEN flag for all listeners. By default, it is managed by the system but may be explicitly switched off by setting it to '0'.
For general knowledge about the TCP Fast Open extension, please consult with Wikipedia. In short, it allows the elimination of one TCP round-trip when establishing a connection.
In practice, using TFO in many situations may optimize client-agent network efficiency, as if persistent agents are in play, but without holding active connections, and also without limitation for the maximum num of connections.
On modern OS, TFO support is usually switched 'on' at the system level, but this is just a 'capability', not the rule. Linux (as the most progressive) has supported it since 2011, on kernels starting from 3.7 (for the server-side). Windows has supported it from some builds of Windows 10. Other operating systems (FreeBSD, MacOS) are also in the game.
For Linux system server checks variable /proc/sys/net/ipv4/tcp_fastopen and behaves according to it. Bit 0 manages client side, bit 1 rules listeners. By default, the system has this parameter set to 1, i.e., clients enabled, listeners disabled.
The log setting specifies the name of the log file where all searchd run time events will be logged. If not specified, the default name is 'searchd.log'.
Alternatively, you can use the 'syslog' as the file name. In this case, the events will be sent to the syslog daemon. To use the syslog option, you need to configure Manticore with the -–with-syslog option during building.
- Example
log = /var/log/searchd.logОграничивает количество запросов в одном пакете. Необязательно, по умолчанию 32.
Заставляет searchd выполнять проверку разумности количества запросов, отправленных в одном пакете при использовании мультизапросов. Установите в 0, чтобы пропустить проверку.
- Example
max_batch_queries = 256Максимальное количество одновременных клиентских подключений. По умолчанию неограничено. Обычно это заметно только при использовании любых видов постоянных подключений, таких как cli mysql сессии или постоянные удалённые подключения из удалённых распределённых таблиц. При превышении лимита вы всё ещё можете подключиться к серверу, используя VIP-подключение. VIP-подключения не учитываются в лимит.
- Example
max_connections = 10Глобальное ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра CPU, не оставляя места для других операций. Например, call pq к достаточно большой таблице percolate может использовать все потоки в течение десятков секунд. Установка max_threads_per_query в, скажем, половину от значения threads обеспечит возможность запуска нескольких таких операций call pq параллельно.
Вы также можете установить этот параметр как переменную сессии или глобальную переменную во время выполнения.
Кроме того, вы можете управлять поведением для каждого запроса с помощью опции threads OPTION.
- Example
max_threads_per_query = 4Максимально допустимое количество фильтров на запрос. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 256.
- Example
max_filters = 1024Максимально допустимое количество значений в фильтре. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 4096.
- Example
max_filter_values = 16384Максимальное количество файлов, которые сервер может открыть, называется "мягким лимитом". Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может требовать установки этого лимита на высоком уровне, так как каждый диск-чанк может занимать десятки и более файлов. Например, таблица реального времени с 1000 чанков может требовать открытия тысяч файлов одновременно. Если в логах появляется ошибка 'Too many open files', попробуйте изменить этот параметр, это может помочь решить проблему.
Существует также "жёсткий лимит", который нельзя превысить с помощью этой опции. Этот лимит определяется системой и может быть изменён в файле /etc/security/limits.conf на Linux. Другие операционные системы могут иметь другие подходы, поэтому обратитесь к документации для получения дополнительной информации.
- Example
max_open_files = 10000Помимо прямых числовых значений, вы можете использовать магическое слово 'max', чтобы установить лимит равным текущему доступному жёсткому лимиту.
- Example
max_open_files = maxМаксимально допустимый размер сетевого пакета. Этот параметр ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удалённых агентов в распределённой среде. Используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 128M.
- Example
max_packet_size = 32MСтрока версии сервера, возвращаемая через протокол 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. (По умолчанию он сообщает свою собственную версию.)
- Example
mysql_version_string = 5.0.37Количество сетевых потоков, по умолчанию 1.
Этот параметр полезен при чрезвычайно высоких скоростях запросов, когда одного потока недостаточно для обработки всех входящих запросов.
Управляет интервалом busy loop сетевого потока. По умолчанию -1, может быть установлен в -1, 0 или положительное целое число.
В случаях, когда сервер настроен как чистый мастер и просто маршрутизирует запросы к агентам, важно обрабатывать запросы без задержек и не допускать, чтобы сетевой поток засыпал. Для этого существует busy loop. После входящего запроса сетевой поток использует CPU poll в течение 10 * net_wait_tm миллисекунд, если net_wait_tm положительное число, или опрашивает только с помощью CPU, если net_wait_tm равен 0. Также busy loop можно отключить с помощью net_wait_tm = -1 — в этом случае poller устанавливает таймауты, соответствующие фактическим таймаутам агента в системном вызове опроса.
ВНИМАНИЕ: Busy loop загружает ядро CPU, поэтому установка этого значения в любое не стандартное значение приведет к заметному использованию CPU даже при простое сервера.
Определяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для контроля пропускной способности сетевого цикла в условиях высокой нагрузки.
Определяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для контроля пропускной способности сетевого цикла в условиях высокой нагрузки.
Таймаут чтения/записи запроса клиента сети, в секундах (или с использованием special_suffixes). Необязательно, по умолчанию 5 секунд. searchd принудительно закроет соединение клиента, если тот не отправит запрос или не прочитает результат в течение этого таймаута.
Обратите внимание также на параметр reset_network_timeout_on_packet. Этот параметр изменяет поведение network_timeout с применения к всему query или result на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объем данных, этот параметр может быть незаменим для поддержания активных операций.
- Example
network_timeout = 10sЭтот параметр позволяет указать сетевой адрес узла. По умолчанию он установлен в адрес репликации listen. Это правильно в большинстве случаев; однако бывают ситуации, когда его нужно указать вручную:
- Узел за файрволом
- Включен сетевой транслятор адресов (NAT)
- Развертывания в контейнерах, таких как Docker или облачные развертывания
- Кластеры с узлами в более чем одном регионе
- Example
node_address = 10.101.0.10Этот параметр определяет, разрешать ли запросы, содержащие только оператор отрицания полнотекстового поиска. Необязательно, по умолчанию 0 (запросы с только оператором NOT считаются ошибочными).
- Example
not_terms_only_allowed = 1Устанавливает порог сжатия таблицы по умолчанию. Подробнее здесь — Number of optimized disk chunks. Этот параметр можно переопределить с помощью опции на запрос cutoff. Также его можно динамически изменить через SET GLOBAL.
- Example
optimize_cutoff = 4Этот параметр определяет максимальное количество одновременных постоянных соединений с удалёнными persistent agents. Каждый раз, когда агент, определённый в agent_persistent, подключается, мы пытаемся повторно использовать существующее соединение (если оно есть) или подключиться и сохранить соединение для будущего использования. Однако в некоторых случаях имеет смысл ограничить количество таких постоянных соединений. Эта директива задаёт лимит. Она влияет на количество соединений с хостом каждого агента во всех распределённых таблицах.
Рекомендуется установить значение равным или меньше опции max_connections в конфиге агента.
- Example
persistent_connections_limit = 29 # assume that each host of agents has max_connections = 30 (or 29).pid_file — обязательный параметр конфигурации в Manticore search, который указывает путь к файлу, где хранится идентификатор процесса сервера searchd.
Файл с идентификатором процесса searchd пересоздаётся и блокируется при запуске, и содержит идентификатор главного процесса сервера, пока сервер работает. При остановке сервера файл удаляется.
Назначение этого файла — позволить Manticore выполнять различные внутренние задачи, такие как проверка, запущен ли уже экземпляр searchd, остановка searchd и уведомление о необходимости ротации таблиц. Файл также может использоваться внешними скриптами автоматизации.
- Example
pid_file = /run/manticore/searchd.pidЗатраты для модели предсказания времени выполнения запроса, в наносекундах. Необязательно, по умолчанию doc=64, hit=48, skip=2048, match=64.
- Example
predicted_time_costs = doc=128, hit=96, skip=4096, match=128Прерывание запросов до их завершения на основе времени выполнения (с помощью настройки максимального времени запроса) — это хорошая страховка, но она имеет свой недостаток: неопределённые (нестабильные) результаты. То есть, если повторить один и тот же (сложный) поисковый запрос с ограничением по времени несколько раз, ограничение времени будет достигаться на разных этапах, и вы получите разные наборы результатов.
- SQL
- API
SELECT … OPTION max_query_timeSetMaxQueryTime()Существует опция, SELECT … OPTION max_predicted_time, которая позволяет ограничить время выполнения запроса и получить стабильные, повторяемые результаты. Вместо того чтобы регулярно проверять текущее фактическое время во время выполнения запроса, что является неопределённым, она предсказывает текущее время выполнения с помощью простой линейной модели:
predicted_time =
doc_cost * processed_documents +
hit_cost * processed_hits +
skip_cost * skiplist_jumps +
match_cost * found_matchesЗапрос затем прерывается досрочно, когда predicted_time достигает заданного предела.
Конечно, это не жёсткое ограничение на фактическое затраченное время (однако это жёсткое ограничение на количество выполненной обработки), и простая линейная модель ни в коем случае не является идеально точной. Поэтому реальное время по часам может быть как ниже, так и выше целевого предела. Тем не менее, погрешности вполне приемлемы: например, в наших экспериментах с целевым лимитом 100 мс большинство тестовых запросов попадали в диапазон от 95 до 105 мс, и все запросы были в диапазоне от 80 до 120 мс. Также, в качестве приятного побочного эффекта, использование смоделированного времени запроса вместо измерения фактического времени выполнения приводит к некоторому уменьшению количества вызовов gettimeofday().
Нет двух одинаковых моделей и марок серверов, поэтому директива predicted_time_costs позволяет настроить затраты для вышеуказанной модели. Для удобства они заданы целыми числами, измеряемыми в наносекундах. (Лимит в max_predicted_time считается в миллисекундах, и указывать значения затрат как 0.000128 мс вместо 128 нс более подвержено ошибкам.) Не обязательно указывать все четыре значения затрат сразу, так как пропущенные будут иметь значения по умолчанию. Однако мы настоятельно рекомендуем указывать все для удобочитаемости.
Директива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки preopen для каждой таблицы. Если установлено в 0, то могут применяться настройки для каждой таблицы, которые по умолчанию равны 0.
Предварительное открытие таблиц может предотвратить гонки между поисковыми запросами и ротациями, которые могут иногда приводить к сбоям запросов. Однако это также использует больше дескрипторов файлов. В большинстве сценариев рекомендуется предварительно открывать таблицы.
Вот пример конфигурации:
- Example
preopen_tables = 1Опция конфигурации pseudo_sharding включает параллелизацию поисковых запросов к локальным plain и real-time таблицам, независимо от того, запрашиваются ли они напрямую или через распределённую таблицу. Эта функция автоматически параллелит запросы до количества потоков, указанного в searchd.threads # потоков.
Обратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:
- высокая конкуренция запросов
- физическое шардинг любого типа:
- распределённая таблица из нескольких plain/real-time таблиц
- real-time таблица, состоящая из слишком большого количества дисковых чанков
то включение pseudo_sharding может не дать никаких преимуществ и даже привести к небольшому снижению пропускной способности. Если вы отдаёте приоритет более высокой пропускной способности над меньшей задержкой, рекомендуется отключить эту опцию.
Включено по умолчанию.
- Example
pseudo_sharding = 0Директива replication_connect_timeout задаёт тайм-аут подключения к удалённому узлу. По умолчанию значение предполагается в миллисекундах, но может иметь другой суффикс. Значение по умолчанию — 1000 (1 секунда).
При подключении к удалённому узлу Manticore будет ждать не более этого времени для успешного завершения подключения. Если тайм-аут достигнут, но соединение не установлено, и включены retries, будет выполнена повторная попытка.
replication_query_timeout задаёт время, в течение которого searchd будет ждать завершения запроса от удалённого узла. Значение по умолчанию — 3000 миллисекунд (3 секунды), но может иметь суффикс для указания другой единицы времени.
После установления соединения Manticore будет ждать максимум replication_query_timeout для завершения удалённым узлом. Обратите внимание, что этот тайм-аут отличается от replication_connect_timeout, и общая возможная задержка, вызванная удалённым узлом, будет суммой обоих значений.
Этот параметр — целое число, указывающее, сколько раз Manticore попытается подключиться и выполнить запрос к удалённому узлу во время репликации, прежде чем сообщить о фатальной ошибке запроса. Значение по умолчанию — 3.
Этот параметр — целое число в миллисекундах (или special_suffixes), задающее задержку перед повторной попыткой запроса к удалённому узлу в случае сбоя во время репликации. Это значение актуально только при ненулевом значении. Значение по умолчанию — 500.
Эта конфигурация задаёт максимальный объём оперативной памяти, выделяемой для кэшированных наборов результатов в байтах. Значение по умолчанию — 16777216, что эквивалентно 16 мегабайтам. Если значение установлено в 0, кэш запросов отключается. Для получения дополнительной информации о кэше запросов смотрите query cache.
- Example
qcache_max_bytes = 16777216Целое число в миллисекундах. Минимальный порог времени выполнения запроса, при котором результат будет кэшироваться. По умолчанию 3000, или 3 секунды. 0 означает кэшировать всё. Подробнее см. query cache. Это значение также может быть выражено с помощью временных special_suffixes, но используйте их с осторожностью и не путайте с названием самого параметра, содержащим '_msec'.
Целое число, в секундах. Период истечения срока действия для кэшированного набора результатов. По умолчанию 60, или 1 минута. Минимально возможное значение — 1 секунда. Подробности см. в разделе query cache. Это значение также может быть выражено с помощью временных special_suffixes, но используйте это с осторожностью и не путайте с названием самого значения, содержащим '_sec'.
Формат журнала запросов. Необязательно, допустимые значения — plain и sphinxql, по умолчанию sphinxql.
Режим sphinxql записывает действительные SQL-запросы. Режим plain записывает запросы в простом текстовом формате (в основном подходит для чисто полнотекстовых случаев использования). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также можно изменить на лету, используя синтаксис SET GLOBAL query_log_format=sphinxql. Подробности см. в разделе Query logging.
- Example
query_log_format = sphinxqlЛимит (в миллисекундах), который предотвращает запись запроса в журнал запросов. Необязательно, по умолчанию 0 (все запросы записываются в журнал запросов). Эта директива указывает, что в журнал будут записываться только запросы с временем выполнения, превышающим указанный лимит (это значение также может быть выражено с помощью временных special_suffixes, но используйте это с осторожностью и не путайте с названием самого значения, содержащим _msec).
Имя файла журнала запросов. Необязательно, по умолчанию пусто (не вести журнал запросов). Все поисковые запросы (например, SELECT ... но не INSERT/REPLACE/UPDATE запросы) будут записываться в этот файл. Формат описан в разделе Query logging. В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу журнала. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом LOG_INFO, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть собран с опцией -–with-syslog.
- Example
query_log = /var/log/query.logДиректива query_log_mode позволяет установить разные права доступа для файлов журнала searchd и журнала запросов. По умолчанию эти файлы журнала создаются с правами 600, что означает, что читать их могут только пользователь, под которым запущен сервер, и пользователи root. Эта директива может быть полезна, если вы хотите разрешить другим пользователям читать файлы журнала, например, решениям для мониторинга, работающим под не-root пользователями.
- Example
query_log_mode = 666Директива read_buffer_docs управляет размером буфера чтения на ключевое слово для списков документов. Для каждого вхождения ключевого слова в каждом поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Эта настройка позволяет контролировать размер буфера списка документов.
Больший размер буфера может увеличить использование ОЗУ на запрос, но возможно уменьшит время ввода-вывода. Имеет смысл устанавливать большие значения для медленных хранилищ, но для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.
Значение по умолчанию — 256K, минимальное значение — 8K. Вы также можете установить read_buffer_docs для каждой таблицы отдельно, что переопределит настройки на уровне сервера.
- Example
read_buffer_docs = 128KДиректива read_buffer_hits задает размер буфера чтения на ключевое слово для списков попаданий в поисковых запросах. По умолчанию размер 256K, минимальное значение 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Увеличение размера буфера может увеличить использование ОЗУ на запрос, но уменьшить время ввода-вывода. Для медленных хранилищ имеет смысл использовать большие размеры буфера, а для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.
Эта настройка также может быть задана для каждой таблицы отдельно с помощью опции read_buffer_hits в read_buffer_hits, что переопределит настройку на уровне сервера.
- Example
read_buffer_hits = 128KРазмер чтения без подсказок. Необязательно, по умолчанию 32K, минимальное 1K
При выполнении запросов некоторые чтения заранее точно знают, сколько данных нужно прочитать, а некоторые — нет. Наиболее заметно, что размер списка попаданий в настоящее время заранее не известен. Эта настройка позволяет контролировать, сколько данных читать в таких случаях. Она влияет на время ввода-вывода списка попаданий, уменьшая его для списков, больших, чем размер чтения без подсказок, но увеличивая для меньших списков. Она не влияет на использование ОЗУ, так как буфер чтения уже будет выделен. Поэтому она не должна быть больше, чем read_buffer.
- Example
read_unhinted = 32KУточняет поведение сетевых таймаутов (таких как 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.
- Example
reset_network_timeout_on_packet = 0Период проверки сброса чанков RAM RT-таблиц, в секундах (или special_suffixes). Необязательно, по умолчанию 10 часов.
Активно обновляемые RT-таблицы, полностью помещающиеся в чанки RAM, могут приводить к постоянно растущим бинлогам, что влияет на использование диска и время восстановления после сбоев. С помощью этой директивы поисковый сервер выполняет периодические проверки сброса, и подходящие чанки RAM могут быть сохранены, что позволяет последующую очистку бинлогов. Подробнее см. в разделе Binary logging.
- Example
rt_flush_period = 3600 # 1 hourМаксимальное количество операций ввода-вывода (в секунду), которые поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).
Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов OPTIMIZE. Гарантируется, что все операции оптимизации RT не будут генерировать больше дисковых IOPS (операций ввода-вывода в секунду), чем заданный лимит. Ограничение rt_merge_iops может уменьшить деградацию производительности поиска, вызванную слиянием.
- Example
rt_merge_iops = 40Максимальный размер операции ввода-вывода, которую поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).
Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов OPTIMIZE. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции в рамках лимита rt_merge_iops. Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.
- Example
rt_merge_maxiosize = 1MПредотвращает зависания searchd при ротации таблиц с огромным объемом данных для предварительного кэширования. Необязательно, по умолчанию 1 (включена бесшовная ротация). В системах Windows бесшовная ротация по умолчанию отключена.
Таблицы могут содержать данные, которые необходимо предварительно кэшировать в RAM. В настоящее время файлы .spa, .spb, .spi и .spm полностью предварительно кэшируются (они содержат данные атрибутов, данные блоб-атрибутов, таблицу ключевых слов и карту удаленных строк соответственно). Без бесшовной ротации ротация таблицы старается использовать как можно меньше RAM и работает следующим образом:
- Новые запросы временно отклоняются (с кодом ошибки "retry");
searchdожидает завершения всех текущих запросов;- Старая таблица освобождается, и ее файлы переименовываются;
- Файлы новой таблицы переименовываются, и выделяется необходимая RAM;
- Данные атрибутов и словаря новой таблицы предварительно загружаются в RAM;
searchdвозобновляет обслуживание запросов из новой таблицы.
Однако если данных атрибутов или словаря много, этап предварительной загрузки может занять заметное время — до нескольких минут при загрузке файлов размером 1-5+ ГБ.
При включенной бесшовной ротации ротация работает следующим образом:
- Выделяется RAM для хранения новой таблицы;
- Данные атрибутов и словаря новой таблицы асинхронно предварительно загружаются в RAM;
- При успешной загрузке старая таблица освобождается, и файлы обеих таблиц переименовываются;
- При неудаче новая таблица освобождается;
- В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.
Бесшовная ротация требует большего пикового использования памяти во время ротации (поскольку обе копии данных .spa/.spb/.spi/.spm — старая и новая — должны находиться в RAM во время предварительной загрузки новой копии). Среднее использование памяти остается прежним.
- Example
seamless_rotate = 1Этот параметр задает размер кэша блоков, используемого вторичными индексами. Необязательно, по умолчанию 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений. В объединенных запросах этот процесс повторяется для каждой партии строк из левой таблицы, и каждая партия может повторно читать одни и те же метаданные в рамках одного объединенного запроса. Это может значительно повлиять на производительность. Кэш метаданных блоков хранит эти блоки в памяти, чтобы они могли быть повторно использованы последующими партиями.
Кэш используется только в объединенных запросах и не влияет на не объединенные запросы. Обратите внимание, что ограничение размера кэша применяется на каждый атрибут и на каждый вторичный индекс. Каждый атрибут в каждом дисковом чанке работает в рамках этого ограничения. В худшем случае общее использование памяти можно оценить, умножив ограничение на количество дисковых чанков и количество атрибутов, используемых в объединенных запросах.
Установка secondary_index_block_cache = 0 отключает кэш.
- Example
secondary_index_block_cache = 16MThis option enables/disables the use of secondary indexes for search queries. It is optional, and the default is 1 (enabled). Note that you don't need to enable it for indexing as it is always enabled as long as the Manticore Columnar Library is installed. The latter is also required for using the indexes when searching. There are three modes available:
0: Disable the use of secondary indexes on search. They can be enabled for individual queries using analyzer hints1: Enable the use of secondary indexes on search. They can be disabled for individual queries using analyzer hintsforce: Same as enable, but any errors during the loading of secondary indexes will be reported, and the whole index will not be loaded into the daemon.
- Example
secondary_indexes = 1Integer number that serves as a server identifier used as a seed to generate a unique short UUID for nodes that are part of a replication cluster. The server_id must be unique across the nodes of a cluster and in the range from 0 to 127. If server_id is not set, it is calculated as a hash of the MAC address and the path to the PID file or a random number will be used as a seed for the short UUID.
- Example
server_id = 1searchd --stopwait waiting time, in seconds (or special_suffixes). Optional, default is 60 seconds.
When you run searchd --stopwait your server needs to perform some activities before stopping, such as finishing queries, flushing RT RAM chunks, flushing attributes, and updating the binlog. These tasks require some time. searchd --stopwait will wait up to shutdown_time seconds for the server to finish its jobs. The suitable time depends on your table size and load.
- Example
shutdown_timeout = 3m # wait for up to 3 minutesSHA1 hash of the password required to invoke the 'shutdown' command from a VIP Manticore SQL connection. Without it,debug 'shutdown' subcommand will never cause the server to stop. Note that such simple hashing should not be considered strong protection, as we don't use a salted hash or any kind of modern hash function. It is intended as a fool-proof measure for housekeeping daemons in a local network.
A prefix to prepend to the local file names when generating snippets. Optional, default is the current working folder.
This prefix can be used in distributed snippets generation along with load_files or load_files_scattered options.
Note that this is a prefix and not a path! This means that if a prefix is set to "server1" and the request refers to "file23", searchd will attempt to open "server1file23" (all of that without quotes). So, if you need it to be a path, you have to include the trailing slash.
After constructing the final file path, the server unwinds all relative dirs and compares the final result with the value of snippet_file_prefix. If the result does not begin with the prefix, such a file will be rejected with an error message.
For example, if you set it to /mnt/data and someone calls snippet generation with the file ../../../etc/passwd as the source, they will get the error message:
File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope
instead of the content of the file.
Also, with a non-set parameter and reading /etc/passwd, it will actually read /daemon/working/folder/etc/passwd since the default for the parameter is the server's working folder.
Note also that this is a local option; it does not affect the agents in any way. So you can safely set a prefix on a master server. The requests routed to the agents will not be affected by the master's setting. They will, however, be affected by the agent's own settings.
This might be useful, for instance, when the document storage locations (whether local storage or NAS mountpoints) are inconsistent across the servers.
- Example
snippets_file_prefix = /mnt/common/server1/WARNING: If you still want to access files from the FS root, you have to explicitly set
snippets_file_prefixto empty value (bysnippets_file_prefix=line), or to root (bysnippets_file_prefix=/).
Path to a file where the current SQL state will be serialized.
On server startup, this file gets replayed. On eligible state changes (e.g., SET GLOBAL), this file gets rewritten automatically. This can prevent a hard-to-diagnose problem: If you load UDF functions but Manticore crashes, when it gets (automatically) restarted, your UDF and global variables will no longer be available. Using persistent state helps ensure a graceful recovery with no such surprises.
sphinxql_state cannot be used to execute arbitrary commands, such as CREATE TABLE.
- Example
sphinxql_state = uservars.sqlMaximum time to wait between requests (in seconds, or special_suffixes) when using the SQL interface. Optional, default is 15 minutes.
- Example
sphinxql_timeout = 15mPath to the SSL Certificate Authority (CA) certificate file (also known as root certificate). Optional, default is empty. When not empty, the certificate in ssl_cert should be signed by this root certificate.
Сервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.
- Example
ssl_ca = keys/ca-cert.pemПуть к SSL-сертификату сервера. Необязательно, по умолчанию пусто.
Сервер использует этот сертификат как самоподписанный открытый ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.
- Example
ssl_cert = keys/server-cert.pemПуть к ключу SSL-сертификата. Необязательно, по умолчанию пусто.
Сервер использует этот приватный ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.
- Example
ssl_key = keys/server-key.pemМаксимальный размер кеша документов общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).
Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. multi-queries). Максимум столько ОЗУ будет потрачено на кеширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.
- Example
subtree_docs_cache = 8MМаксимальный размер кеша попаданий общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).
Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. multi-queries). Максимум столько ОЗУ будет потрачено на кеширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.
- Example
subtree_hits_cache = 16MКоличество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт такое количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:
- Поиск в таблице реального времени
- Поиск в распределённой таблице, состоящей из локальных таблиц
- Вызов перколяции запроса
- и другие
По умолчанию установлено количество ядер CPU на сервере. Manticore создаёт потоки при запуске и держит их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.
В случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше количества ядер CPU.
- Example
threads = 10Максимальный размер стека для задачи (корутина, один поисковый запрос может вызвать несколько задач/корутин). Необязательно, по умолчанию 128K.
Каждая задача имеет свой собственный стек размером 128K. При запуске запроса проверяется, сколько стека он требует. Если стандартных 128K достаточно, запрос просто обрабатывается. Если требуется больше, планируется другая задача с увеличенным стеком, которая продолжает обработку. Максимальный размер такого расширенного стека ограничен этой настройкой.
Установка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужен стек в 500M. И только если мы увидим внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.
Однако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и потребляет слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой thread_stack выглядит вполне разумным.
- Example
thread_stack = 8MОпределяет, следует ли удалять копии таблиц с расширением .old после успешной ротации. Необязательно, по умолчанию 1 (удалять).
- Example
unlink_old = 0Поточный сторож сервера. Необязательно, по умолчанию 1 (сторож включён).
Когда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа searchd также поддерживает отдельный лёгкий процесс, который следит за основным процессом сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.
- Example
watchdog = 0 # disable watchdoglemmatizer_base — это необязательная директива конфигурации, которая задает базовый путь для словарей лемматизатора. Путь по умолчанию — /usr/share/manticore
Реализация лемматизатора в Manticore Search (см. Морфология, чтобы узнать, что такое лемматизаторы) основана на словарях и требует специальных файлов словарей для разных языков. Эти файлы можно скачать с сайта Manticore (https://manticoresearch.com/install/#other-downloads).
Пример:
lemmatizer_base = /usr/share/manticore/progressive_merge — это директива конфигурации, которая при включении объединяет дисковые чанки таблицы в реальном времени от меньших к большим. Такой подход ускоряет процесс слияния и уменьшает усиление операций чтения/записи. По умолчанию эта настройка включена. Если отключена, чанки объединяются в порядке их создания.
json_autoconv_keynames — это необязательная директива конфигурации, которая определяет, нужно ли и как автоматически преобразовывать имена ключей внутри JSON-атрибутов. Известное значение — 'lowercase'. По умолчанию эта настройка не задана (то есть преобразование не происходит).
При установке в lowercase имена ключей внутри JSON-атрибутов будут автоматически преобразовываться в нижний регистр во время индексации. Это преобразование применяется к JSON-атрибутам из всех источников данных, включая SQL и XMLpipe2.
Пример:
json_autoconv_keynames = lowercasejson_autoconv_numbers — это необязательная директива конфигурации, которая определяет, следует ли автоматически обнаруживать и преобразовывать JSON-строки, представляющие числа, в числовые атрибуты. Значение по умолчанию — 0 (не преобразовывать строки в числа).
Если эта опция установлена в 1, значения, такие как "1234", будут индексироваться как числа, а не как строки. Если опция установлена в 0, такие значения будут индексироваться как строки. Это преобразование применяется к JSON-атрибутам из всех источников данных, включая SQL и XMLpipe2.
Пример:
json_autoconv_numbers = 1on_json_attr_error — это необязательная директива конфигурации, которая задает действие при обнаружении ошибок формата JSON. Значение по умолчанию — ignore_attr (игнорировать ошибки). Эта настройка применяется только к атрибутам sql_attr_json.
По умолчанию ошибки формата JSON игнорируются (ignore_attr), и инструмент индексации выводит предупреждение. Установка этой опции в fail_index приведет к сбою индексации при первой ошибке формата JSON.
Пример:
on_json_attr_error = ignore_attrplugin_dir — это необязательная директива конфигурации, которая задает доверенное расположение для динамических библиотек (UDF). Путь по умолчанию — /usr/local/lib/manticore/.
Эта директива задает доверенную директорию, из которой могут загружаться библиотеки UDF.
Пример:
plugin_dir = /usr/local/lib/manticore/Manticore Search поддерживает использование специальных суффиксов для упрощения числовых значений с определённым значением. Эти суффиксы делятся на суффиксы размера и суффиксы времени. Общий формат суффиксов — это целое число, за которым следует литерал, например 10k или 100d. Литералы не чувствительны к регистру, поэтому 10W и 10w считаются одинаковыми.
-
Суффиксы размера: Эти суффиксы можно использовать в настройках, которые определяют размер чего-либо, например, буфера памяти, размера файла на диске или лимита ОЗУ. Если суффикс не указан, значение по умолчанию считается в байтах. Доступные суффиксы размера:
kдля килобайтов (1k = 1024 байта)mдля мегабайтов (1m = 1024k)gдля гигабайтов (1g = 1024m)tдля терабайтов (1t = 1024g)
-
Суффиксы времени: Эти суффиксы можно использовать в настройках, которые определяют значения временных интервалов, таких как задержки или тайм-ауты. Значения без суффиксов для этих параметров обычно имеют задокументированную шкалу, но вместо догадок можно использовать явный суффикс. Доступные суффиксы времени:
usдля микросекундmsдля миллисекундsдля секундmдля минутhдля часовdдля днейwдля недель
Конфигурация Manticore поддерживает синтаксис shebang, позволяющий писать конфигурацию на языке программирования и интерпретировать её при загрузке. Это даёт возможность динамически задавать настройки, например, создавать таблицы, выполняя запросы к таблице базы данных, изменять настройки в зависимости от внешних факторов или включать внешние файлы с объявлениями таблиц и источников.
Файл конфигурации разбирается объявленным интерпретатором, а его вывод используется в качестве фактической конфигурации. Это происходит каждый раз при чтении конфигурации, а не только при запуске searchd.
Примечание: эта функция недоступна на платформе Windows.
В следующем примере используется PHP для создания нескольких таблиц с разными именами и для сканирования определённой папки на наличие файлов с дополнительными объявлениями таблиц:
#!/usr/bin/php
...
<?php for ($i=1; $i<=6; $i++) { ?>
table test_<?=$i?> {
type = rt
path = /var/lib/manticore/data/test_<?=$i?>
rt_field = subject
...
}
<?php } ?>
...
<?php
$confd_folder='/etc/manticore.conf.d/';
$files = scandir($confd_folder);
foreach($files as $file)
{
if(($file == '.') || ($file =='..'))
{} else {
$fp = new SplFileInfo($confd_folder.$file);
if('conf' == $fp->getExtension()){
include ($confd_folder.$file);
}
}
}
?>