Sphinx全文检索引擎使用指南:searchd程序配置选项

摘自http://www.ithov.com/

Sphinx是一个基于SQL的全文检索引擎,可以结合MySQL,PostgreSQL做全文搜索

8.4.1. address

要绑定的接口 IP地址。可选项,默认为0.0.0.0(即在所有接口上监听)。

此设置指定searchd在哪个接口上绑定、监听和接受输入的网络连接。默认值为0.0.0.0,意思是在所有接口上监听。目前不能指定多个接口。

示例:

address = 192.168.0.1

8.4.2. port

searchd的TCP端口号。必选项,默认为3312。

示例:

port = 3312

8.4.3. log

日志文件名。可选项,默认为“searchd.log”。全部 searchd运行时事件会被记录在这个日志文件中。

示例:

log = /var/log/searchd.log

8.4.4. query_log

查询日志文件名。可选项,默认为空(不记录查询日志)。全部搜索查询会被记录在此文件中。其格式在节 4.8, “searchd 查询日志格式” 中描述

示例:

query_log = /var/log/query.log

8.4.5. read_timeout

网络客户端请求的读超时时间,单位是秒。可选项,默认是5秒。searchd强制关闭在此时间内未能成功发出查询的客户端连接。

示例:

read_timeout = 1

8.4.6. max_children

子进程的最大数量(或者说,并行执行的搜索的数目)。可选项,默认为0,不限制。

用来控制服务器负载。任何时候不可能有比此设置值更多的搜索同时运行。当达到限制时,新的输入客户端会被用临时失败(SEARCH_RETRY)状态码驳回,同时给出一个声明服务器已到最大连接限制的消息。

示例:

max_children = 10

8.4.7. pid_file

searchd进程ID文件名。必选项。

PID文件会在启动时重建(并锁定)。主守护进程运行时它含有该进程的ID,而当守护进程退出时该文件会被删除。这个选项是必须的,因为Sphinx在内部使用它做如下事:检查是否已有一个searchd示例;停止 searchd;通知searchd应该轮换索引了。也可以被各种不同的外部自动化脚本所利用。

Example:

示例:

pid_file = /var/run/searchd.pid

8.4.8. max_matches

守护进程在内存中为每个索引所保持并返回给客户端的匹配数目的最大值。可选选项,默认值为1000.

引入此选项是为了控制和限制内存使用,max_matches设置定义了搜索每个索引时有多少匹配项会保存在内存中。每个找到的匹配项都会被处理,但只有它们中最佳的N个会在内存中保持并最终返回给客户端。假设索引中包括 2000000个当前查询的匹配项,你几乎总是不需要它们中的全部。通常您需要扫描它们并根据某种条件(即按相关度排序、或者价格、或者其他什么)选出最好的那些,比如500个,并以在页面上显示 20到100项。只跟踪最好的 500个匹配要比保持全部的2000000个匹配项大大地节约内存和CPU,之后可以对这些最佳匹配排序,然后丢弃除了要在页面上要显式的20项之外的结果。max_matches控制“最佳 N个匹配”中的N。

此参数明显影响每个查询消耗的内存和CPU。1000到10000的值通常就可以满足需求,但更高的值要小心使用。粗心地把 max_matches增加到1000000意味着 searchd被迫为每一个查询分配1M条匹配项的缓冲。这会明显增大查询的内存消耗,有时会明显影响性能。

特别注意!此限制还可在另一个地方指定。max_matches可以通过 对应的API调用 实时降低,该调用的默认值也是1000。因此要使应用程序获取超过1000个匹配结果,必须修改配置文件,重启 searchd,再用SetLimits()调用设置合适的限制。还要注意,API调用设置的限制不能大于.conf文件中的设置,这是为了预防恶意的或错误的请求。

示例:

max_matches = 10000

8.4.9. seamless_rotate

防止 searchd轮换在需要预取大量数据的索引时停止响应。可选选项,默认为1(启用无缝(seamless)轮换)。

索引可能包含某些需要预取到内存中的数据。目前.spa,.spi和.spm文件会被完全预取到内存中(它们分别包含属性数据,MVA数据和关键字索引)。若无无缝轮换,轮换索引时会尽量使用较小的内存,并如下工作:

1. 新的查询暂时被拒绝(用“retry”错误码)

2. searchd等待目前正在运行的查询结束

3. 旧的索引被释放,文件被重命名

4. 新的索引文件被重命名,分配所需的内存

5. 新的索引属性和字典数据预调进内存

6. searchd恢复为新索引提供查询服务

然而,如果有大量的属性或字典数据,那么预调数据的步骤可能消耗大量的时间——预调1.5GB的文件可能需要几分钟的时间。 当启用了无缝轮换,轮换按如下工作:

1. 为新索引分配内存

2. 新索引的属性和字典数据异步地预调进内存

3. 如果成功,旧的索引被释放,新旧索引文件被重命名

4. 如果失败,释放新索引

5. 在任意时刻,查询服务都正常运行——或者使用旧索引,或者使用新索引

无缝轮换以轮换过程中更大的峰值内存消耗为代价(因为当预调新索引时.spa/.spi/.spm数据的新旧拷贝需要同时保持在内存中)。平均内存耗用不变。

示例:

seamless_rotate = 1

8.4.10. preopen_indexes

是否在启动是强制重新打开所有索引文件。可选选项,默认为0(不重新打开)。对所有提供服务的索引强制打开 preopen 选项,免得对每个索引手工指定了。

示例:

preopen_indexes = 1

8.4.11. unlink_old

索引轮换成功之后,是否删除以.old为扩展名的索引拷贝。可选选项,默认为1(删除这些索引拷贝)。

示例:

unlink_old = 0

Last modification:January 2nd, 2018 at 12:17 am
If you think my article is useful to you, please feel free to appreciate

Leave a Comment