JAVAのヒープメモリのデフォルト値

本番用環境でWEBの画面が突然表示されなくなった。

TomcatのログをチェックしたところOut Of Memoryが発生していた。

そういえば、今のところヒープメモリの設定をした記憶がない。

インフラ側で設定されてあると思っていたので。

ヒアリングしたところ、誰も設定していないとのこと。

それなりにデータ投入してテストしていたのに普通に動いていた。ある意味奇跡？

このプロジェクト、PMの仕切り方・タスクの振り方・適切な体制の構築すべてが曖昧だったり、無理やりだったので、

度々このような漏れのようなことが発生する。

対策としてヒープメモリの設定を暫定ではあるが、明示的に設定することとデフォルト値の確認をする

ことになった。

設定自体は $CATALINA_HOME\binにsetenv.shを配置して、そのファイルに-Xmx -Xms -Xss 等を設定。

例

JAVA_OPTION="-Xms2048m -Xmx4096m -Xss4m"

このファイルを置いておくと、start.sh→catalina.shで読み込まれる。

また、デフォルト値ですが、以下のページに記載されている。

http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/gc-ergonomics.html

なんでもJAVA5.0から変更されている。

今回サーバクラスのマシンだったので、VMが自動でOSの種類等を検知して設定されるようです。

最小は

マシンの物理メモリの 1/64 か、妥当な最小サイズかの大きい方

最大は

物理メモリの 1/4 か、1GB かの小さい方

とのことなので、最大が１Gで動作していたと思われる。

HudsonのWindowsバッチコマンドの実行の問題点

HudsonにはWindowsの場合DOSコマンドを実行する「Windowsバッチコマンドの実行」がある。

この機能で不可解な動作をすることがあった。

今まで正常に動作していたバッチ処理の一部が実行できなくなっていた。

処理を追加したら発生したので、正常に動作しているものを変更しなければ問題は

発生しない。（当然といえば当然だが）

コンソールをチェックすると、問題の処理はパスが正しくないとうようなエラーが発生していた。

でもすべての処理がそうなっているわけではないのだが。

試しに、「Windowsバッチコマンドの実行」の処理を分割してみたら、解消された。

でも、ただ分割すればすべて解消されるわけでもない。

いまいちよくわからない。ただ、分割することで解消されることは確認できた。

Hudsonのバグなのか？

Eclipseで意味不明なビルドエラー

memcachedのライブラリ追加対応で、pom.xmlを修正したあとぐらいで何故かXMLファイル（Springの設定ファイル）

でビルドエラーが発生。

なんでも指定しているクラスがないとのこと。

でも、memcached関連ではなさそうだし、pom.xmｌの修正で関係あるのは、Eclipseのmaven all Dependenciesを

実行すればたいてい解消されるはずだが、解消されない。

ただ、確かに指定しているクラスファイルがlibにないと他のメンバーに指摘され、しぶしぶクリーンビルドすることに。

これやるとかなりの時間待たされるから嫌なのだが仕方ないので実行。

そして問題解決。すっきりしないなぁ。