Ulimit 오류를 해결하는 방법

최근에 매우 흥미로운 문제에 직면했습니다. 자주 문제가 발생하는 HAProxy 그룹이 있습니다. 서버에 로그인하여 CPU, 메모리, 네트워크, IO를 확인합니다. 결국 머신의 TIME_WAIT 상태에서 60,000개 이상의 연결이 있었던 것으로 밝혀졌습니다.

TIME_WAIT 상태는 일반적으로 HAProxy 및 Nginx와 같은 프록시 시스템에 표시되며 주로 빈번한 활성 종료로 인해 발생합니다. 재사용 및 재활용 매개변수를 수정하면 문제가 상대적으로 빠르게 해결될 수 있습니다.

네트워크 상태 통계는 다음 명령을 사용하여 계산할 수 있습니다.

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}' ESTABLISHED 70 FIN_WAIT2 30 CLOSING 33 TIME_WAIT 65520

이에 대해 마법 같은 것은 없지만 65535라는 숫자는 정말 너무 민감합니다. 그것은 일종의 상한선을 촉발했을 것입니다.

우리를 더욱 당황하게 만드는 것은 TIME_WAIT 상태의 연결이 65535에 도달하는데 왜 서비스를 사용할 수 없는 걸까요?

머신당 수백만 개의 연결이 있다는 주장은 왜 문제에 맞서지 못하는 걸까요? ?

65535는 2의 16승에서 1을 뺀 것과 같다는 뜻으로 마법의 숫자입니다. 이 작은 숫자는 잠시 제쳐두고 먼저 Linux가 지원하는 연결 용량이 얼마나 되는지 이해해 보겠습니다.

1. Linux는 몇 개의 연결을 지원할 수 있나요?

답은 셀 수 없이 많습니다. 하지만 포트는 65535개 밖에 없습니다.

포트가 65535개밖에 없는 이유는 무엇입니까?

TCP와 UDP 프로토콜은 각각 원본 포트 번호와 대상 포트 번호를 저장하기 위해 처음에 16비트를 사용합니다. 안타깝게도 이 값은 short 유형이고 크기도 2^16-1입니다.

역사적인 이유로 인한 불변의 기준은 너무나 뿌리 깊습니다.

그렇다면 Linux는 몇 개의 연결을 지원할 수 있습니까? 대답은 셀 수 없이 많습니다.

nginx를 예로 들면 포트 80에서 모니터링합니다. 이때 머신 A는 Nginx에 연결되며 최대 60,000개의 긴 연결을 시작할 수 있습니다. 머신 B가 Nginx에 연결되면 60,000개의 다중 연결을 시작할 수도 있습니다. 연결 결정은 src와 dst에 의해 결정되기 때문입니다.

Linux가 65535개의 연결만 허용할 수 있다는 생각은 매우 피상적인 가정이라고 할 수 있습니다.

65535 포트, 스트레스 테스터로서는 너무 작을 수 있습니다. 그러나 서버의 경우 이것만으로도 충분합니다.

2. 수백만 개의 연결을 지원하는 방법은 무엇입니까?

위에서 볼 수 있듯이 연결 수에는 제한이 없습니다. 그러나 Linux에는 파일 핸들 수라는 또 다른 보호 계층이 있습니다. lsof 명령을 통해 보이는 것들이 소위 파일 핸들입니다.

먼저 몇 가지 명령 표시를 살펴보겠습니다.

ulmit, 각 프로세스가 점유할 수 있는 파일 핸들 수를 표시합니다.

ulimit -n 65535

file-max는 모든 프로세스에 대해 운영 체제가 점유할 수 있는 총 파일 핸들 수를 표시합니다.

cat /proc/sys/fs/file-max 766722

file-nr, 현재 사용 중인 핸들 수와 총 핸들 수를 표시합니다. 모니터링에 사용할 수 있습니다.

cat /proc/sys/fs/file-nr 1824  0 766722

수백만 개의 연결을 지원하려면 운영 체제 수준 핸들과 프로세스 수준 핸들을 출시해야 합니다. 즉, ulimit 및 file-max의 표시는 100만보다 커야 합니다.

3. 어떻게 설정하나요?

일반적으로 사용되는 솔루션은 프로세스 핸들 수를 설정하는 ulimit이지만 권장하지 않습니다. 다른 이유 없이 동일한 셸에서 시작된 프로세스만 ulimit 설정의 영향을 받습니다. 다른 셸을 열거나 시스템을 재부팅하면 ulimit 변경 사항이 사라집니다.

ulimit -n 1000000

올바른 방법은 /etc/security/limits.conf 파일을 수정하는 것입니다. 예를 들면 다음과 같은 내용입니다.

root soft nofile 1000000 root hard nofile 1000000 * soft nofile 1000000 * hard nofile 1000000

특정 사용자에 대한 핸들 수를 수정할 수 있음을 알 수 있습니다. 이는 es와 같은 응용 프로그램을 설치할 때 자주 발생합니다.

es  -  nofile  65535

이 방법을 사용하더라도 작동하려면 새 셸을 열어야 합니다. 이 명령은 수정된 셸이나 수정 전 셸에서는 적용되지 않습니다. xjjdog에서는 제한이 해제되었음에도 불구하고 여전히 문제가 발생하는 여러 사례를 접했습니다.

프로세스의 메모리 매핑 파일을 보고 이러한 변경 사항이 적용되었는지 확인하세요. 예를 들어, "cat /proc/180323/limits" 명령을 실행하면 자세한 정보가 표시됩니다.

이 값은 원하는만큼 높게 설정되지 않았습니다. 크기의 상한은 nr_open에 의해 결정됩니다. 크기를 늘리려면 /ect/sysct.conf에서 fs.nr_open 값을 변경하십시오.

cat /proc/sys/fs/nr_open 1048576

file-max 매개변수를 수정하려면 /etc/sysctl.conf 파일에 다음 내용을 추가하는 것이 좋습니다. 6백만 개가 넘습니다!

fs.file-max = 6553560

파일 개수를 초과하면 오류 커널: VFS: file-max Limit 65535reach가 보고됩니다.

요약하자면.

Linux가 포트를 열더라도 엄청난 수의 연결을 받아들일 수 있습니다. 이러한 연결의 상한은 단일 프로세스의 파일 핸들 수와 운영 체제의 파일 핸들 수, 즉 ulimit 및 file-max에 의해 제한됩니다.

매개변수 수정 사항을 유지하기 위해 변경 사항을 파일에 기록하는 경향이 있습니다. 프로세스의 파일 핸들 제한은 /etc/security/limits.conf에 배치될 수 있으며, 그 상한은 fs.nr_open에 의해 제한됩니다. 운영 체제의 파일 핸들 제한은 /etc/sysctl.conf에 배치될 수 있습니다. 파일. 마지막으로 /proc/$id/limits 파일을 확인하여 수정 사항이 프로세스에 적용되었는지 확인하세요.

위 내용은 Ulimit 오류를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!