Linux 環境のセットアップと確認

Linux® オペレーティング・システムでは、多数のパッチおよび更新が適用されます。

IBM® 担当員は、すべてのパッチに対して Java VM をテストすることはできません。 いくつかのディストリビューションの最新のリリースに対してテストを行うことを方針としています。 通常は、最新のパッチを適用してシステムを最新の状態にしておく必要があります。 最新のリフレッシュを入手してフィックス・リストを表示するには、 Java SDK サポート・ページを参照してください。

作業ディレクトリー

Java VM プロセスの現行作業ディレクトリーは、コア・ファイル、Java™ ダンプ、ヒープ・ダンプ、および Java VM トレース出力 (アプリケーション・トレースとメソッド・トレースを含む) の生成のデフォルト・ロケーションです。 このディレクトリーには十分な空きディスク・スペースを用意する必要があります。 また、Java VM には書き込み権限が必要です。

Linux システム・ダンプ (コア・ファイル)

クラッシュ発生時に取得すべき最も重要な診断データは、システム・ダンプです。 このファイルが確実に生成されるようにするには、以下の設定を確認する必要があります。

オペレーティング・システムの設定

オペレーティング・システムの設定が正しく行われている必要があります。 これらの設定は、ディストリビューションおよび Linux のバージョンによって異なる場合があります。

完全なコア・ファイルを取得するには、以下のような ulimit オプションを設定してください。
ulimit -c unlimited		 turn on corefiles with unlimited size  
ulimit -n unlimited		 allows an unlimited number of open file descriptors
ulimit -m unlimited		 sets the user memory limit to unlimited
ulimit -f unlimited		 sets the file size to unlimited

ulimit の設定について詳しくは、 OpenJ9 ユーザー資料の システムの構成 を参照してください。

Java 5 以降、ソフト制限の ulimit -c 値は無視され、コア・ファイルの生成に役立つハード制限値が使用されます。

Automatic Bug Reporting Tool (ABRT)やApportツールなどのLinuxツールは、Linux /proc/sys/kernel/core_patternファイルの設定を使用して、コア・ファイルを診断プログラムにリダイレクトします。 これらのツールとかれらの使っている/proc/sys/kernel/core_patternファイル設定により、JVMがシステムダンプを正常に生成できなくなる可能性があります。 そのツールは、一部の Linux ディストリビューションではデフォルトで有効になっています。 次のエラー・メッセージが表示される可能性があります。
JVMPORT030W "proc/sys/kernel/core_pattern setting ..... 
specifies that the core dump is to be piped to an external program.
Attempting to rename either core or core.<pid>
Java VM からシステム・ダンプを生成しようとすると問題が発生する場合は、 当該ツールの構成を検討したり、当該ツールを無効にすることを検討したりしてください。
Java 仮想マシンの設定

クラッシュ発生時にコア・ファイルを生成するには、Java VM にそうした動作が設定されているか確認します。

java -Xdump:what を実行すると、以下のような出力が生成されます。
-Xdump:system:
    events=gpf+abort+traceassert+corruptcache,
    label=/mysdk/sdk//jrebin/core.%Y%m%d.%H%M%S.%pid.dmp,
    range=1..0,
    priority=999,
    request=serial
これらの値はデフォルトの設定値です。 クラッシュ発生時に中核ファイルを生成するには、events=gpfを設定しなければなりません。 コマンド行オプション-Xdump:system[:name1=value1,name2=value2 ...]を使って、オプションを変更、設定できます。
使用可能なディスク・スペース

コア・ファイルを書き込めるだけの十分な大きさの使用可能ディスク・スペースが必要です。

JVMでは、labelオプション指定の任意ディレクトリーに中核ファイルを書き込めます。 例:
-Xdump:system:label=/mysdk/sdk/jre/bin/core.%Y%m%d.%H%M%S.%pid.dmp
コア・ファイルをこのロケーションに書き込むには、ディスク・スペースが十分である必要があります (32 ビット・プロセスの場合は最大 4 GB が必要になる可能性があります)。また、Java プロセスがそのロケーションに書き込むための適切な許可が必要です。

ZipException または IOException ( Linux の場合)

数多くのファイル記述子を使用してクラスのさまざまなインスタンスをロードすると、「java.util.zip.ZipException: error in opening .zip file」というエラー・メッセージ、またはファイルを開けなかったという内容の他の何らかの形式の IOException が表示されることがあります。 これを解決するには、ulimit コマンドを使用して、ファイル記述子のプロビジョンを増やします。 開いているファイルに関する現在の制限を確認するには、以下のコマンドを使用します。
ulimit -a
開けるファイルの数を増やすには、次のコマンドを使用します。
ulimit -n 8196

Linux on zSeries

z10 ハードウェア上の zVM の下の zLinux 上で Java 7 を実行している場合は、 zVM バージョン 5 リリース 2 以降を使用する必要があります。 以前のバージョンの zVM を使用している場合には、DFP によるパフォーマンス上の利点が得られません。

スレッド化ライブラリー

IBM Java VM でサポートされるディストリビューションは、拡張ネイティブ POSIX Threads Library for Linux (NPTL) を提供します。

/libディレクトリーに移動してファイルlibc.so.6を実行することで、ご使用のglibcバージョンを検出できます。 Linux コマンド ldd は、アプリケーションの共有ライブラリー依存関係を解決するのに役立つ情報を表示します。

CPU 時間制限の使用によるランナウェイ・タスクの制御

リアルタイム・スレッドは高優先順位、かつ FIFO スケジューリングを使用して実行されているため、障害が発生したアプリケーション (通常は CPU 制約による短いループ) が原因でシステムが無反応になることがあります。 開発環境では、ランナウェイ・タスクが消費可能な CPU の量を制限することによって、それらのタスクが kill されるようにすると便利です。 ソフト制限とハード制限の設定については、「 #linux_setup__linux_core_files 」を参照してください。

コマンドulimit -tは、現在のタイムアウト値をCPU秒単位でリストします。 この値は、ソフトのいずれかに削減されます。例えば、ulimit -St 900は暴走タスクを停止するハード値のいずれかで削減できます。