UML がカーネルに追加――パート1-2使用上の問題
UML のような機能には、使用法はいくつもある。 例えば私のようにソフトウェアのβ版をたくさんインストールしたり、 たくさんのソフトウェアを評価していると、 結局は大混乱を抱えてしまうことになる。 そこでつい2台目のマシンを使ってしまうが、 それは1台目よりはるかに遅いので、 セットアップ中にスイッチボックスを使ってコンピュータ間を行ったり来たりしなければならず、一度にすべてを見ることができない。 UML を使えば、 β版のソフトウェアなどもろもろをメインコンピュータ上のバーチャルシステムに閉じ込めることができる。 βのバグは UML のセッションを混乱させるだけで、 稼動中のマシン全体には影響が出ない。 重要なのは、全面的には信用できない、 あるいは敢えて信用しないサービスがあるということだ。 誰かが FTP サーバー領域から進入してきやしないか心配だったら? FTP サーバーを UML 内から稼動すれば、 侵入者はメインマシンには到達できない。 BIND セキュリティ警告に悩まされている? ネームサーバーも UML に任せればいい。 もちろん、UML を使っていると性能は打撃を受ける。 UML インスタンスごとのバーチャルカーネルとプラスメインカーネル、 UML 内で動いているプログラムとメインマシンで動いているプログラムがある。 UML を使用しているときは RAM も道連れだ。 しかし RAM は VMware のようなツールにも、同様に大切なものだ。 UML インスタンスをたくさん動かしていると、 性能の低下がもっとも明らかになる。 コロケーションサービスではなく複数の UML サービスを実行しているユーザーが、 すでに UML コミュニティにたくさんいる。 ここでは、 各クライアントあるいはそれに関与するものがそれぞれ同じマシン上に自分のバーチャルマシンを持っていて、 各自のルートログインなどで妥当だと思うことを施す。 UML で実行されるサービスが増えるにつれ、 マシン全体の負荷も増えるので、 注意しないと、ひとりに CPU リソースの多くを独占されてしまうという結果になりかねない。 これを避けるには、 各 UML に与えられる RAM の量を指定することができる。 値は個別に設定できるので、 すべての UML に同じ量の RAM を与える必要はなく、 したがって、優先順位の高いサービスには優先順位の低いサービスよりたくさんの RAM を割り当てることができる。 幸いにも、 みんなの要求を満たすことができるように RAM を十分確保できるよう計算しても、 UML が実際に使用できる以上の RAM を要求した場合、 メインマシンのカーネルが他の RAM の使いすぎの場合と同じように、 この要求をスワップできる。 またそれぞれの用途に合わせて、 スワップ空間を UML に割り当てることもできる。 次回は
今すぐ UML を使ってみよう
»
最新トップニュース
|
|