환경:
저는 CentOS-7을 하이퍼바이저로 사용하고 있습니다 libvirt
. 각 컨테이너는 간단한 FreePBX(Asterisk, Apache, MySQL + 비트)와 함께 CentOS-7의 최소 설치를 실행합니다.
징후:
16개의 컨테이너가 문제 없이 실행되고 있습니다. 컨테이너를 다시 시작하면 시작되지만 17번째 컨테이너가 시작된 후에는 systemctl start/restart/stop <anything>
어떤 컨테이너에서도 다음을 수행할 수 없습니다.
[root@test-lxc ~]# systemctl restart dnsmasq
Error: Too many open files
진단:
17번째 LXC가 실행되고 실패하는 동안 다음 진단 및 계산이 수행되었습니다 systemctl restart blabla
.
LXC에 SSH로 접속하여 ls 등과 같은 가장 기본적인 명령을 실행할 수 있습니다. 나는 이 제한이 systemd
.
나는 어디에서/왜 한계에 부딪혔는지 이해하려고 노력하고 있습니다.
[root@lxc-hypervisor]# sysctl fs.file-nr
fs.file-nr = 29616 0 12988463
이것은 조정되지 않았으며 기본적으로 설치되는 것입니다. 위와 마찬가지로 최대(마지막) 값 = 12988463은 하이퍼바이저에 의해 보고되며 각 LXC 내부에도 있습니다. 30,000 미만의 매우 유사한 첫 번째 값도 각 LXC에서 보고되었습니다.
각 LXC 내 모든 프로세스의 파일 디스크립터 수를 세려고 하면 각 LXC에서 얻는 순서는 400~500입니다.
for pid in $( ls /proc/ | grep -E -e "^[0-9][0-9]*\$" ); do
ls -l /proc/${pid}/fd/ 2> /dev/null | wc -l
done
하이퍼바이저 자체가 없으면 총계는 약 9000(9k)입니다. 하이퍼바이저에서 실행하면 일반적으로 10005와 같이 10000보다 약간 높은 의심스러울 만큼 가까운 값을 얻습니다.
질문:
Q1. 제한사항은 어디에서 설정되거나 상속되나요?
Q2. 제한 사항이 systemctl start/stop/restart blah
명령에 영향을 미치는 이유는 무엇입니까? 하지만 여전히 LXC로 ssh를 통해 루트 권한이기는 하지만 많은 분기 루프가 있는 bash 스크립트와 같은 명령을 실행할 수 있습니다.
Q3. 더 많은 LXC를 실행할 수 있도록 제한을 조정하는 방법. 내가 아는 한 RAM 및 기타 리소스에는 제한이 없습니다.
파일 설명자 제한 주제에 대한 많은 기사와 답변을 읽었지만 내 시스템이 어디에서 제한에 도달했는지는 확인하지 못했습니다.
기타 관련 정보도 환영합니다.
답변1
나는 당신이 글로벌 한도에 도달하지 않았다고 믿습니다.inotify한계. 이는 실행 중인 컨테이너에서 볼 수 있습니다.체계왜냐하면체계사용inotify회계는 편리하지만 호스트도 영향을 받습니다. 컨테이너는 사용되지 않습니다.체계(도 아니다inotify)에는 영향을 미치지 않을 수 있습니다.
/proc/sys/fs/inotify/max_user_instances
:이는 실제 사용자 ID당 생성할 수 있는 inotify 인스턴스 수의 상한을 지정합니다.
루트가 없는 경우(예:뿌리진짜는 컨테이너 안에 있어요뿌리) 컨테이너가 사용 중이면뿌리사용자가 병목 현상을 겪게 됩니다. 여러 컨테이너가 동일한 루트 없는 사용자 매핑을 사용하면 해당 컨테이너에 병목 현상이 발생할 수도 있습니다.뿌리사용자(호스트에는 영향을 주지 않음). 기본값은 128이며 컨테이너 사용에는 너무 적습니다.
CentOS7(또는 Rocky9)에는 LXC에 대한 기본 설정이 포함되어 있지 않습니다.Debian 기반 배포판에는 다음이 포함됩니다.호스트 시스템에 있는 이 파일은 다음과 같습니다.
/etc/sysctl.d/30-lxc-inotify.conf
:
# Defines the maximum number of inotify listeners.
# By default, this value is 128, which is quickly exhausted when using
# systemd-based LXC containers (15 containers are enough).
# When the limit is reached, systemd becomes mostly unusable, throwing
# "Too many open files" all around (both on the host and in containers).
# See https://kdecherf.com/blog/2015/09/12/systemd-and-the-fd-exhaustion/
# Increase the user inotify instance limit to allow for about
# 100 containers to run before the limit is hit again
fs.inotify.max_user_instances = 1024
따라서 호스트 시스템에서 이 파일을 생성하여 동일한 작업을 수행해야 합니다. 즉시 적용됩니다(호스트에서):
sysctl -w fs.inotify.max_user_instances=1024