1

我们在为我们的一个 MySQL 数据库重建 Sphinx 索引时遇到问题。轮换和重建索引反复失败，系统继续使用旧索引。数据库大小在过去几个月中翻了一番，现在包含超过 1000 万行的表。在重建 Sphinx 索引期间，使用

indexer --config our_config.conf --rotate --all

（由此处使用的 UltraSphinx 插件生成），我们在 Sphinx 守护进程日志文件 searchd.log 中得到以下错误

WARNING: rotating index 'main': preread failed: failed to open 
~/etc/sphinx//sphinx_index_main.new.spi: No such file or directory; 
using old index
WARNING: rotating index 'main': preread failure reported

随着数据库变大，错误消息出现的频率越来越高。完整索引现在需要大约 1 1/2 小时，并且索引文件加起来大于 1 GB。我们将 Sphinx 版本从 0.9.8.1 更新到 2.0.4 以解决这个问题，但它仍然存在。服务器有大约 4 GB 内存，配置文件以

indexer {
  mem_limit = 1024M
}

searchd {
  read_timeout = 5
  max_children = 300
  log = ~/etc/sphinx/log/searchd.log
  port = 3313
  max_matches = 100000
  query_log = ~/etc/sphinx/log/query.log
  seamless_rotate = 1
  pid_file = ~/etc/sphinx/log/searchd.pid
  address = 127.0.0.1
}
..

有谁知道如何解决这个问题？我猜似乎存在某种与 2 GB 限制有关的索引大小限制，这是有符号 32 位整数的最大值和某些文件系统上文件大小的最大值。我们在 Ubuntu/Debian 系统上使用的 ext3 文件系统最多允许 16 GB 的文件，但某些库实际上可能会将文件大小限制为 2 GB（参见此处和此处）。

4

2 回答 2

1

检查索引器本身的输出 - 它显示索引期间的进度，并可能提供有关问题的线索。

于 2012-04-24T18:58:00.637 回答
0

请检查您的数据位置。看起来 Sphinx 想要在~/etc/sphinx//sphinx_index_main.new.spi. 我在这里看到两件事，一个是〜，不确定这是否有效。另一件事是 double /。

IIRC 这是您的 Sphinx 配置文件的索引部分。

于 2012-04-24T18:28:12.930 回答