Linux에서는 이를 허용 ulimit -s unlimited하므로 프로그램이 시스템 메모리를 소모하고 컴퓨터를 충돌시킬 수 있습니다. 그래서 일반적으로 좋지 않습니다.
그러나 현재 8192 기본값의 한계를 크게 늘리면 어떤 단점이 있습니까 limit -s 1048576? 많은 런어웨이 프로그램/스레드가 결합하여 메모리를 소모하는 것 외에 신뢰할 수 있는 시스템에서 어떤 나쁘거나 바람직하지 않은 일이 발생할 수 있습니까?
답변1
ulimit에는 하드 제한과 소프트 제한이 있습니다. 스택 공간의 하드 제한은 일반적으로 더 높습니다. 예를 들어 내 시스템에서는 배포 기본값을 사용합니다.
$ ulimit -S -s
8192
$ ulimit -H -s
unlimited
기본 소프트 제한을 변경할 이유가 없습니다. 이로 인해 메모리가 낭비될 수 있습니다. 스택 공간이 특정 프로세스와 관련된 경우 프로세스의 소프트 제한만 높이는 래퍼 셸 스크립트를 통해 프로세스를 시작해야 합니다. 하드 제한은 시스템 구성의 일부로 전역적으로 또는 사용자/그룹 구성원별로 늘릴 수 있습니다.
실제 리소스 제한이 있는 경우 ulimit에서 제공하는 프로세스별 제한은 실제로 좋은 메커니즘이 아닙니다. Solaris 영역, 제어 그룹(컨테이너) 또는 가상 머신과 같은 다른 기술을 고려해 보겠습니다.
소프트 한도를 높이는 이유가 있나요? 물론, 보유 소프트웨어가 많은 수의 열린 파일을 처리할 수 없기 때문에 파일 설명자 수와 같은 것은 낮게 유지되며, 소프트 제한을 지속적으로 수정해야 하는 것은 사람들에게 성가신 일이 될 수 있습니다.
마지막으로 언급할 가치가 있는 점은 소프트 및 하드 설정 없이 ulimit를 사용하면 실제로 두 설정을 동시에 변경한다는 것입니다. 실수로 하드 제한을 낮추지 않도록 설정을 변경할 때 -S를 사용하는 것이 가장 좋습니다.
이것은 데모입니다.
$ ulimit -n
1024
$ ulimit -H -n
524288
$ ulimit -S -n
1024
$ ulimit -n 2048
$ ulimit -H -n
2048
$ ulimit -S -n
2048