Sphinx Search desligando após 'FATAL: accept () falhou: muitos arquivos abertos'

Question

Estou executando o Sphinx Search Server V2.06 (a última versão estável) em um Amazon EC2 com o Linux CentOS. Em geral, ele está funcionando bem, mas o searchd.log está mostrando esse erro repetidamente com um número variável de tempos de repetição:

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

Suponho que isso seja algum tipo de conexão perdida (com base em algumas respostas do fórum Sphinx). Eu gostaria de consertar isso, mas não é nossa principal preocupação ... mas possivelmente relacionada. Depois que a Sphinx estiver funcionando por um tempo, ou sob carga pesada (o mais próximo que eu possa saber), o número de vezes que a mensagem se repete aumenta e atinge o pico em 100. Geralmente, ao mesmo tempo ocorrerá o seguinte erro fatal vai fechar a Esfinge:

FATAL: accept() failed: Too many open files

Procurei aumentar os limites de arquivo do meu sistema, mas não sei exatamente o que fazer. Aqui está o que meu sistema reporta atualmente. Ainda estou vendo esse erro.

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

Eu realmente não sei o que significam esses números diferentes, mas eu acho que eles poderiam ser usados para resolver o meu problema de acordo com este artigo . Como posso corrigir o erro Fatal da Esfinge e garantir que o sistema mantenha essa configuração 'fixa' após uma reinicialização?

    

Answer 1

Vamos começar com alguns artigos úteis

• link
• link
• link
• ulimit: diferença entre os limites hard e soft

Além disso, o que você já listou.

Basicamente, o que você diz é isso:

• Número máximo de descritores de arquivos abertos por sistema: 7017952
• ulimit -a: Número máximo de descritores de arquivos que podem ser abertos por um shell e processados com início
• ulimit -Sn: O mesmo que acima, mas mostra apenas o limite flexível para o número máximo de descritores de arquivos
• ulimit -Hn: mostra limite máximo para descritores de arquivos abertos de sessão

Basicamente, o que você precisa fazer é ver a saída de lsof do seu processo para ver onde ele está ficando preso. Limite suave que você pode alterar para cima ou para baixo para alterar o número possível de descritores de arquivos abertos durante a sessão. Limite rígido você só pode diminuir, mas somente o root pode aumentar.

Por isso, gostaria de sugerir que você analisasse:

sysctl fs.file-nr

que lhe daria o número total de descritores de arquivos abertos e não utilizados no sistema e também a saída de

lsof -p <pid> 

em que <pid> é o processo em questão para determinar quantos arquivos e soquetes esse processo abriu e ver se você está atingindo seu limite.

    

Answer 2

Crie um arquivo chamado /etc/security/limits.d/99-searchd.conf com o seguinte conteúdo:

searchd      hard    nofile  16384
searchd      soft    nofile  8192

, reinicie o serviço ou reinicie.