≫ 服务器设置
以下设置用于 Manticore Search 配置文件的 searchd 部分,以控制服务器的行为。以下是每个设置的摘要:
此设置为 access_plain_attrs 设置实例范围的默认值。此项为可选,默认值为 mmap_preread。
access_plain_attrs 指令允许您为此 searchd 实例管理的所有表定义 access_plain_attrs 的默认值。每个表的指令优先级更高,会覆盖此实例范围的默认值,从而提供更细粒度的控制。
此设置为 access_blob_attrs 设置实例范围的默认值。此项为可选,默认值为 mmap_preread。
access_blob_attrs 指令允许您为此 searchd 实例管理的所有表定义 access_blob_attrs 的默认值。每个表的指令优先级更高,会覆盖此实例范围的默认值,从而提供更细粒度的控制。
此设置为 access_doclists 设置实例范围的默认值。此项为可选,默认值为 file。
access_doclists 指令允许您为此 searchd 实例管理的所有表定义 access_doclists 的默认值。每个表的指令优先级更高,会覆盖此实例范围的默认值,从而提供更细粒度的控制。
此设置为 access_hitlists 设置实例范围的默认值。此项为可选,默认值为 file。
access_hitlists 指令允许您为此 searchd 实例管理的所有表定义 access_hitlists 的默认值。每个表的指令优先级更高,会覆盖此实例范围的默认值,从而提供更细粒度的控制。
此设置为 access_dict 设置实例范围的默认值。此项为可选,默认值为 mmap_preread。
access_dict 指令允许您为此 searchd 实例管理的所有表定义 access_dict 的默认值。每个表的指令优先级更高,会覆盖此实例范围的默认值,从而提供更细粒度的控制。
此设置为 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 次(使用 ha_strategy = roundrobin 选项时即为如此)。
然而,作为 agent 的 retry_count 选项提供的值是绝对限制。换句话说,代理定义中的 [retry_count=2] 选项始终意味着最多尝试 2 次,无论您为代理指定了 1 个还是 10 个镜像。
此设置为以毫秒为单位的整数(或 special_suffixes),指定 Manticore 在失败时重试查询远程代理之前的延迟时间。仅当指定非零的 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 OPTIMIZEManticore 支持自动创建尚不存在但在 INSERT 语句中指定的表。此功能默认启用。要禁用它,请在配置中显式设置 auto_schema = 0。要重新启用,请设置 auto_schema = 1 或从配置中移除 auto_schema 设置。
请注意,/bulk HTTP 端点不支持自动创建表。
注意:自动 schema 功能 需要 Manticore Buddy。如果功能无法使用,请确保 Buddy 已安装。
- Disable
- Enable
auto_schema = 0 # disable 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 MB。
当当前二进制日志文件达到此大小限制时,将强制打开一个新的日志文件。这带来了更细粒度的日志划分,并且在某些边界工作负载下可以更高效地使用二进制日志磁盘空间。值为 0 表示不基于大小重新打开日志文件。
- Example
binlog_max_log_size = 16M此设置确定二进制日志(也称为事务日志)文件的路径。为可选项,默认值为构建时配置的数据目录(例如 Linux 下的 /var/lib/manticore/data/binlog.*)。
二进制日志用于RT表数据的崩溃恢复以及普通磁盘索引的属性更新,否则这些属性更新仅存储在RAM中直到刷新。启用日志记录时,每个提交到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、对其进行修改或实现新插件,则可能需要修改。后者情况下,您可以从 https://github.com/manticoresoftware/manticoresearch-buddy 克隆Buddy,向 ./plugins/ 目录添加新插件,并在切换到Buddy源码目录后运行 composer install --prefer-source 以便于开发。
为确保能运行 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
您也可以选择发布中的Linux amd64专用版本 manticore-executor-dev,例如:https://github.com/manticoresoftware/executor/releases/tag/v1.0.13
如果采用此方式,记得将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此设置控制由于 PHRASE、PROXIMITY 和 QUORUM 操作符内的 OR 操作符生成的替代短语变体的最大数量。此项为可选,默认值为 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(表示“本地时区”)。
默认情况下,所有“按时间分组”表达式(如 API 中的按天、周、月和年分组,以及 SQL 中的按天、月、年、年月、年月日分组)均使用本地时间进行。例如,如果您有属性时间为 13:00 utc 和 15:00 utc 的文档,在分组时,它们都会根据您的本地时区设置归入相应的设施组。如果您所在时区为 utc,则它们属于同一天,但如果您所在时区为 utc+10,则这些文档会被匹配到不同的“按天分组”设施组(因为 UTC+10 时区的 13:00 utc 是本地时间 23:00,而 15:00 是第二天的 01:00)。有时这种行为是不可接受的,且希望使时间分组不依赖于时区。您可以通过设置全局 TZ 环境变量来运行服务器,但这不仅会影响分组,还会影响日志中的时间戳,这可能也是不希望的。开启此选项(无论是在配置中还是使用 SQL 中的 SET global 语句)将使所有时间分组表达式以 UTC 计算,而其他依赖时间的函数(例如服务器日志记录)仍使用本地时区。
此设置指定日期/时间相关函数使用的时区。默认情况下,使用本地时区,但您可以指定 IANA 格式的其他时区(例如,Europe/Amsterdam)。
请注意,此设置不会影响日志记录,日志始终使用本地时区。
另外,请注意,如果使用了 grouping_in_utc,则“按时间分组”函数仍将使用 UTC,而其他日期/时间相关函数将使用指定的时区。总体而言,不建议混合使用 grouping_in_utc 和 timezone。
您可以在配置中设置此选项,或通过 SQL 中的 SET global 语句进行配置。
此设置指定代理镜像统计窗口大小,单位为秒(或 special_suffixes)。此项为可选,默认值为 60 秒。
对于包含代理镜像的分布式表(详见 agent),主节点跟踪多个不同的每镜像计数器。这些计数器随后用于故障转移和平衡(主节点根据计数器选择最佳镜像)。计数器以 ha_period_karma 秒为块进行累积。
开始新块后,主节点可能仍会使用前一个块的累积值,直到新块填充到一半。因此,任何之前的历史最多在 1.5 倍 ha_period_karma 秒后停止影响镜像选择。
尽管最多使用两个块进行镜像选择,但最多存储最近 15 个块以供监控使用。可以使用 SHOW AGENT STATUS 语句查看这些块。
- Example
ha_period_karma = 2m此设置配置代理镜像之间的 ping 间隔,单位为毫秒(或 special_suffixes)。此项为可选,默认值为 1000 毫秒。
对于包含代理镜像的分布式表(详见 agent),主节点在空闲期间向所有镜像发送 ping 命令,以跟踪当前代理状态(存活或死亡、网络往返时间等)。此指令定义了 ping 之间的间隔。要禁用 ping,请将 ha_ping_interval 设置为 0。
- Example
ha_ping_interval = 3shostname_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 监听队列的长度,用于传入连接。这对于逐个处理请求的 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此设置允许您指定 Manticore 接受连接的 IP 地址和端口,或 Unix 域套接字路径。
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 功能受限。
mysqlMySQL 协议,用于 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 节点和基于 Manticore 二进制 API 的客户端的连接。
默认情况下,Linux 不允许 Manticore 监听 1024 以下的端口(例如 listen = 127.0.0.1:80:http 或 listen = 127.0.0.1:443:https),除非以 root 用户运行 searchd。如果您仍希望在非 root 用户下启动 Manticore 并监听 <1024 端口,请考虑以下任一方法(任一方法均可):
- 运行命令
setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/searchd - 在 Manticore 的 systemd 单元中添加
AmbientCapabilities=CAP_NET_BIND_SERVICE并重新加载守护进程(systemctl daemon-reload)。
此设置允许为所有监听器启用 TCP_FASTOPEN 标志。默认情况下,由系统管理,但可以通过设置为 '0' 明确关闭。
关于 TCP Fast Open 扩展的一般知识,请参考 Wikipedia。简而言之,它允许在建立连接时消除一次 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 选项,您需要在构建时使用 -–with-syslog 选项配置 Manticore。
- Example
log = /var/log/searchd.log限制每批查询的数量。可选,默认值为 32。
当使用 多查询 时,使 searchd 对单个批次中提交的查询数量进行合理性检查。设置为 0 可跳过检查。
- Example
max_batch_queries = 256最大同时客户端连接数。默认无限制。通常只有在使用任何类型的持久连接时才会注意到,比如 cli mysql 会话或来自远程分布式表的持久远程连接。当超过限制时,您仍然可以使用 VIP 连接 连接服务器。VIP 连接不计入限制。
- Example
max_connections = 10单个操作可使用的线程实例范围限制。默认情况下,适当的操作可以占用所有 CPU 核心,不留给其他操作空间。例如,对相当大的 percolate 表执行 call pq 可能会利用所有线程持续数十秒。将 max_threads_per_query 设置为例如 threads 的一半,将确保您可以并行运行几个这样的 call pq 操作。
您也可以在运行时将此设置作为会话或全局变量设置。
此外,您可以借助 threads 选项 按查询控制行为。
- Example
max_threads_per_query = 4每个查询允许的最大过滤器数量。此设置仅用于内部合理性检查,不直接影响内存使用或性能。可选,默认值为 256。
- Example
max_filters = 1024每个过滤器允许的最大值数量。此设置仅用于内部合理性检查,不直接影响内存使用或性能。可选,默认值为 4096。
- Example
max_filter_values = 16384服务器允许打开的最大文件数称为“软限制”。请注意,服务大型碎片化实时表可能需要将此限制设置得较高,因为每个磁盘块可能占用十几个或更多文件。例如,一个有 1000 个块的实时表可能需要同时打开数千个文件。如果您在日志中遇到“打开的文件过多”错误,请尝试调整此选项,这可能有助于解决问题。
还有一个“硬限制”,该限制不能被此选项超越。此限制由系统定义,可在 Linux 的 /etc/security/limits.conf 文件中更改。其他操作系统可能有不同的方法,请查阅您的手册以获取更多信息。
- 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 连接器 6.3.x 在版本号为 1.x 且某些标志组合时内部失败等。为了解决这个问题,您可以使用 mysql_version_string 指令,让 searchd 向通过 MySQL 协议连接的客户端报告不同的版本。(默认情况下,它报告自己的版本。)
- Example
mysql_version_string = 5.0.37网络线程数,默认值为 1。
当查询率极高且单线程无法管理所有传入查询时,此设置非常有用。
控制网络线程的忙循环间隔。默认值为 -1,可设置为 -1、0 或正整数。
在服务器配置为纯主服务器并仅将请求路由到代理的情况下,重要的是要无延迟地处理请求,不允许网络线程进入休眠状态。为此有一个忙循环。在收到请求后,如果 net_wait_tm 是正数,网络线程会使用 CPU 轮询 10 * net_wait_tm 毫秒;如果 net_wait_tm 是 0,则只用 CPU 轮询。 另外,可以通过设置 net_wait_tm = -1 来禁用忙循环——在这种情况下,轮询器会在系统轮询调用中将超时设置为实际代理的超时。
警告: CPU 忙循环实际上会占用 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设置默认的表压缩阈值。详细信息请参见 - 优化的磁盘块数量。此设置可以被每个查询的选项 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 搜索中的一个必需配置选项,指定存储 searchd 服务器进程 ID 的文件路径。
searchd 进程 ID 文件在启动时被重新创建并锁定,服务器运行时包含主服务器进程 ID。服务器关闭时该文件被删除。
该文件的目的是使 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_time有一个选项,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 = 1pseudo_sharding配置选项启用对本地普通表和实时表的搜索查询并行化,无论是直接查询还是通过分布式表查询。此功能会自动将查询并行化到searchd.threads指定的线程数。
请注意,如果你的工作线程已经很忙,因为你有:
- 高查询并发
- 任何形式的物理分片:
- 多个普通/实时表的分布式表
- 由过多磁盘块组成的实时表
那么启用pseudo_sharding可能不会带来任何好处,甚至可能导致吞吐量略有下降。如果你优先考虑更高吞吐量而非更低延迟,建议禁用此选项。
默认启用。
- Example
pseudo_sharding = 0replication_connect_timeout指令定义连接远程节点的超时时间。默认值假定为毫秒,但可以使用其他后缀。默认值为1000(1秒)。
连接远程节点时,Manticore最多等待此时间以成功完成连接。如果超时但连接未建立,且启用了retries,则会发起重试。
replication_query_timeout设置searchd等待远程节点完成查询的时间。默认值为3000毫秒(3秒),但可以使用后缀表示不同时间单位。
建立连接后,Manticore将最多等待replication_query_timeout时间以完成远程节点的查询。注意此超时与replication_connect_timeout分开,远程节点可能导致的总延迟是两者之和。
此设置为整数,指定Manticore在复制期间尝试连接和查询远程节点的次数,超过后报告致命查询错误。默认值为3。
此设置为以毫秒为单位的整数(或特殊后缀),指定复制期间查询远程节点失败后重试前的延迟时间。仅当指定非零值时生效。默认值为500。
此配置设置用于缓存结果集的最大RAM字节数。默认值为16777216,相当于16兆字节。如果设置为0,则禁用查询缓存。有关查询缓存的更多信息,请参阅查询缓存。
- Example
qcache_max_bytes = 16777216整数,单位为毫秒。查询结果被缓存的最小墙钟时间阈值。默认值为3000,即3秒。0表示缓存所有。详情请参阅查询缓存。此值也可以用时间特殊后缀表示,但请谨慎使用,避免与值名中包含的'_msec'混淆。
整数,单位为秒。缓存结果集的过期时间。默认值为60秒,即1分钟。最小可能值为1秒。详情请参阅查询缓存。该值也可以用时间特殊后缀表示,但请谨慎使用,不要与值本身包含的“_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”作为日志文件路径。在这种情况下,所有搜索查询将以LOG_INFO优先级发送到syslog守护进程,前缀为“[query]”而非时间戳。要使用syslog选项,Manticore必须在构建时配置-–with-syslog。
- Example
query_log = /var/log/query.logquery_log_mode指令允许您为searchd和查询日志文件设置不同的权限。默认情况下,这些日志文件的权限为600,意味着只有运行服务器的用户和root用户可以读取日志文件。 如果您想允许其他用户读取日志文件,例如运行在非root用户下的监控解决方案,此指令非常有用。
- Example
query_log_mode = 666read_buffer_docs指令控制文档列表的每个关键字读取缓冲区大小。对于每个搜索查询中的每个关键字出现,有两个相关的读取缓冲区:一个用于文档列表,一个用于命中列表。此设置允许您控制文档列表缓冲区大小。
较大的缓冲区大小可能会增加每个查询的RAM使用,但可能减少I/O时间。对于慢速存储,设置较大值是合理的,但对于能够提供高IOPS的存储,应在较低值区域进行实验。
默认值为256K,最小值为8K。您也可以在每个表级别设置read_buffer_docs,这将覆盖服务器配置级别的设置。
- Example
read_buffer_docs = 128Kread_buffer_hits指令指定搜索查询中命中列表的每个关键字读取缓冲区大小。默认大小为256K,最小值为8K。对于搜索查询中的每个关键字出现,有两个相关的读取缓冲区,一个用于文档列表,一个用于命中列表。增加缓冲区大小可以增加每个查询的RAM使用,但减少I/O时间。对于慢速存储,较大的缓冲区大小是合理的,而对于能够提供高IOPS的存储,应在较低值区域进行实验。
此设置也可以通过在每个表级别使用read_buffer_hits选项在read_buffer_hits中指定,这将覆盖服务器级别的设置。
- Example
read_buffer_hits = 128K未提示读取大小。可选,默认值为32K,最小值为1K。
在查询时,有些读取操作事先知道确切的数据量,但有些则不知道。最明显的是,命中列表大小目前无法预先知道。此设置允许您控制在这种情况下读取的数据量。它影响命中列表的I/O时间,对于大于未提示读取大小的列表减少I/O时间,但对于较小的列表则增加I/O时间。它不影响RAM使用,因为读取缓冲区已经分配。因此,它不应大于read_buffer。
- Example
read_unhinted = 32K细化网络超时(如network_timeout和agent_query_timeout)的行为。
设置为0时,超时限制发送整个请求/查询的最大时间。 设置为1(默认)时,超时限制网络活动之间的最大时间。
通过复制,节点可能需要将一个大文件(例如,100GB)发送到另一个节点。假设网络传输速率为1GB/s,数据包大小为4-5MB。传输整个文件需要100秒。默认的5秒超时只允许传输5GB数据,之后连接会被断开。增加超时可以作为一种解决方法,但这不可扩展(例如,下一个文件可能是150GB,仍会导致失败)。然而,默认情况下 reset_network_timeout_on_packet 设置为1,超时应用于单个数据包而非整个传输。只要传输正在进行中(且在超时期间网络上实际接收到了数据),连接就会保持活跃。如果传输卡住,导致数据包之间发生超时,则连接会被断开。
请注意,如果设置了分布式表,主节点和代理节点都应进行调优。主节点影响的是 agent_query_timeout;代理节点则相关于 network_timeout。
- Example
reset_network_timeout_on_packet = 0RT表RAM块刷新检查周期,单位为秒(或special_suffixes)。可选,默认值为10小时。
完全适合RAM块的主动更新RT表仍可能导致binlog不断增长,影响磁盘使用和崩溃恢复时间。通过此指令,搜索服务器执行周期性刷新检查,符合条件的RAM块可以被保存,从而实现后续binlog清理。详情见二进制日志。
- Example
rt_flush_period = 3600 # 1 hourRT块合并线程允许启动的最大I/O操作数(每秒)。可选,默认值为0(无限制)。
此指令允许限制由 OPTIMIZE 语句引起的I/O影响。保证所有RT优化活动产生的磁盘IOPS(每秒I/O次数)不会超过配置的限制。限制rt_merge_iops可以减少合并导致的搜索性能下降。
- Example
rt_merge_iops = 40RT块合并线程允许启动的最大I/O操作大小。可选,默认值为0(无限制)。
此指令允许限制由 OPTIMIZE 语句引起的I/O影响。超过此限制的I/O操作将被拆分成两个或更多I/O操作,这些操作将作为独立I/O计入rt_merge_iops限制。因此,保证所有优化活动每秒产生的磁盘I/O不超过 (rt_merge_iops * rt_merge_maxiosize) 字节。
- Example
rt_merge_maxiosize = 1M防止在旋转包含大量数据以进行预缓存的表时,searchd 停顿。可选,默认值为1(启用无缝旋转)。在Windows系统上,默认禁用无缝旋转。
表可能包含需要预缓存到RAM中的数据。目前,.spa、.spb、.spi 和 .spm 文件会被完全预缓存(它们分别包含属性数据、blob属性数据、关键字表和已删除行映射)。无无缝旋转时,旋转表尽量少用RAM,流程如下:
- 临时拒绝新查询(返回“重试”错误码);
searchd等待所有正在运行的查询完成;- 旧表被释放,其文件被重命名;
- 新表文件被重命名,分配所需RAM;
- 新表属性和字典数据预加载到RAM;
searchd恢复从新表服务查询。
但如果属性或字典数据量大,预加载步骤可能耗时显著——预加载1-5GB以上文件时可能需要几分钟。
启用无缝旋转后,旋转流程如下:
- 分配新表RAM存储;
- 异步预加载新表属性和字典数据到RAM;
- 成功时,释放旧表,重命名两个表的文件;
- 失败时,释放新表;
- 任何时刻,查询要么从旧表,要么从新表副本服务。
无缝旋转代价是旋转期间峰值内存使用增加(因为预加载新副本时,旧副本和新副本的 .spa/.spb/.spi/.spm 数据都需在RAM中)。平均使用量保持不变。
- Example
seamless_rotate = 1此选项指定二级索引使用的块缓存大小。可选,默认8MB。当二级索引处理包含大量值的过滤器(例如IN()过滤器)时,会读取并处理这些值的元数据块。 在连接查询中,这一过程会对左表的每个批次重复执行,每个批次可能在单个连接查询内重复读取相同元数据。这会严重影响性能。元数据块缓存将这些块保存在内存中,以便后续批次重用。 缓存仅在连接查询中使用,对非连接查询无影响。注意,缓存大小限制是针对每个属性和每个二级索引的。每个磁盘块中的每个属性都在此限制内运行。最坏情况下,总内存使用量可估算为限制乘以磁盘块数和连接查询中使用的属性数。
设置 secondary_index_block_cache = 0 可禁用缓存。
secondary_index_block_cache = 16M
- Example
This 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 [https://github.com/manticoresoftware/columnar] % 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 hints
-
1: Enable the use of secondary indexes on search. They can be disabled for individual queries using analyzer hints -
force: 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.secondary_indexes = 1
- Example
Integer 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.server_id = 1
- Example
`searchd --stopwait` waiting time, in seconds (or %special_suffixes [../Server_settings/Special_suffixes.md] %). 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
SHA1 hash of the password required to invoke the 'shutdown' command from a VIP Manticore SQL connection. Without it,%debug [../Reporting_bugs.md#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.
snippets_file_prefix = /mnt/common/server1/
- Example
### sphinxql_statePath 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.
sphinxql_state = uservars.sql
- Example
Maximum time to wait between requests (in seconds, or %special_suffixes [../Server_settings/Special_suffixes.md] %) when using the SQL interface. Optional, default is 15 minutes.sphinxql_timeout = 15m
- Example
Path 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 格式。
服务器使用此证书作为自签名公钥,通过 SSL 加密 HTTP 流量。该文件必须是 PEM 格式。
服务器使用此私钥通过 SSL 加密 HTTP 流量。该文件必须是 PEM 格式。
此设置限制公共子树优化器的内存使用(参见 multi-queries)。最多将使用这么多内存来缓存每个查询的文档条目。将限制设置为 0 会禁用优化器。
此设置限制公共子树优化器的内存使用(参见 multi-queries)。最多将使用这么多内存来缓存每个查询的关键字出现(命中)。将限制设置为 0 会禁用优化器。
- Example
Manticore 守护进程的工作线程数(或线程池大小)。Manticore 启动时创建此数量的操作系统线程,这些线程执行守护进程内的所有任务,如执行查询、创建摘要等。一些操作可能被拆分为子任务并行执行,例如:- 在实时表中搜索
- 在由本地表组成的分布式表中搜索
- 轮询查询调用
- 以及其他 默认情况下,线程数设置为服务器的 CPU 核心数。Manticore 启动时创建线程并保持运行直到停止。每个子任务在需要时可以使用其中一个线程。子任务完成后释放线程,供其他子任务使用。 在密集 I/O 类型负载的情况下,设置的线程数高于 CPU 核心数可能更合理。 threads = 10
- Example
Example📋作业的最大栈大小(协程,一个搜索查询可能导致多个作业/协程)。可选,默认值为 128K。每个作业有自己的 128K 栈。运行查询时,会检查所需的栈大小。如果默认的 128K 足够,则直接处理。如果需要更多,则调度另一个具有更大栈的作业继续处理。此设置限制了此类扩展栈的最大大小。
将此值设置为合理较高的数值,有助于处理非常深的查询,而不会导致整体内存消耗过高。例如,设置为 1G 并不意味着每个新作业都会占用 1G 内存,而是如果发现作业需要 100M 栈,则只分配 100M。其他作业同时使用默认的 128K 栈。以此类推,我们可以运行需要 500M 的更复杂查询。只有当内部检测到作业需要超过 1G 栈时,才会失败并报告 thread_stack 设置过低。
然而,实际上,即使是需要 16M 栈的查询通常也过于复杂,解析耗时且资源消耗大。因此,守护进程会处理它,但通过
thread_stack设置限制此类查询是合理的。thread_stack = 8M
- Example
Example📋确定是否在成功轮换后取消链接 `.old` 表副本。可选,默认值为 1(执行取消链接)。unlink_old = 0
- Example
Example📋线程化服务器看门狗。可选,默认值为 1(启用看门狗)。当 Manticore 查询崩溃时,可能导致整个服务器宕机。启用看门狗功能后,
searchd还维护一个独立的轻量级进程,监控主服务器进程,并在异常终止时自动重启。看门狗默认启用。watchdog = 0 # disable watchdog
When a Manticore query crashes, it can take down the entire server. With the watchdog feature enabled,
searchdalso maintains a separate lightweight process that monitors the main server process and automatically restarts it in case of abnormal termination. The watchdog is enabled by default.- Example
Example📋watchdog = 0 # disable watchdog