2014年8月15日金曜日

PermGenの増加について

アプリケーションの負荷テスト実行中、PermGenが現象しない場合、OutOfMemory の可能性がある。以下のように、PermGenが減るかどうか確認が必要。

 S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 19.81   0.00  90.04   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  90.92   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  90.92   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  91.81   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  92.05   4.83 100.00     66    2.889     4    1.306    4.195
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 19.81   0.00  92.05   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  92.92   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  92.92   4.83 100.00     66    2.889     4    1.306    4.195
 19.81   0.00  94.82   4.83  99.27     66    2.889     4    1.306    4.195
 19.81   0.00  95.01   4.83  99.27     66    2.889     4    1.306    4.195
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 19.81   0.00  95.01   4.83  99.27     66    2.889     4    1.306    4.195
 19.81   0.00  95.55   4.83  99.27     66    2.889     4    1.306    4.195
 19.81   0.00  95.55   4.83  99.27     66    2.889     4    1.306    4.195

上記は、PermGenが 100 になってから、99.27に減少している。その間、FullGCは発生していない。

consoleでjavaアプリケーションのJVMメモリ領域を確認する

jstatコマンドを使う。

$JAVA_HOME/bin に 標準で付属する jstatコマンドは以下のオプションを指定する。

jstat -出力オプション(-h[ヘッダーを出力する行間隔]) [プロセス番号] [出力間隔(ミリ秒)]
ex) >sudo ./jstat -gcutil -h5 1905 3000














上記の出力を得ることが出来る。各値の意味は、以下。


  • S0 Survivor領域0(From)の使用率(現在の容量に対するパーセンテージ)
  • S1 Survivor領域1(To)の使用率(現在の容量に対するパーセンテージ)
  • E Eden領域の使用率(現在の容量に対するパーセンテージ)
  • O Old領域の使用率(現在の容量に対するパーセンテージ)
  • P Permanent領域の使用率(現在の容量に対するパーセンテージ)
  • YGC New領域のカベージ・コレクションの回数
  • YGCT New領域のガベージ・コレクション時間(ミリ秒)
  • FGC 完全カベージ・コレクションの回数
  • FGCT 完全ガベージ・コレクション時間
  • GCT ガベージ・コレクション総時間(ミリ秒)




tomcatアプリケーションの負荷テスト

tomcatアプリケーションを負荷テストするにあたって必要なことをまとめる。

負荷テストクライアント


負荷テストツールには、JMeter を使う。
メーカーにいた8年くらい前からずっとスタンダードなツール。

pluginは入れておいたほうが良い。

http://jmeter-plugins.org/downloads/all/


リスナーとしては、以下を表示しておくと良い。

  • jp@gc – Response Times Over Time
  • jp@gc – Transactions per Second
  • jp@gc – Active Threads Over Time
  • jp@gc – Composite Graph (上記の選択表示)


スループットを制御するには jp@gc - Throughput Shaping Timer を使う。

RPS(Requests Per Second) とその継続秒数を指定して、スケジューリングすることが可能だ。


JMeterでハマった点は、PUT Method で Body パラメータをPOSTと同様には送信出来ないことだ。
Body Dataに直接 {key}={value}&... と記述すると送信出来た。変な仕様。


監視ツール

VisualVM と JConsole を使う。

VisualVM
http://visualvm.java.net/ja/gettingstarted.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20090902/336270/?ST=develop&P=1

JConsole
JDKに標準で付属する監視ツール。


負荷テスト中監視したいのは、リクエストに成功しているかどうか、とメモリ領域に異常が無いかどうかである。

リクエストに成功しているかは、以下で確認出来る。


  • JMeter:レスポンスを確認
  • VisualVM :ヒープサイズに異常が無いか
  • VisualVM:待機スレッドが不必要に増加していないか


メモリ領域は、OutOfMemoryの原因が潜んでいないかどうかを確認する。


  • PermSize
  • CodeCache

CodeCacheについて


Hotspot VM は 動的コンパイラ(Just in Time) の1つであり、よく使われるプログラム(Hotspot)の
メモリ上のバイトコードをメモリ上のネイティブコードに変換するキャッシュの仕組みである。

よく使われる部分について、ネイティブと同程度の性能を得られる。


PermSizeが不足したOutOfMemoryError


perm領域を食いつぶしていた話



運用しておいた方が良いパラメータ

以下のブログにまとめられている。


こちらも参考になる。
http://kohago.blogspot.jp/2013/09/jvm-memory-system-jconsole.html


負荷テストの時だけ有効にしておきたい設定


2014年8月14日木曜日

JavaServletサーバ設定

JavaのServletサーバを構築することがあったので、ついでに設定についてまとめておきます。

サーバの構成はレガシーです。


  • tomcat:Webアプリケーションサーバ
  • Jersey:JAX-RSの実装
  • Doma:ORM、DAO
  • DBCP:DB接続プール
  • MySQL:RDB


裏側、DBとアプリケーションの接続からまとめます。

DBCPを使ってDB接続プールを保持する場合の設定です。

ここでは、WEBアプリケーション直下にMETA-INFディレクトリを作成し、context.xmlを格納する方法を使い、以下のように記述します。


設定値は以下の意味を持ちます。
  • factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" #dbcpのコネクションプーリングを使用する
  • initialSize="5" #プールの初期状態に確保するコネクション数
  • minIdle="1" #未使用の接続を保持する最小数
  • maxIdle="10" #未使用の接続を保持する最大数
  • maxActive="50" #最大接続数
  • maxWait="5000" #接続が取得出来るまでwaitする秒数
  • validationQuery="SELECT 1" #コネクションの有効性検証用クエリ
  • validationQueryTimeout="5" #検証クエリが失敗した場合に、再接続するまでの秒数
  • testOnBorrow="true" #trueの場合、プールからコネクションを取得する際に検証を行う
  • testWhileIdle="true" #trueに設定すると、監視スレッドがアイドル状態のコネクションの生存確認を行う際に、有効性確認も行う。検証に失敗した場合、プールから削除する。
  • timeBetweenEvictionRunsMillis="1800000" #指定した間隔で監視スレッドを起動する。監視スレッドはコネクションの生存確認を行う。デフォルトは 30 分以上アイドル状態のコネクションをプールから削除する。(設定値は30分)
  • numTestsPerEvictionRun="5" #プール無いで生存を確認するアイドル接続数
  • minEvictableIdleTimeMillis="86400000" #アイドル接続するミリ秒数 (設定値は24時間)
  • removeAbandoned="true" #クローズ漏れコネクションの自動切断
  • removeAbandonedTimeout="600" #クローズ漏れとみなすまでの秒数 (設定値は10分)


これら以外に設定することを悩んだパラメータがあります。


  • preparedStatementのキャッシュ(非採用)
poolPreparedStatements="false"がデフォルトです。設定しませんでした。理由は、統計情報によりキャッシュクエリを保持するため、有効になるかどうかは博打を打つようなもので、緊急の手段として用いるものです。

これで、DBCPによるコネクションプーリングが出来ました。最大接続数はアプリケーションの特性に合わせて決定すべきです。


続けて、表側のtomcatの設定をします。

その前に、JVMのメモリ領域について整理しましょう。

JVMのメモリ領域の種類

○ヒープ
New領域:インスタンス化されたオブジェクトの情報
Old領域:寿命の長いオブジェクトの情報

○非ヒープ
Permanent領域:JVMにロードされたクラスやメソッドの情報(基本GC対象外だが、ユーザ定義のクラスローダーが存在する場合は、ロード情報はGCされる。)

□New領域
Eden領域:オブジェクトがインスタンス化されてはじめて配置される領域
From領域:Scavenge GC時のオブジェクト退避領域1
To領域:Scavenge GC時のオブジェクト退避領域2

FromとToを合わせてSurvivor領域と呼ぶことがあります。

□GC
Scavenge GC:New領域のみを対象とするGC。比較的短時間。
 トリガーはEden領域が一杯になった時。
 Scavenge GCが実行されたら、不要なオブジェクトは破棄、必要なオブジェクトはTo領域へ。
 既にToに入っているオブジェクトはFrom領域へ、FromからはToへ移動する。
 To、From間の移動がMaxTenuringThreashold(default 32)を超えると、Old領域へ移動。

Full GC:Old領域及びPermanent領域を対象とするGC。処理時間は長い。
 トリガーはOldまたはPermanent領域が不足した時。実施中はシステムがほぼ停止状態になる。

OldとPermanetが肥大化しないように注意する。
  • オブジェクトをあまり使いまわさないことや、新しいオブジェクトを大量に使用するな、Newを大きくして、Oldに移動しにくくなるようにする。
  • Permanent領域については、staticメソッドを多用しないこと。

サーバーモード

○起動サーバモード
起動時に -server オプションを指定する。:サーバモードを有効化する。
 サーバーモード:プログラム実行速度が最大化するように調整される。
 クライアントモード:起動時間を退縮し、メモリサイズを縮小するように調整される。

○Permanent領域
-XX:MaxPermSize:Permanent領域の最大値。
-XX:PermSize:Permanent領域の初期値、MaxPermSizeと同じ値を設定。

Permanentサイズの設定は、OutOfMemoryエラー対策になる。デフォルトは64MBと小さいので、
必ず設定すること。

○New、Old領域
-XX:NewRatio:New領域とOld領域の比を設定する、サーバVMの場合、デフォルトが 2 である。つまり、New:Old = 1:2 となる。

-XX:SurvivorRatio:EdenとSurvivorの比。デフォルトはEden:8、From:1、To:1 である。


初期設定は以下。負荷試験によって変更すると良い。

-Xms2048m -Xmx2048m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:PermSize=512m -XX:MaxPermSize=512m -server

2014年7月3日木曜日

Jersey で Restful API をつくる

Jersey で Restful な API を作成する。

前提知識として、JAX-RS をさらっと認識しておくと良い。
何故 REST なのか、REST の何がうれしいかを見ておく。

JAX-RS 1 について : http://www.coppermine.jp/docs/programming/2012/12/jaxrs1.html

JAX-RS 2 について : http://www.coppermine.jp/docs/programming/2012/12/jaxrs2.html


JAX-RS 2 を見るにあたっては、CDI も見ておくと良い。

CDI :: https://blogs.oracle.com/nishigaya/entry/javaee6_understanding_cdi_part_1


1 と 2 どちらを用いるかは、作成するアプリケーションの API の複雑性・多様性によって決めると良い。

テキストのみを扱うシンプルな API に JAX-RS 2 の仕様を実装するのもどうかと思う。

Jersey1


ここでは、JAX-RS 1 の実装である、Jersey 1系 を使って、Servlet 環境を作成する。

Jersey 1系の最新 1.18 を以下からダウンロードできる。

https://jersey.java.net/download.html


ダウンロードしたファイルを解凍して、以下を Tomcat プロジェクトのライブラリとして登録する。


  • asm-3.1.jar
  • jersey-client-1.18.jar
  • jersey-core-1.18.jar
  • jersey-json-1.18.jar
  • jersey-server-1.18.jar
  • jersey-servlet-1.19.jar
  • jsr311-api-1.1.1.jar

次に、web.xml を準備する。WEB-INF/web.xml を以下の様に作成する。




servlet タグには、servlet-name と対応する servlet-class を記載する。
これは、jerseyのクラスを設定する。init-paramには、jerseyを使うパッケージを設定する。

ここでは「jp.masazdream.scryi.server.api」である。
load-on-startup で、アプリケーションがコンテナにロードされるときに、初期化するよう設定する。

servlet-mapping では、servlet-name が一致した servlet にアクセスする url-patternを設定する。

ここでは、<アプリケーションコンテキスト名>/api/~ でアクセスする。

~ は、Jerseyによってアノテーションで記述する。

次に、jp.masazdream.scryi.server.api パッケージにクラスを記述する。



アノテーション「@Path」に続けて書いたのが、~部分である。
また、Doma を使った DAO 部分の記述をテストとして記述しているが、適当な文字列を返すほうがはじめの一歩の検証に良いだろう。


アプリケーションコンテキスト名は、Eclipse で作成したプロジェクトの場合、通常プロジェクト名がデフォルトで設定されるが、以下の手順で変更が可能である。

[プロジェクトプロパティ]-[Tomcat]-[全般タブ]-コンテキスト名

である。例えば、「test」と設定したとする。


Tomcatプロジェクト全般の設定については、以下が参考になる。

http://seesaawiki.jp/salyu/d/Eclipse%A4%CB%A4%AA%A4%B1%A4%EBTomcat%A4%CE%C0%DF%C4%EA

以上で、以下のURLからAPIをたたくことが可能である。

http://localhost:8080/test/api/communication



Doma gen で dao と entity を自動生成する

Doma に付属するツール Doma Gen で、dao と entity を自動生成する方法。

以下のチュートリアルが参考になります。



doma-genをダウンロードしたら、必要なファイルをプロジェクトにコピーします。

  • doma-gen-build.xml : プロジェクトトップに配置
  • doma-gen-1.xx.x.jar : WEB-INF/lib に設置(アプリケーションとしては不要なので、別の場所の方が良いのかも)
  • freemaker-2.x.xx.jar : 同上
後は、接続するDBに対応したドライバーを準備します。ここでは、MySQLを使いました。

  • mysql-connector-java-x.x.xx-bin.jar : WEB-INF/lib に設置

ant でビルドしますので、適当に ant をインストールしておきましょう。バージョンの制限は見た限りありませんでした。


ビルドしたいプロジェクトに合わせて、doma-gen-build.xml を編集します。
今回は tomcat プロジェクトに設置しました。

ant はコマンドラインから実行します。

ant -f doma-gen-build.xml

これで、WEB-INF/src 配下に DAO、Entityクラスが自動生成出来ます。

2014年7月1日火曜日

Doma を使って Java の DAO を楽にする。

○javaアプリケーション の DAO に何を使うか? Doma が良さそう。


How to use doma ? ということで、


JavaのDaoフレームワークである、Doma(ここでは Doma1 を)を導入します。
Domaは2waysql方式で、発行したSQLがわかりやすく、ローカルトランザクションをサポートしています。

大きな連続した命令を行う必要がないアプリケーションであれば、十分な機能を有しています。

また、他のライブラリへの依存が無いこともよいです。

Doma -----------

データ型:http://doma.seasar.org/reference/basic.html
エンティティ定義:http://doma.seasar.org/reference/entity.html
トランザクション:http://doma.seasar.org/reference/transaction.html
アノテーション:http://doma.seasar.org/reference/apt.html
Daoインターフェース:http://doma.seasar.org/reference/dao.html

■DB生成

MySQLにテーブルを構築します。
今回は、テスト用に1つテーブルを作成しました。

ex)
○テーブル
use beta_doma_table;
CREATE TABLE `beta_doma_table`.`beta_doma` (
  `beta_doma_id` INT NOT NULL AUTO_INCREMENT,
  `beta_doma_message` VARCHAR(255) NULL,
  `beta_doma_number` INT NULL,
  `beta_doma_created_at` TIMESTAMP NULL,
  `beta_doma_updated_at` TIMESTAMP NULL,
  `beta_doma_deleted_flag` TINYINT NULL DEFAULT 0,
  `beta_doma_deleted_at` TIME NULL DEFAULT NULL,
  PRIMARY KEY (`beta_doma_id`),
  UNIQUE INDEX `beta_doma_id_UNIQUE` (`beta_doma_id` ASC))
ENGINE = InnoDB
COMMENT = 'test for doma table';

○テスト用データ
use beta_doma_table;
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test1こんにちは', 101, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test2ありがとう', 102, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test3すばらしい!', 103, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test4確かに', 104, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test5緩やかに', 105, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test6そうですね', 106, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test7反対です', 107, now(), now());
insert into beta_doma (beta_doma_message, beta_doma_number, beta_doma_created_at, beta_doma_updated_at) values('test8。。。888888', 108, now(), now());

■データソースの生成
以下の用にDBへのアクセス情報を保持しておきます。
MySQLの方言も吸収します。

■Entityの生成
テーブルに対応したEntityを生成します。
自動生成するツール Doma Gen もあるようなので、後日試します。


■Entityに対するDaoを生成
Entityに対する操作をDaoに定義します。
引数をカラム名と等しくする必要があります。


■コンパイル時のアノテーションプロセス
プロジェクトプロパティの[JavaCompiler]-[Annotation Processing]-[Enable project specific settings]をonにします。

Generated source directoryには「.apt_generated」とします。

[Factory Path]には、domaのライブラリ(doma-1.XX.X.jar)を指定します。

■プロジェクトビルド
antでdomaをビルドします。
destにはビルド先を指定します。Daoインターフェースの実装クラス(Impl)がDomaによって生成されます。
targetには、jarが出来ます。



■生成jarをビルドパスに追加
targetに生成したjarをビルドパスに追加します。
JavaのアプリケーションからdomaのDAO機能を使うことが出来ます。


■テスト用コード
以下の用にEntityを取得し、更新が可能です。

以上で、Domaの基本的な操作は完了です。
大きなデータベースの場合、Entityを手動で書くことが難しくなります。
そのため、Doma gen が力を発揮するのでしょう。