☰

Sphinx 搜索在“致命：接受（）失败：打开文件太多”后关闭

tag-icon • tag-icon linux filesystems files
Sphinx 搜索在“致命：接受（）失败：打开文件太多”后关闭

我正在运行 Linux CentOS 的 Amazon EC2 上运行 Sphinx Search Server V2.06（最新的稳定版本）。一般来说，它运行良好，但 searchd.log 一遍又一遍地显示此错误，重复次数不同：

send() failed: 32: Broken pipe
WARNING: last message repeated 6 times

我认为这是某种失去连接的情况（基于一些 Sphinx 论坛的回复）。我想解决这个问题，但这不是我们主要关心的问题......但可能相关。 Sphinx 运行一段时间后，或者在重负载下（据我所知），“消息重复”的次数会上升并达到峰值 100。通常大约在同一时间会发生以下致命错误，并且它会关闭 Sphinx：

FATAL: accept() failed: Too many open files

我已经考虑提高系统上的文件限制，但不确定到底该怎么做。这是我的系统当前报告的内容。我仍然看到这个错误。

sysctl fs.file-max ... returns ... fs.file-max = 7017952
ulimit -a ... returns ... open files 1024
ulimit -Hn ... returns ... 4096
ulimit -Sn ... returns ... 1024

我真的不知道这些不同的数字意味着什么，但我认为它们可以用来解决我的问题本文。如何修复 sphinx 致命错误并确保系统在重新启动后保持此“固定”配置？

答案1

让我们从一些有用的文章开始

再加上您已经列出的那个。

基本上它告诉你的是：

  • 每个系统打开文件描述符的最大数量：7017952
  • ulimit -a：允许 shell 打开并启动的进程的最大文件描述符数
  • ulimit -Sn：与上面相同，但仅显示文件描述符最大数量的软限制
  • ulimit -Hn：显示会话打开文件描述符的硬限制

基本上，您需要做的是查看lsof流程的输出，看看它在哪里被卡住。您可以向上或向下更改软限制，以更改会话期间打开的文件描述符的可能数量。硬限制你只能降低，但只有 root 可以增加。

所以我建议看看：

sysctl fs.file-nr

这将为您提供系统上打开和未使用的文件描述符的总数以及输出

lsof -p <pid>

<pid>有问题的进程在哪里，可以确定该进程打开了多少个文件和套接字，并查看是否达到了限制。

答案2

创建一个名为/etc/security/limits.d/99-searchd.conf以下内​​容的文件：

searchd      hard    nofile  16384
searchd      soft    nofile  8192

然后重新启动服务或重新启动。

相关内容