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