주기적으로 파일 수를 계산하고 여는 데몬을 실행하고 있습니다. 또한 이러한 파일의 데이터를 네트워크를 통해 다양한 클라우드 제공업체에 복사합니다. 데몬은 단일 프로세스로 실행됩니다. 프로세스가 시작된 후 열린 파일 제한을 시스템 기본값인 1024에서 32768로 늘렸습니다 prlimit --pid <the process id> --nofile=32768:32768. 하드 및 소프트 파일 제한이 실제로 업데이트되었음을 확인했습니다.
노트lsof: 현재 열려 있는 파일을 참조한다는 것은 다른 창( )에서 계속해서 실행하여 반환되는 값을 말하는 것입니다 while [ true ]; do sudo lsof -p <the process id> | wc -l; done;. 이것은 단순한 추측이 아닙니다.
서버는 한동안 문제 없이 실행되었으며, 부하가 심한 경우에도 3500개 미만의 파일이 열려 있었습니다. 그러나 때로는 보통 로드에서 수백 개의 파일만 열려 있는 경우(500개 미만) 프로세스에서 소켓 생성, 파일 열기, 파일 개수 계산 등을 시도할 때 "열린 파일이 너무 많습니다"라는 오류가 발생하기 시작합니다.
소프트 제한이 32768이고 실제로는 수백 개의 파일만 열린 것으로 표시되는 경우에도 "열린 파일이 너무 많음"을 유발할 수 있다고 생각하지 않은 다른 변수/제한이 있습니까?
관련 정보:
- 레드햇 엔터프라이즈 리눅스 서버 7.6
- 커널 3.10.0-957.el7.x86_64(오래된 것으로 알고 있습니다. 제어할 수 없습니다.)
완전히 명확하게 말하면 커널 자체 기록( 을 통해 lsof)에 따르면 프로세스는 열린 파일을 너무 많이 사용하지 않습니다. 이러한 오류가 발생하기 시작하면 커널은 수백 개의 열린 파일 설명자만 보고합니다(프로세스 제한은 32768입니다).
답변1
내가 왜 이러는지는 모르겠지만, 내가 가장 먼저 하는 일은데몬이 시작되기 전에 ulimit 설정.
답변2
다시 만들다Symcbean의 답변
systemd는 프로세스별로 제한을 처리합니다. 즉, 다른 제한을 무시하므로 실제로 서비스의 단위 파일에서 제한을 구성해야 합니다.
아래는 예입니다:
[Unit]
Description=example systemd service unit file.
[Service]
ExecStart=/bin/bash /usr/sbin/example.sh
LimitNOFILE=32768
[Install]
WantedBy=multi-user.target