初步看了就是死锁吧，反正并发越来越高，所有任务处理不完，直到内存耗尽。 下一步继续优化一下线程检测再看看吧，短时间你就自己定时重开服务吧。只要杀掉 xs-searchd子进程即可。
那我下次死的时候，就用这个方法查一下吧，不过现在我通过top查看到有三个 xs-searchd的进程 这个正常吗
我的问题也是一样。目前我们网站所有页面都会有使用到xunsearch的查询。不过我发现一个奇怪的现象，就是searchd.log接近1G的时候，就会出现这样的错误。今天刚刚增加了一个自动清理searchd.log的脚本，看看是否会稳定一些。
停止服务时是 searchd 非常慢还是 indexd 非常慢呢？ 你的日志是发生卡死时的日志吗，indexd.log 里看到你更新并发有 20 个，为什么会这么多？可否进一步优化，但并没有异常。 搜索进程看不出有异样。 下次出错时我希望你可以 ...
照这方法还是不行，不死机，Process 14193 attached - interrupt to quit futex(0x8063c48, FUTEX_WAIT_PRIVATE, 18, NULL [hr] 照这方法还是不行，不死机，Process 14193 attached - interrupt to quit futex(0x8063c48, FUTEX_WAIT_PRIVATE, 18, NULL
并发一般设多少比较合适， 我通过任务，每隔10分钟检测一下数据库有没有新的数据，有数据的话，通过 index_put($index)来提交一次索引，所以我每一次提交20个数据，如果我设少了，那十分钟内如果有30个资料的更新，那索引就...
并发一般设多少比较合适， 我通过任务，每隔10分钟检测一下数据库有没有新的数据，有数据的话，通过 index_put($index)来提交一次索引，所以我每一次提交20个数据，如果我设少了，那十分钟内如果有30个资料的更新，那索引就...
futex(0x8063c48, FUTEX_WAIT_PRIVATE, 18, NULL 不动是引起死锁了，这个问题偶尔是有出现。请问你当时的访问并发数比较高吗？建议尝试以下改法观察一两天。 修改 bin/xs-ctl.sh 第 79 行加入红色部分强制只开一个工作进程 bin/xs-searchd -l tmp...
用了这些方法还是死机 [root@edu ~]# strace -p 23786 Process 23786 attached - interrupt to quit rt_sigsuspend(~[HUP INT QUIT ILL TRAP ABRT BUS FPE KILL SEGV ALRM TERM CHLD STOP TSTP XCPU RTMIN RT_1] Process 23786 detached [root@edu ~]# strace -p 4514 Process 4514 attached - interrupt to q...