"치명적: accept() 실패: 열린 파일이 너무 많습니다." 이후 Sphinx 검색이 종료됩니다.

"치명적: accept() 실패: 열린 파일이 너무 많습니다." 이후 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

이 서로 다른 숫자가 무엇을 의미하는지 잘 모르겠지만 내 문제를 해결하는 데 사용할 수 있을 것 같습니다.이 기사. 스핑크스의 치명적인 오류를 수정하고 시스템이 재부팅 시에도 이 "고정된" 구성을 유지하는지 확인하는 방법은 무엇입니까?

답변1

유용한 기사부터 시작해 보겠습니다.

게다가 이미 나열한 것.

기본적으로 이것이 말하는 내용은 다음과 같습니다.

  • 시스템당 최대 열린 파일 설명자 수: 7017952
  • ulimit -a: 쉘이 열고 시작하도록 허용된 최대 파일 설명자 수입니다.
  • ulimit -Sn: 위와 동일하지만 최대 파일 설명자 수에 대한 소프트 제한만 표시합니다.
  • ulimit -Hn: 세션에 대해 열린 파일 설명자의 하드 제한을 표시합니다.

기본적으로 당신이 해야 할 일은 lsof프로세스의 출력을 살펴보고 그것이 어디서 멈추는지 확인하는 것입니다. 소프트 제한을 위아래로 변경하여 세션 중에 열려 있는 파일 설명자의 가능한 수를 변경할 수 있습니다. 하드 제한은 낮출 수만 있고 루트만 늘릴 수 있습니다.

따라서 다음을 살펴보는 것이 좋습니다.

sysctl fs.file-nr

그러면 출력과 함께 시스템에서 열려 있고 사용되지 않은 파일 설명자의 총 개수가 제공됩니다.

lsof -p <pid> 

<pid>문제가 있는 프로세스가 있는 경우 프로세스에서 열려 있는 파일 및 소켓 수를 확인하고 제한에 도달했는지 확인할 수 있습니다.

답변2

/etc/security/limits.d/99-searchd.conf다음 내용으로 이름이 지정된 파일을 만듭니다 .

searchd      hard    nofile  16384
searchd      soft    nofile  8192

그런 다음 서비스를 다시 시작하거나 재부팅하십시오.

관련 정보