☰

OS X/MacOS/BSD 최대 파일 크기 설정

tag-icon • tag-icon osx bsd ulimit
OS X/MacOS/BSD 최대 파일 크기 설정

내 OS X 컴퓨터에 프로세스당 허용되는 열린 파일 수를 추적할 수 있는 문제가 있습니다. maxfiles명령 보기 옵션을 사용하는 경우 launchctl( limit내 OS X El Cap 시스템에서)

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    256            unlimited

소프트 제한은 256이고 하드 제한은 "제한 없음"인 것 같습니다. 소프트 제한을 비슷한 값으로 변경 2048하고 하드 제한은 동일하게 유지하고 싶습니다 . limit그들의 주장을 보면

$ launchctl help limit
Usage: launchctl limit [<limit-name> [<both-limits> | <soft-limit> <hard-limit>]

같은 것에 대해 두 가지 제한을 설정할 수 있는 것 같습니다.또는소프트 및 하드 값을 설정합니다. 하지만 제한이 없는 엄격한 제한을 설정하려고 하면

$ sudo launchctl limit maxfiles 2048 unlimited

나는 이상한 값 10240으로 끝났습니다.

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    2048           10240

여기서 무슨 일이 일어나고 있는 걸까요? 값을 무제한으로 설정할 수 있나요? 그렇지 않은 경우 이는 명령의 제한사항입니까 launchctl limit, 아니면 시스템 수준 제한사항입니까? 후자의 경우 unlimited보고서의 초기 값은 무엇입니까? 아니면 이 사과는 그냥 사과일까요?

보너스 포인트의 경우 - 애초에 이 한도가 왜 그렇게 낮게 설정되어 있는지 아는 사람이 있나요?

답변1

이것이 XNU, FreeBSD, TrueOS 및 OpenBSD의 공통점입니다. 안 돼요제한 없는열린 파일 설명자에 대한 하드 및 소프트 제한. 다양한 운영 체제 커널은 특정 동작이 다양하지만 RLIMIT_NOFILES이 기능에 대한 제한 설정을 허용하지 않습니다.RLIM_INFINITYsetrlimit()

이것은 이 모든 것에서 완전히 문서화되지 않았습니다.

문서화되지 않은 동작은 데이터 세그먼트, 스택 세그먼트, 사용자당 최대 프로세스 수 및 최대 열린 파일 설명자 수에 대한 소프트 및 하드 제한이 모두 sysctl다양한 커널 변수의 값에 의해 제한된다는 것입니다. 커널 변수가 각 제한으로 제한되는 것과 같은 세부 사항은 운영 체제에 따라 다릅니다.

  • XNU에서 권한이 있는 프로세스는 열린 파일 설명자 제한을 kern.maxfiles커널 변수보다 높게 설정할 수 없습니다. 권한이 없는 프로세스는 열린 파일 설명자 제한을 kern.maxfilesperproc커널 변수보다 높게 설정할 수 없습니다. 코드는 다음과 같습니다.
  • FreeBSD 및 TrueOS에서 프로세스는 열린 파일 설명자 제한을 kern.maxfilesperproc커널 변수보다 높게 설정할 수 없습니다. 코드는 다음과 같습니다.
  • OpenBSD에서 프로세스는 열린 파일 설명자 제한을 kern.maxfiles커널 변수보다 높게 설정할 수 없습니다. 코드는 다음과 같습니다.

이 모든 것에도 모자는 침묵합니다. 이 setrlimit()호출은 오류를 반환하지 않습니다. 프로그램에서 요구하는 값보다 하한값을 간단하고 조용히 설정합니다. (XNU에는 "POSIX 모드"가 있습니다.부드러운상한을 초과하여 제한합니다. 하지만 설정딱딱한그렇게 하면 다른 운영 체제와 마찬가지로 제한이 자동으로 제한됩니다. ) 프로그램이 제한 적용을 비활성화하려고 시도하는 경우 이러한 운영 체제에서는 제한 상한 값이 운영 체제 수준에서 계속 적용됩니다.

RLIM_INFINITY엄밀히 말하면 이는 오류가 반환되지 않고 해당 동작을 자동으로 제공하지 않는 것을 요구하고 제공하지 않는 단일 Unix 사양을 위반하는 것입니다 .

RLIM_INFINITY성공적인 호출에 지정된 리소스 제한 값은 setrlimit()해당 리소스 제한 적용을 비활성화합니다.

launchctl limitlaunchd매뉴얼에 나와 있듯이 이 명령은 프로세스가 setrlimit()자체 프로세스 리소스 제한을 설정하도록 호출하도록 지시하는 방법일 뿐입니다 . 그래서 당신이 보는 것은 launchd과정 입니다시작열린 파일 설명자 수에 대해 무한한 하드 제한을 두고, 그런 다음 유한한 제한을 받고, kern.maxfilesperproc열린 파일 설명자 수에 대해 무한한 하드 제한을 둔 다음 첫 번째 시도에서놓다하드 오픈 파일 설명자 제한은 무제한입니다.

(FreeBSD/TrueOS에서도 같은 일이 발생합니다. 여기서 프로세스 #1은 열린 파일 설명자의 높은 하드 제한으로 시작하고 프로세스 #1 프로그램은 명시적으로 하드 제한을 하한으로 재설정합니다.

(실제로 GNOME 터미널 서버 프로세스가 초기에 상위 프로세스로부터 열린 파일 설명자에 대한 엄격한 제한을 상속받는 운영 체제에서 발생하는 경우 터미널 세션을 시작할 수 없게 되는 매우 성가신 버그가 GNOME 터미널에 있습니다. kern.maxfiles현재 값이 / 보다 높으면 이 오류가 발생할 수 있습니다 kern.maxfilesperproc. 그놈 터미널 작성자는 원래 치명적인 오류를 읽은 것과 동일한 값으로 하드 제한을 설정하지 못한 것으로 간주합니다., GNOME 터미널이 XNU/BSD 동작을 트리거하여 자동으로 하드 제한을 낮추어 코드가 결국 시도하게 한다는 점을 고려하지 않고증가하다그것은, 실패의 이유이다. )

kern.maxfilesperproc10240은 XNU의 커널 변수에 대해 컴파일된 초기 값 입니다 . 그러나 그렇지 않습니다.상당히그렇게 간단합니다. 시스템 부팅 시 서버 성능 모드에 있을 때,XNU는 이 변수를 스케일 값의 75000배로 초기화합니다..

관련 정보