在本文中，我们将讨论索引如何在启动时加载，以及这对传入查询和搜索实例管理的影响。 在较早的Sphinx版本中，如果设置了preopen选项，索引会被预读并加载到内存中。在此期间，守护进程将拒绝接受任何传入连接。对于小索引来说，这并不是大问题，因为它们加载得很快。但对于需要加载数十甚至数百GB的巨大索引来说，这确实是个问题，因为加载完成可能需要几分钟甚至更长时间。 在 Sphinx 2.3 中，这一点发生了变化：索引文件会通过 mmap 进行 内存映射 ，而不是简单地读取并加载 ...
我们很高兴地宣布 Manticore Search 2.7.2 GA 的发布。 适用于 Debian、Ubuntu、Red Hat/CentOS、Windows 和 OSX 的预构建软件包可以从 这里 下载。对于 Docker 镜像，请查看官方 仓库 。 改进 Manticore Search 现在与 MySQL 8.x 客户端兼容。 TRUNCATE 命令新增可选参数 WITH RECONFIGURE，允许在单个命令中截断并重新配置 RT 索引。 使用 listen 指令中 ...
嘿。只是想给你一个提示，如果你在使用 Unix 套接字与你的 Sphinx / Manticore 实例通信时遇到错误 "FATAL: port 0 is out of range" 应该如何处理。 这里有一个示例： snikolaev@dev:~/dir$ ./searchd -c sphinx.conf Manticore 2.7.1 458e9c6@180704 dev Copyright (c) 2001-2016, Andrew Aksyonoff ...
在本文中，我们将讨论如何从 Sphinx 升级。 Manticore Search 是 Sphinx Search 2.3 的一个分支。虽然代码的许多部分已经 重构 并 改进，但没有需要大量努力才能升级的破坏性变更。在大多数情况下，升级过程与升级 Sphinx 的次要版本相同，这主要只是替换二进制可执行文件。 索引 Manticore 使用与 Sphinx 2.x 相同的索引格式，使用 Sphinx 创建的索引将被 Manticore 守护进程加载。唯一需要重新索引的情况是， ...
在 2.7 中，我们重构了 master daemon 与远程 agents 之间多个通信环节。这些改动属于“底层优化”，用于解决在某些场景下，或在使用带远程节点的分布式索引 且负载较高的部署中会造成明显影响的问题。 异步 DNS 这在使用云基础设施的用户中尤其成为一个问题。在 Linux 系统上，如果可用，守护进程将使用 getaddrinfo_a() 进行异步 DNS 解析。这意味着我们不需要主动等待答案，而是安排任务，当（如果）DNS 返回答案时继续处理，或在一段时间后 ...
直到现在，资源共享都是通过读写锁来实现的。在高负载情况下，使用锁机制在尝试对索引进行修改时可能会遇到问题。为了解决这些问题，我们必须重新思考线程与索引之间的关系。 索引可能很大甚至非常大，它们在多个工作进程中共享。在多核 CPU 上，你可以同时发起许多查询，它们会分布在各个核心上，使用同一个索引。这很简单明了。然而，有时你需要更新索引。无缝切换在旧版 fork 工作进程中表现良好：我们只需加载新的索引文件，让正在运行的 fork 进程继续使用旧索引提供服务。在某一时刻，新查询 ...