日期:2014-05-16  浏览次数:20833 次

sphinx遭遇sql_range_query: MySQL server has gone away错误
Coreseek一直运行的好好的,但最近有些搜索不到了,重建次索引也不行。

仔细查看了运行提示,如下
Coreseek Fulltext 3.2 [ Sphinx 0.9.9-release (r2117)]
Copyright (c) 2007-2010,
Beijing Choice Software Technologies Inc (http://www.coreseek.com)

using config file '/usr/local/coreseek/etc/csft.conf'...
indexing index 'hx_line'...
ERROR: index 'hx_line': sql_range_query: MySQL server has gone away (DSN=mysql://root:***@localhost:3306/hx_db).
total 302579 docs, 14798361 bytes
total 33.659 sec, 439652 bytes/sec, 8989.49 docs/sec
total 0 reads, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
total 242 writes, 0.572 sec, 1021.9 kb/call avg, 2.3 msec/call avg


错误提示是这个:
sql_range_query: MySQL server has gone away

在SE中搜索未果,看来没人碰上过这问题啊!

我是有使用sphinx的分区查询功能,设置了sql_range_step和sql_ranged_throttle。尝试调整这两个参数运行,但都不行。
每次都是索引到30w的文档时,卡住约10多秒,然后就显示上面的内容了。

想到我的mysql的配置有设置超时时间,应该是这个配置影响了它吧。
wait_timeout=8
interactive_timeout=8

在csft.conf中,加入
sql_query_pre= set session wait_timeout = 60;
sql_query_pre= set session interactive_timeout=60;

后,运行
bin/indexer hx_line --rotate


同样运行到30w之后,停住了约十几秒,然后又继续了:)
问题解决了!

那么为什么运行到30w时会卡住呢?猜测是我设置的mem_limit=512M的问题,难道是设置太小了?再仔细看了文档,找到答案了
mem_limit 索引过程内存使用限制.可选选项,默认 32M. 这是 indexer 不会超越的强制内存限制.可以以字节,千字节(以 K 为后缀)或兆字节(以 M 为后缀)为单位.参见示例.当过小的值导致 I/O 缓冲低于 8KB 时该限制会自动提高,此 值的最低限度依赖于待索引数据的大小.如果缓冲低于 256KB,会产生警告. 最大可能的限制是 2047M.太低的值会影响索引速度,但 256M 到 1024M 对绝大多数数据 集(如果不是全部)来说应该足够了.这个值设得太高可能导致 SQL 服务器连接超时.在文档收集阶段,有时内存缓冲的一部分会被排序,而与数据库的通信会暂停,于是数据库服务器可能超时.这可以通过提高 SQL 服务器端的超时时间或降低 mem_limit 来解决.



原来居然是因为mem_limit这个值设高了。。。!在文档收集阶段,有时内存缓冲的一部分会被排序,而与数据库的通信会暂停,所以看到了运行到30w时卡住的情况,然后化了十几秒,超过了我设置的8s的限制,所以报MySQL server has gone away了。