ユーザがいるなら、 彼らに対してシステムの利用を制限できないか考えたことがあるのではないでしょうか。 FreeBSD は、 個々のユーザが利用できるシステム資源の量を管理者が制限できる方法をいくつも用意しています。 その種の制限は、ディスククォータ (quota) とその他の資源の制限の とその他のリソースの制限の 2 つに分けられます。
ディスククォータは、ユーザのディスクの利用を制限し、 その都度計算しなくてもユーザのディスク使用量を簡単に確認できる手段も提供しています。 クォータについては、項16.12 で解説しています。
その他のリソースの制限とは、ユーザが消費できる CPU、メモリなどのリソースを制限する手段のことです。 これはログインクラスを用いて定義されているもので、 この後で解説しています。
ログインクラスは /etc/login.conf で定義します。詳細な働きの説明はこの節の範囲を超えますが、 login.conf(5) のマニュアルに詳しく記載されています。 各ユーザにはログインクラスが割り当てられていて (デフォルトでは default です)、 それぞれのログインクラスにはログインケーパビリティの集合が割り当てられているといえば十分でしょう。 ログインケーパビリティとは、 名称=値 の組のことで、名称 は周知の識別子、値 は、名称に応じて処理される任意の文字列です。 ログインクラスとケーパビリティを設定するのはどちらかといえば簡単なことで、 login.conf(5) でも説明されています。
注意: システムは普通は、直接 /etc/login.conf ファイルから設定を読み込まず、 より速く検索できるデータベースファイル /etc/login.conf.db から読み込みます。/etc/login.conf から /etc/login.conf.db を生成するには、 次のコマンドを実行してください。
# cap_mkdb /etc/login.conf
リソースの制限は、 2 つの点で標準的なログインケーパビリティと異なっています。 第一に、どの制限についても、ソフト (現在の) リミットとハードリミットがあります。 ソフトリミットは、ユーザやアプリケーションが調整できますが、 ハードリミットを超えることはできません。 ユーザはハードリミットを下げることはできますが、上げることはできません。 第二に、ほとんどのリソースの制限は特定のユーザに対してプロセス毎に適用されるもので、 そのユーザが利用するリソースの総量を制限するものではありません。 ただし、この違いは制限を特別扱いすることで実現されるものであり、 ログインケーパビリティフレームワークの実装によるものではありません (つまり、リソースの制限は、 実際にはログインケーパビリティの特別な場合ではないのです)。
難しい話はこのくらいにしておいて、 以下が最もよく使われるリソースの制限になります (残りは、他のすべてのログインケーパビリティと並んで login.conf(5) に書かれています)。
プログラムが生成する core ファイルのサイズにかかる制限は、 自明な理由でほかのディスク使用に関する制限に従属します (例: filesize やディスククォータ)。それでも、 ディスク領域の消費を制御するあまり厳しくない手段としてよく使われています。 ユーザは core ファイルを自分で生成するわけではなく、 削除しないことも多いので、これを設定すれば大きなプログラム (たとえば Emacs) が異常終了してもディスクの空きがなくならずに済みます。
そのユーザのプロセスが消費できる CPU 時間の上限です。 これを超えたプロセスは、カーネルにより終了されます。
ユーザが所有できるファイルの大きさの上限です。ディスククォータ と違い、 この制限はユーザのファイルをすべてまとめた集合にではなく、 個々のファイルにかかります。
ユーザが実行できるプロセス数の上限です。
フォアグラウンドプロセスとバックグラウンドプロセスの両方を平等に扱います。
自明な理由から、sysctl(8) 変数
kern.maxproc
で指定されたシステムの制限を超えることはできません。
また、同時に複数ログインすることや、
パイプライン実行することは便利なことが多いので、
この値をあまり小さな値に設定すると、
そのユーザの生産性が悪化することにも注意してください。
大きなプログラムをコンパイルする場合のように、
タスクによっては複数のプロセスが実行されます (たとえば make(1), cc(1)
や、その他仲立ちとなるプリプロセッサ)。
これは、 1 つのプロセスがメインメモリにロックされることを要求できるメモリの最大容量です (mlock(2) をご覧ください)。amd(8) のようなシステムで重要なプログラムは、 メインメモリへロックして、スワップアウトイベントにおいて、 問題発生時にシステムのスラッシングを引き起こさないようにします。
これは、どの時点かを問わず、 あるプロセスが消費できる最大のメモリ容量です。 これは、メインメモリとスワップの使用量を合わせたものです。 メモリ消費を抑えるための包括的な制限ではありませんが、 手始めにはよいでしょう。
これは、あるプロセスが開いておける最大のファイル数です。 FreeBSD
では、ファイルはまた、ソケットや IPC チャンネルを表わすのにも使われています。
ですから、あまり低い値に設定しないよう注意してください。
これに対応するシステム全体の制限は sysctl(8) 変数
kern.maxfiles で定義されています。
これは、あるユーザが消費できるネットワークメモリ (つまり mbuf) の上限の量です。これは、 大量のソケットを生成する古いサービス拒否攻撃に対応するものとして作られましたが、 一般的にはネットワーク通信を制限するのに使えます。
これは、プロセスのスタックサイズの上限です。 あるプログラムが使用しうるメモリの量を制限するには、 これだけでは十分ではありません。 したがって、他の制限と組み合わせて使わなければなりません。
リソースの制限を設定するにあたり、 ほかにもいくつか覚えておかなければならないことがあります。 以下は、一般的なこつやお勧め、さまざまなコメントになります。
システム起動時に /etc/rc から起動されたプロセスは、daemon ログインクラスに割り当てられます。
システムに付属していた /etc/login.conf はほとんどの制限について妥当な値になっていますが、 あなたのシステムに何がふさわしいか分かるのは、 管理者であるあなただけです。 制限をあまり緩くするとシステムを悪用しやすくしてしまいますし、 厳しくしすぎると生産性を悪化させてしまいます。
X Window System (X11) のユーザには、 他のユーザより多くのリソースを与えるべきかもしれません。 X11 そのものが多くのリソースを使うだけでなく、 より多くのプログラムを並行して使うことをユーザに促します。
多くの制限は個々のプロセスにかかるもので、
一人のユーザにまとめてかかるものではないことを忘れないでください。 例えば、openfiles を 50 に設定することは、
ユーザが動かすそれぞれのプロセスが最大 50 個のファイルを開けるということです。
したがって、あるユーザが開けられるファイルの総数は、 openfiles の値に maxproc
をかけたものになります。 同じことがメモリ消費量にもあてはまります。
リソースの制限と、ログインクラス、 ログインケーパビリティ一般についての詳しい情報は、 それぞれのマニュアルページ、 cap_mkdb(1), getrlimit(2), login.conf(5) をご覧ください。
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で)
連絡してください。
本文書に関する質問については、<doc@FreeBSD.org> まで電子メールを (英語で)
送ってください。