アプリケーション・サーバーの始動

アプリケーション・サーバーを始動すると、新規サーバー・プロセスが開始します。 この新規サーバー・プロセスは、現行のサーバー構成のプロセス定義設定に基づいています。

始める前に

アプリケーション・サーバーを始動する前に、アプリケーションが必要とするすべてのリソースが使用可能であることを確認します。また、すべての前提条件サブシステムを開始する必要があります。

インストール済みのアプリケーションで必要に応じてサーバー・コンポーネントを動的に開始するには、アプリケーション・サーバーの構成設定で「必要に応じてコンポーネントを開始 (Start components as needed)」オプションが選択済みであることを確認してからアプリケーション・サーバーを始動してください。 このオプションを選択すると、アプリケーション・サーバーの起動時間が短縮され、 アプリケーション・サーバーのメモリー占有スペースを削減することができます。必要に応じたコンポーネントの開始は、サーバーにデプロイされているアプリケーションがすべて同じタイプの場合、最も効果的です。 例えば、このオプションは、すべてのアプリケーションがサーブレット、および JavaServer Pages (JSP) を使用する Web アプリケーションである場合に、より効果的に機能します。このオプションは、アプリケーションでサーブレット、JSP、および Enterprise JavaBeans (EJB) が使用されている場合には、あまり効果的ではありません。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble):
  • 他の WebSphere® 製品との互換性を確保するため、「必要に応じてコンポーネントを開始」オプションは、デフォルト設定ではクリアされています。 このオプションを選択する前に、この製品とともに実行する他の WebSphere 製品がこの機能をサポートしていることを確認してください。
  • コンソールからアプリケーション・サーバーを始動すると、アプリケーション・サーバーは、ulimit 設定を含むノード・エージェントの環境を継承します。ulimit を必要な値に設定する作業は、アプリケーション・サーバーがノード・エージェントから正しい値を継承するように、ノード・エージェント・レベルで実行することが必要な場合があります。
  • コマンド行からアプリケーション・サーバーを始動する場合は、startServer コマンドを発行する前に OS シェルで ulimit 設定を指定する必要があります。これは、このシナリオでは、アプリケーション・サーバーは OS シェルの ulimit 設定を継承するからです。
gotcha

このタスクについて

アプリケーション・サーバーを始動する には、アプリケーション・サーバーが配置されているノードのノード・ エージェントがあらかじめ実行されている必要があります。

通常、このサーバー始動手順は、サーバーの再始動にも適用されます。 ただし、サーバーに障害が発生し、リカバリー機能を使用して、それらの処理を完了してからそのサーバーで新規作業を開始する場合のみ、例外となることがあります。 この状態では、サーバーをリカバリー・モードで再始動する必要があります。

アプリケーション・サーバー定義の作成後、 新規サーバーの始動、停止、または管理を管理コンソールを使用して行うか、または コマンドを使用して行うことができます。

アプリケーション・サーバーの始動後、その他のプロセスが、稼働中の アプリケーション・サーバーをすぐに発見できない場合があります。 アプリケーション・サーバーはノード・エージェントによって発見されます。 ただし、ノード・エージェントは、デプロイメント・マネージャーによって 発見されます。ノード・エージェントは、通常、ローカル・アプリケーション・サーバーをすぐに発見できますが、デプロイメント・マネージャーがノード・エージェントを発見するには、最長 60 秒かかる場合があります。

クラスターを使用している場合、アプリケーション・サーバー・サブコンポーネントの「初期状態」プロパティーは、クラスターの始動時にクラスター内の個々のサーバーの状態を制御するために使用されるものではありません。 このプロパティーは、サーバーのサブコンポーネントの状態を制御するためだけに使用されます。 管理コンソールの「サーバー」オプション、またはコマンド行コマンドの startServer および stopServer を使用して、クラスターの各サーバーを始動および停止します。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 子プロセスが開始すると、Java はランタイム・パスを LIBPATH 環境変数に追加 して、正しいライブラリー・パスが使用されるように します。この実装はランタイム・パスが既に LIBPATH 環境変数に 存在するかをチェックしないため、既存の項目と重複する 可能性があります。しかし、親プロセスが停止してから始動する場合、 子プロセスの始動時に LIBPATH 環境変数に追加されたすべての 追加のランタイム・パスは LIBPATH 環境変数から削除され ます。gotcha

アプリケーション・サーバーを始動するには、以下のとおり複数の 方法があります。

手順

タスクの結果

指定されたサーバーが始動します。サーバーが始動状態にあることを確認するには、管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」をクリックします。

次のタスク

サーバーが始動した後、このサーバーで実行させるアプリケーションをデプロイします。

標準 Java™ デバッグが使用可能になっているアプリケーション・サーバーを始動する必要がある場合は、以下のようにします。
  1. 管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」をクリックします。
  2. トレースおよびデバッグの対象プロセスがあるアプリケーション・サーバーをクリックします。
  3. [AIX Solaris HP-UX Linux Windows][z/OS]「サーバー・インフラストラクチャー」で、「Java およびプロセス管理」 > 「プロセス定義」をクリックします。
  4. [z/OS]制御」を選択します。
  5. [AIX Solaris HP-UX Linux Windows][z/OS]Java 仮想マシン」を選択します。
  6. 「Java 仮想マシン」ページで、「デバッグ・モード」オプションを選択して、標準 Java デバッガーを開始します。必要な場合は、「デバッグ・モード」の引数を設定します。
  7. OK」をクリックします。
  8. 構成ファイルに変更を保存します。
  9. アプリケーション・サーバーを停止します。
  10. 前述の説明に従って再度アプリケーション・サーバーを始動します。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_svr_start
ファイル名:trun_svr_start.html