Unix サーバーの管理は、特に管理するシステムが酷使され、パフォーマンスの問題で可用性が低下する場合、困難になる場合があります。 幸い、特定のリソースに制限を設けることで、サーバ上の最も重要なプロセスが実行し続けられるようにし、競合するプロセスがシステム全体にとって良いよりもはるかに多くのリソースを消費しないようにすることができます。 ulimit コマンドは災害を抑えることができますが、どこで制限が意味を持ち、どこで問題を引き起こすかを予測する必要があります。
それほど頻繁に起こることではないかもしれませんが、あまりにも多くのプロセスを開始する単一のユーザーが、他のすべての人にとってシステムを使用不能にすることができます。 フォーク爆弾 (利用可能なリソースが枯渇するまでプロセスが自己を複製し続けるサービス拒否攻撃) は、この最悪のケースとなります。 しかし、友好的なユーザーでさえ、しばしば意図せずに、システムにとって好ましい以上のリソースを使用してしまうことがあります。 同時に、一般ユーザーを想定した制限値に対して、正当なプロセスが実行されると失敗することもあります。 この場合、これらのプロセスが、すべての人が同じリソースを利用できるようにすることなく、適切に実行できるように、システムリソースの割り当てを強化する必要があります。
ログインに関連する制限を確認するには、ulimit -a コマンドを使用します。 通常のユーザー アカウントを使用している場合、次のようなものが表示されます。 実行中のプロセスがアボートしても、コアファイルがホームディレクトリにドロップされることはありません。 コア・ファイル・サイズが0に設定されている限り、コア・ダンプは許可されません。 しかし、アプリケーションで発生した問題をデバッグするためにコアダンプが必要な場合は、コアファイルのサイズを無制限に設定することをお勧めします – そして、おそらくそうすることができます。
$ ulimit -c ulimited$ ulimit -cunlimited
サーバーを管理しており、すべてのユーザーに対してコア ダンプを生成する機能を有効にしたい場合、おそらく開発者はこれらのコア ダンプを分析できることが本当に必要なのですが、ユーザーに root に切り替えて /etc/security/limits.Debian を編集する必要があります。(Linux) または /etc/system (Solaris) ファイルを変更します。
一方、サーバーを管理しており、ユーザーがどれだけコア ダンプを生成したくてもできないようにしたい場合、limits.conf で 0 の制限を設定できます。 このために使用される ulimit オプションは -u です。 ulimit -a コマンドで上で行ったように制限を見ることもできますし、ulimit -u コマンドで “nproc” の制限だけを表示することもできます。
$ ulimit -u50
もう一度言いますが、ユーザーは別の ulimit コマンド — ulimit -u 100 — で制限を変更することができますが、もちろん変更できなければ、その限りではない。 limits.conf やシステムファイルでプロセスを 50 に制限している場合、制限を増やそうとすると次のようなエラーが出ます:
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
制限をグループ別に設定することも可能で、たとえば開発者にはマネージャよりも多くのプロセスを実行する能力を与えることができます。 limits.conf ファイルに次のような行を追加します:
@managers hard nproc 50@developers hard nproc 200
開いているファイルの数を制限したい場合は、別の設定を使用します:
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
ここでは、2 つのグループと 1 人の個人が開いているファイルの制限値を増加させました。 これらはすべてハード制限を設定しています。 ソフトリミットも設定すると、ユーザーは下限に達したときに警告を受けます。
@developers soft nofile 2048@developers hard nofile 8192
ulimit オプションのリストを見るには、マニュアルページ (man ulimit) を見てください。 ulimit は bash に組み込まれており、少なくとも Linux では、以下のオプションが利用可能であることがわかるでしょう:
-a All current limits are reported-c The maximum size of core files created-d The maximum size of a process's data segment-e The maximum scheduling priority ("nice")-f The maximum size of files written by the shell and its children-i The maximum number of pending signals-l The maximum size that may be locked into memory-m The maximum resident set size (has no effect on Linux)-n The maximum number of open file descriptors (most systems do not allow this value to be set)-p The pipe size in 512-byte blocks (this may not be set)-q The maximum number of bytes in POSIX message queues-r The maximum real-time scheduling priority-s The maximum stack size-t The maximum amount of cpu time in seconds-u The maximum number of processes available to a single user-v The maximum amount of virtual memory available to the shell
もし limits.conf ファイルが許可しているなら、本当に余分な容量を必要とする特定のアプリケーションに対して、このように制限が設定されているかもしれません。 この例では、oracle ユーザーは最大 16,384 プロセスを実行し、65,536 ファイルを開く能力を与えられています。 これらの行は、Oracle ユーザーの .bash_profile.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi
で設定されます。