Приведённые ниже настройки используются в разделе 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. Если указана опция для запроса, она переопределит значение, заданное в конфигурации.
Обратите внимание, что если в определении вашей распределённой таблицы используются зеркала агентов, сервер будет выбирать другое зеркало для каждой попытки подключения в соответствии с выбранной ha_strategy. В этом случае значение agent_retry_count будет агрегировано для всех зеркал в наборе.
Например, если у вас есть 10 зеркал и установлено agent_retry_count=5, сервер выполнит до 50 повторных попыток, предполагая в среднем по 5 попыток для каждого из 10 зеркал (при опции ha_strategy = roundrobin так и будет).
Однако значение, указанное в качестве опции retry_count для агента, служит абсолютным ограничением. Другими словами, опция [retry_count=2] в определении агента всегда означает максимум 2 попытки, независимо от того, указали вы для агента 1 или 10 зеркал.
Эта настройка представляет собой целое число в миллисекундах (или специальных суффиксах), которое указывает задержку перед повторной попыткой выполнения запроса к удалённому агенту в случае сбоя. Это значение актуально только при указании ненулевого значения agent_retry_count или ненулевого значения retry_count для запроса. Значение по умолчанию — 500. Это значение также можно установить для отдельного запроса с помощью предложения OPTION retry_delay=XXX. Если указана опция для запроса, она переопределит значение, заданное в конфигурации.
При использовании UPDATE для изменения атрибутов документов в реальном времени изменения сначала записываются в копию атрибутов в оперативной памяти. Эти обновления происходят в файле, отображаемом в память, что означает, что ОС решает, когда записать изменения на диск. При нормальном завершении работы searchd (вызванном сигналом SIGTERM) все изменения принудительно записываются на диск.
Вы также можете указать searchd периодически записывать эти изменения обратно на диск, чтобы предотвратить потерю данных. Интервал между этими сбросами определяется параметром attr_flush_period, указываемым в секундах (или с использованием специальных суффиксов).
По умолчанию значение равно 0, что отключает периодический сброс. Однако сброс всё равно произойдёт при нормальном завершении работы.
- Example
attr_flush_period = 900 # persist updates to disk every 15 minutesЭта настройка управляет автоматическим процессом OPTIMIZE для уплотнения таблицы.
По умолчанию уплотнение таблицы происходит автоматически. Вы можете изменить это поведение с помощью настройки auto_optimize:
- 0 для отключения автоматического уплотнения таблицы (вы всё равно можете вручную вызывать
OPTIMIZE) - 1 для явного включения
- для включения с умножением порога оптимизации на 2.
По умолчанию OPTIMIZE выполняется до тех пор, пока количество дисковых чанков не станет меньше или равно количеству логических ядер ЦП, умноженному на 2.
Однако, если у таблицы есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается равным количеству физических ядер ЦП, делённому на 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 МБ.
Новый файл бинарного лога будет принудительно открыт, как только текущий файл достигнет этого ограничения по размеру. Это приводит к более детальной гранулярности логов и может обеспечить более эффективное использование диска для бинарного лога при определённых пограничных рабочих нагрузках. Значение 0 указывает, что файл бинарного лога не должен переоткрываться на основе размера.
- Example
binlog_max_log_size = 16MЭта настройка определяет путь к файлам бинарного лога (также известного как журнал транзакций). Она является необязательной, по умолчанию имеет значение каталога данных, настроенного во время сборки (например, /var/lib/manticore/data/binlog.* в Linux).
Бинарные логи используются для восстановления данных RT-таблиц после сбоев и для обновления атрибутов обычных дисковых индексов, которые в противном случае хранились бы только в оперативной памяти до сброса на диск. При включенном логировании каждая транзакция, зафиксированная (COMMIT) в RT-таблице, записывается в файл журнала. Затем логи автоматически воспроизводятся при запуске после некорректного завершения работы, восстанавливая залогированные изменения.
Директива binlog_path указывает расположение файлов бинарных логов. Она должна содержать только путь; searchd будет создавать и удалять несколько файлов 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 или реализовать новый плагин. В последнем случае вы можете клонировать Buddy из репозитория git clone 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, установите значение пустым, как показано в примере.
- 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Эта настройка определяет максимальное время ожидания между запросами (в секундах или с специальными суффиксами) при использовании постоянных соединений. Она является необязательной, значение по умолчанию — пять минут.
- 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Эта настройка управляет режимом строгой проверки при преобразовании строк в числовые типы во время операций INSERT и REPLACE. Необязательная, по умолчанию 0 (нестрогий режим, обратно совместимый).
При значении 1 (строгий режим) некорректные преобразования строк в числа (например, преобразование пустой строки '' или нечисловой строки 'a' в атрибут типа bigint) будут возвращать ошибки вместо тихого преобразования в 0. Это помогает раньше выявлять проблемы с качеством данных при вставке.
При значении 0 (нестрогий режим, по умолчанию) некорректные преобразования будут тихо преобразовываться в 0, сохраняя обратную совместимость со старыми версиями.
Строгий режим проверяет следующие случаи:
- Пустые строки или строки, которые не могут быть преобразованы
- Строки с завершающими нечисловыми символами (например,
'123abc') - Числовые значения, выходящие за пределы диапазона типа (переполнение/потеря значимости)
- Example
attr_autoconv_strict = 1 # enable strict conversion modeТаймаут для предотвращения автоматического сброса RAM-чанка на диск, если в таблице не выполняются поисковые запросы. Необязательный, по умолчанию 30 секунд.
Время проверки наличия поисковых запросов перед определением необходимости автоматической сброски на диск.
Автоматическая сброска на диск произойдет только если в таблице был хотя бы один поисковый запрос за последние diskchunk_flush_search_timeout секунд. Работает совместно с diskchunk_flush_write_timeout. Соответствующая настройка на уровне таблицы имеет более высокий приоритет и переопределяет этот глобальный параметр по умолчанию, обеспечивая более детальный контроль.
- Example
diskchunk_flush_search_timeout = 120sВремя в секундах ожидания без записи перед автоматической сброской RAM-чанка на диск. Необязательный параметр, значение по умолчанию — 1 секунда.
Если в RAM-чанке не происходит запись в течение diskchunk_flush_write_timeout секунд, чанк будет сброшен на диск. Работает совместно с 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' (такие как группировка по дням, неделям, месяцам и годам в 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 в SQL) приведет к тому, что все выражения группировки по времени будут рассчитываться в UTC, оставляя остальные зависящие от времени функции (например, логирование сервера) в локальном часовом поясе TZ.
Эта настройка определяет часовой пояс, используемый функциями, связанными с датой/временем. По умолчанию используется локальный часовой пояс, но вы можете указать другой часовой пояс в формате IANA (например, Europe/Amsterdam).
Обратите внимание, что эта настройка не влияет на логирование, которое всегда работает в локальном часовом поясе.
Также обратите внимание, что если используется grouping_in_utc, функция 'group by time' по-прежнему будет использовать UTC, в то время как другие функции, связанные с датой/временем, будут использовать указанный часовой пояс. В целом, не рекомендуется смешивать grouping_in_utc и timezone.
Вы можете настроить эту опцию либо в конфигурации, либо с помощью оператора SET global в SQL.
Эта настройка определяет размер окна статистики зеркал агента в секундах (или специальных суффиксах). Она является необязательной, со значением по умолчанию 60 секунд.
Для распределенной таблицы с зеркалами агента (подробнее см. agent) мастер отслеживает несколько различных счетчиков для каждого зеркала. Эти счетчики затем используются для отказоустойчивости и балансировки (мастер выбирает лучшее зеркало для использования на основе счетчиков). Счетчики накапливаются блоками по ha_period_karma секунд.
После начала нового блока мастер может по-прежнему использовать накопленные значения из предыдущего блока, пока новый не заполнится наполовину. В результате любая предыдущая история перестает влиять на выбор зеркала максимум через 1,5 раза от ha_period_karma секунд.
Несмотря на то, что для выбора зеркала используется не более двух блоков, до 15 последних блоков хранятся для целей инструментирования. Эти блоки можно проверить с помощью оператора SHOW AGENT STATUS.
- Example
ha_period_karma = 2mЭта настройка задает интервал между пингами зеркал агента в миллисекундах (или специальных суффиксах). Она является необязательной, со значением по умолчанию 1000 миллисекунд.
Для распределенной таблицы с зеркалами агента (подробнее см. agent) мастер отправляет всем зеркалам команду ping в периоды простоя. Это необходимо для отслеживания текущего статуса агента (жив или мертв, сетевая задержка и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите 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 МБ, а установка этой опции в 0 отключает кэширование.
Обратите внимание, что каждый поток поддерживает свой собственный кэш, поэтому при оценке общего использования памяти следует учитывать количество потоков, выполняющих запросы.
join_cache_size = 10MНастройка listen_backlog определяет длину очереди TCP-подключений (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-путь идентифицируется начальным слешем. Диапазон портов может быть установлен только для протокола репликации.
Вы также можете указать обработчик протокола (слушатель), который будет использоваться для соединений на этом сокете. Слушатели:
- Не указан - 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для 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).
Эта настройка позволяет использовать флаг TCP_FASTOPEN для всех слушателей. По умолчанию она управляется системой, но может быть явно отключена установкой значения '0'.
Для общего понимания расширения TCP Fast Open, пожалуйста, обратитесь к Википедии. Вкратце, оно позволяет устранить один TCP-раундтрип при установлении соединения.
На практике использование TFO во многих ситуациях может оптимизировать сетевую эффективность клиент-агент, как если бы использовались постоянные агенты, но без удержания активных соединений, а также без ограничения на максимальное количество соединений.
В современных ОС поддержка TFO обычно включена на системном уровне, но это лишь "возможность", а не правило. Linux (как самый прогрессивный) поддерживает его с 2011 года, начиная с ядер 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие операционные системы (FreeBSD, MacOS) также в игре.
Для сервера на Linux система проверяет переменную /proc/sys/net/ipv4/tcp_fastopen и ведет себя в соответствии с ней. Бит 0 управляет клиентской стороной, бит 1 управляет слушателями. По умолчанию система имеет этот параметр установленным в 1, т.е. клиенты включены, слушатели отключены.
Настройка log указывает имя файла журнала, в который будут записываться все события времени выполнения searchd. Если не указано, имя по умолчанию - 'searchd.log'.
В качестве альтернативы вы можете использовать 'syslog' в качестве имени файла. В этом случае события будут отправляться демону syslog. Чтобы использовать опцию syslog, необходимо сконфигурировать Manticore с опцией -–with-syslog во время сборки.
- Example
log = /var/log/searchd.logОграничивает количество запросов в пакете. Необязательный параметр, по умолчанию равен 32.
Заставляет searchd выполнять проверку корректности количества запросов, отправленных в одном пакете при использовании мультизапросов. Установите значение 0, чтобы пропустить проверку.
- Example
max_batch_queries = 256Максимальное количество одновременных клиентских подключений. По умолчанию не ограничено. Обычно это заметно только при использовании любого вида постоянных соединений, таких как сессии cli mysql или постоянные удаленные соединения с удаленных распределенных таблиц. При превышении лимита вы все равно можете подключиться к серверу, используя VIP-соединение. VIP-соединения не учитываются в лимите.
- Example
max_connections = 10Глобальное для экземпляра ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра процессора, не оставляя места для других операций. Например, call pq для достаточно большой перколяционной таблицы может использовать все потоки в течение десятков секунд. Установка 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.
Этот параметр полезен при чрезвычайно высокой частоте запросов, когда одного потока недостаточно для управления всеми входящими запросами.
Управляет интервалом активного цикла сетевого потока. По умолчанию -1, может быть установлено в -1, 0 или положительное целое число.
В случаях, когда сервер сконфигурирован как чистый мастер и просто маршрутизирует запросы агентам, важно обрабатывать запросы без задержек и не позволять сетевому потоку спать. Для этого существует активный цикл. После входящего запроса сетевой поток использует опрос CPU в течение 10 * net_wait_tm миллисекунд, если net_wait_tm является положительным числом, или опрашивает только с помощью CPU, если net_wait_tm равен 0. Также активный цикл может быть отключен с помощью net_wait_tm = -1 - в этом случае поллер устанавливает таймаут на фактическое время ожидания агентов при системном вызове опроса.
ВНИМАНИЕ: Активный цикл ЦП фактически нагружает ядро процессора, поэтому установка этого значения на любое значение, отличное от значения по умолчанию, приведет к заметному использованию ЦП даже на простаивающем сервере.
Определяет, сколько клиентов принимается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для управления пропускной способностью сетевого цикла в сценариях с высокой нагрузкой.
Определяет, сколько запросов обрабатывается на каждой итерации сетевого цикла. По умолчанию 0 (без ограничений), что подходит для большинства пользователей. Это опция тонкой настройки для управления пропускной способностью сетевого цикла в сценариях с высокой нагрузкой.
Таймаут чтения/записи сетевого клиентского запроса в секундах (или с специальными суффиксами). Необязательный параметр, по умолчанию 5 секунд. searchd принудительно закроет клиентское соединение, которое не смогло отправить запрос или прочитать результат в течение этого таймаута.
Также обратите внимание на параметр reset_network_timeout_on_packet. Этот параметр изменяет поведение network_timeout с применения ко всему запросу или результату на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объем данных, этот параметр может оказаться бесценным для поддержания активных операций.
- Example
network_timeout = 10sЭта настройка позволяет указать сетевой адрес узла. По умолчанию он устанавливается на адрес репликации listen. Это верно в большинстве случаев; однако бывают ситуации, когда его необходимо указать вручную:
- Узел за брандмауэром
- Включен трансляция сетевых адресов (NAT)
- Развертывания в контейнерах, таких как Docker или облачные развертывания
- Кластеры с узлами более чем в одном регионе
- Example
node_address = 10.101.0.10Эта настройка определяет, разрешать ли запросы, содержащие только оператор полнотекстового поиска отрицания. Необязательный параметр, по умолчанию 0 (запросы, содержащие только оператор NOT, завершаются ошибкой).
- Example
not_terms_only_allowed = 1Устанавливает порог уплотнения таблицы по умолчанию. Подробнее читайте здесь - Количество оптимизированных дисковых чанков. Эта настройка может быть переопределена с помощью опции для каждого запроса cutoff. Её также можно изменить динамически с помощью SET GLOBAL.
- Example
optimize_cutoff = 4Эта настройка определяет максимальное количество одновременных постоянных соединений с удаленными постоянными агентами. Каждый раз при подключении агента, определенного в 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, которая указывает путь к файлу, в котором хранится идентификатор процесса (PID) сервера searchd.
Файл идентификатора процесса searchd создается заново и блокируется при запуске и содержит PID главного серверного процесса, пока сервер работает. Он удаляется при завершении работы сервера.
Цель этого файла — позволить 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.
Обратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:
- высокая параллельность запросов
- физическое шардирование любого вида:
- распределенная таблица из нескольких обычных/реального времени таблиц
- таблица реального времени, состоящая из слишком большого количества дисковых чанков
то включение 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), указывающее задержку перед повторной попыткой Manticore выполнить запрос к удаленному узлу в случае сбоя во время репликации. Это значение актуально только при указании ненулевого значения. Значение по умолчанию — 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. Подробнее см. в разделе Логирование запросов.
- Example
query_log_format = sphinxqlЛимит (в миллисекундах), который предотвращает запись запроса в лог запросов. Необязательный параметр, значение по умолчанию — 0 (все запросы записываются в лог запросов). Эта директива указывает, что в лог будут записываться только запросы, время выполнения которых превышает указанный лимит (это значение также может быть выражено с помощью специальных суффиксов времени, но используйте это с осторожностью и не путайте с названием самого значения, содержащим _msec).
Имя файла лога запросов. Необязательный параметр, значение по умолчанию — пустое (не логировать запросы). Все поисковые запросы (такие как SELECT ..., но не INSERT/REPLACE/UPDATE) будут записываться в этот файл. Формат описан в разделе Логирование запросов. В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу лога. В этом случае все поисковые запросы будут отправляться демону syslog с приоритетом LOG_INFO, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть сконфигурирован с флагом -–with-syslog при сборке.
- Example
query_log = /var/log/query.logДиректива query_log_mode позволяет установить другие права доступа для файлов логов searchd и запросов. По умолчанию эти файлы логов создаются с правами 600, что означает, что только пользователь, под которым работает сервер, и пользователи 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Размер чтения без подсказки (unhinted). Необязательный параметр, значение по умолчанию — 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-таблиц, в секундах (или специальные суффиксы). Необязательный, по умолчанию 10 часов.
Активно обновляемые RT-таблицы, которые полностью помещаются в RAM-чанках, всё равно могут приводить к постоянно растущим бинарным логам, влияя на использование диска и время восстановления после сбоя. С этой директивой сервер поиска выполняет периодические проверки сброса, и подходящие RAM-чанки могут быть сохранены, что позволяет выполнить последующую очистку бинарных логов. Подробнее см. в Бинарное логирование.
- 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 бесшовная ротация по умолчанию отключена.
Таблицы могут содержать некоторые данные, которые необходимо предварительно загрузить в оперативную память. На данный момент файлы .spa, .spb, .spi и .spm полностью предзагружаются (они содержат данные атрибутов, данные blob-атрибутов, таблицу ключевых слов и карту удалённых строк соответственно.) Без бесшовной ротации попытка ротации таблицы использует как можно меньше оперативной памяти и работает следующим образом:
- Новые запросы временно отклоняются (с кодом ошибки "повторить");
searchdожидает завершения всех текущих выполняемых запросов;- Старая таблица освобождается, и её файлы переименовываются;
- Файлы новой таблицы переименовываются, и выделяется необходимая оперативная память;
- Данные атрибутов и словаря новой таблицы предварительно загружаются в оперативную память;
searchdвозобновляет обслуживание запросов из новой таблицы.
Однако, если данных атрибутов или словаря много, то этап предварительной загрузки может занять заметное время — до нескольких минут в случае загрузки файлов объёмом 1–5+ ГБ.
При включённой бесшовной ротации процесс работает следующим образом:
- Выделяется хранилище оперативной памяти для новой таблицы;
- Данные атрибутов и словаря новой таблицы асинхронно предзагружаются в оперативную память;
- При успехе старая таблица освобождается, и файлы обеих таблиц переименовываются;
- При неудаче новая таблица освобождается;
- В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.
Бесшовная ротация достигается за счёт более высокого пикового использования оперативной памяти во время ротации (поскольку и старая, и новая копии данных .spa/.spb/.spi/.spm должны находиться в оперативной памяти во время предзагрузки новой копии). Среднее использование остаётся прежним.
- Example
seamless_rotate = 1Эта опция определяет размер кэша блоков, используемого вторичными индексами. Необязательная, по умолчанию 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений. В объединённых запросах этот процесс повторяется для каждого пакета строк из левой таблицы, и каждый пакет может перечитывать одни и те же метаданные в рамках одного объединённого запроса. Это может серьёзно повлиять на производительность. Кэш блоков метаданных сохраняет эти блоки в памяти, чтобы они могли быть повторно использованы последующими пакетами.
Кэш используется только в объединённых запросах и не влияет на необъединённые запросы. Обратите внимание, что ограничение размера кэша применяется для каждого атрибута и каждого вторичного индекса. Каждый атрибут внутри каждого дискового чанка работает в рамках этого ограничения. В худшем случае общее использование памяти можно оценить, умножив лимит на количество дисковых чанков и количество атрибутов, используемых в объединённых запросах.
Установка secondary_index_block_cache = 0 отключает кэш.
- Example
secondary_index_block_cache = 16MЭта опция включает/отключает использование вторичных индексов для поисковых запросов. Необязательная, по умолчанию 1 (включено). Обратите внимание, что для индексации её включать не нужно, так как она всегда включена, если установлена Manticore Columnar Library. Последняя также требуется для использования индексов при поиске. Доступны три режима:
0: Отключить использование вторичных индексов при поиске. Их можно включить для отдельных запросов с помощью подсказок анализатора1: Включить использование вторичных индексов при поиске. Их можно отключить для отдельных запросов с помощью подсказок анализатораforce: То же, что и включение, но любые ошибки во время загрузки вторичных индексов будут сообщены, и весь индекс не будет загружен в демон.
- Example
secondary_indexes = 1Целое число, которое служит идентификатором сервера, используемым в качестве сида для генерации уникального короткого UUID для узлов, являющихся частью репликационного кластера. server_id должен быть уникальным среди узлов кластера и находиться в диапазоне от 0 до 127. Если server_id не задан, он вычисляется как хэш MAC-адреса и пути к PID-файлу, или случайное число будет использоваться в качестве сида для короткого UUID.
- Example
server_id = 1Время ожидания searchd --stopwait в секундах (или специальные суффиксы). Опционально, по умолчанию 60 секунд.
Когда вы запускаете searchd --stopwait, ваш сервер должен выполнить некоторые действия перед остановкой, такие как завершение запросов, сброс RT RAM чанков, сброс атрибутов и обновление binlog. Эти задачи требуют некоторого времени. searchd --stopwait будет ждать до shutdown_time секунд, пока сервер завершит свою работу. Подходящее время зависит от размера вашей таблицы и нагрузки.
- Example
shutdown_timeout = 3m # wait for up to 3 minutesSHA1 хэш пароля, необходимого для вызова команды 'shutdown' из VIP соединения Manticore SQL. Без него debug подкоманда 'shutdown' никогда не приведет к остановке сервера. Обратите внимание, что такое простое хэширование не следует считать надежной защитой, поскольку мы не используем хэш с солью или какую-либо современную хэш-функцию. Это предназначено как простая мера предосторожности для служебных демонов в локальной сети.
Эта настройка задает максимальный размер кэша в оперативной памяти для распакованных списков пропуска (skiplists). Необязательный параметр, по умолчанию 64M.
Списки пропуска используются для ускорения поиска в больших списках документов. Их кэширование позволяет избежать многократной распаковки одних и тех же данных списков пропуска при разных запросах. Установите значение этого параметра в 0, чтобы отключить кэширование.
- Example
skiplist_cache_size = 128MПрефикс, добавляемый к локальным именам файлов при генерации сниппетов. Опционально, по умолчанию текущая рабочая папка.
Этот префикс можно использовать в распределенной генерации сниппетов вместе с опциями 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) не согласованы между серверами.
- Example
snippets_file_prefix = /mnt/common/server1/ПРЕДУПРЕЖДЕНИЕ: Если вы все еще хотите получить доступ к файлам из корня файловой системы, вы должны явно установить
snippets_file_prefixв пустое значение (строкойsnippets_file_prefix=), или в корень (строкойsnippets_file_prefix=/).
Путь к файлу, в который будет сериализовано текущее состояние SQL.
При запуске сервера этот файл воспроизводится. При соответствующих изменениях состояния (например, SET GLOBAL) этот файл автоматически перезаписывается. Это может предотвратить трудно диагностируемую проблему: если вы загружаете UDF функции, но Manticore падает, то при его (автоматическом) перезапуске ваши UDF и глобальные переменные больше не будут доступны. Использование постоянного состояния помогает обеспечить плавное восстановление без таких сюрпризов.
sphinxql_state нельзя использовать для выполнения произвольных команд, таких как CREATE TABLE.
- Example
sphinxql_state = uservars.sqlМаксимальное время ожидания между запросами (в секундах или специальные суффиксы) при использовании SQL интерфейса. Опционально, по умолчанию 15 минут.
- Example
sphinxql_timeout = 15mПуть к файлу сертификата центра сертификации SSL (CA) (также известному как корневой сертификат). Опционально, по умолчанию пусто. Когда не пусто, сертификат в ssl_cert должен быть подписан этим корневым сертификатом.
Сервер использует файл 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 (отключено).
Этот параметр ограничивает использование оперативной памяти оптимизатором общего поддерева (см. мультизапросы). Максимум, столько оперативной памяти будет потрачено на кэширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.
- Example
subtree_docs_cache = 8MМаксимальный размер кэша вхождений общего поддерева на запрос. Необязательный параметр, по умолчанию 0 (отключено).
Этот параметр ограничивает использование оперативной памяти оптимизатором общего поддерева (см. мультизапросы). Максимум, столько оперативной памяти будет потрачено на кэширование вхождений ключевых слов (хитов) для каждого запроса. Установка лимита в 0 отключает оптимизатор.
- Example
subtree_hits_cache = 16MКоличество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создает это количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разделены на подзадачи и выполняться параллельно, например:
- Поиск в таблице реального времени
- Поиск в распределенной таблице, состоящей из локальных таблиц
- Вызов перколяционного запроса
- и другие
По умолчанию значение равно количеству ядер ЦП на сервере. Manticore создает потоки при запуске и хранит их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.
В случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше, чем количество ядер ЦП.
- 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 (см. Morphology, чтобы узнать, что такое лемматизаторы) основана на словарях и требует конкретных файлов словарей для разных языков. Эти файлы можно скачать с сайта 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 поддерживает синтаксис шебанга, позволяя писать конфигурацию на языке программирования и интерпретировать её при загрузке. Это даёт возможность динамических настроек, таких как генерация таблиц путём запроса к таблице базы данных, изменение настроек на основе внешних факторов или включение внешних файлов с объявлениями таблиц и источников.
Файл конфигурации разбирается указанным интерпретатором, и вывод используется как реальная конфигурация. Это происходит каждый раз при чтении конфигурации, а не только при запуске 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);
}
}
}
?>