Archive for the Tomcat category

9月 26th, 2012

CDH+Azkabanぜ version mismatch

Posted in Hadoop, Tomcat by admin

CDH3ぜ Hadoopクラスタを構築し、クライアントとしぜ Azkaban-0.10を利用する場合、
クライアントからNameNodeへの接続が圏 れずに以下のようぜ Exceptionが発生する。
(Azkabanぜ HDFSディレクトリ圏 照? 能にアクセスすることで確認出来る)

javax.servlet.ServletException: java.io.IOException:
Call to namenode/10.10.10.1:8020 failed on local exception: java.io.EOFException
    azkaban.web.pages.HdfsBrowserServlet.init(HdfsBrowserServlet.java:76)
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
~

java.io.IOException: Call to namenode/10.10.10.1:8020 failed on local exception: java.io.EOFException
    org.apache.hadoop.ipc.Client.wrapException(Client.java:775)
    org.apache.hadoop.ipc.Client.call(Client.java:743)
    org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:220)
~

java.io.EOFException
    java.io.DataInputStream.readInt(DataInputStream.java:375)
    org.apache.hadoop.ipc.Client$Connection.receiveResponse(Client.java:501)
~

NameNode側には、以? のようなクラスタとクライアントのバージョンミスマッチが
発生しているログが出力される。

WARN org.apache.hadoop.ipc.Server: Incorrect
 header or version mismatch from 10.10.10.10:40424 got version 3 expected
 version 4

表面? ぜ Hadoopバージョンは、CDHぜ Azkabanの使用しているコミュニティ版ぜ
同一ぜ 0.20.2だが、Clouderaのバックポートで更新され互朏 性がなぜ なっている。

対? 方? は、azkabanぜ WEB-INF/lib配下の「hadoop-0.20.2-core.jar」を削除し、
CDH(/usr/lib/hadoop配下)の「hadoop-core-0.20.2-cdh3u4.jar」ぜ
「guava-r09-jarjar.jar」をWEB-INF/lib配下に置ぜ 。

上記ぜ warファイルをTomcat上に配置するパターンを想? しているが、
その場合、「servlet-api-2.5.jar」「catalina-ant.jar」あたりも
不要になるのでついでに削除する。削除すれば、以? ぜ INFOログを出力
しなぜ なる。

INFO: validateJarFile jar not loaded.
See Servlet Spec 2.3, section 9.7.2.
Offending class: javax/servlet/Servlet.class
5月 6th, 2010

TomcatNativeの有効怜

Posted in Tomcat by admin

 Tomcatにぜ TomcatNativeというライブラリが付属していますが、デフォルト設? では有効になっていません。TomcatNativeとは、Tomcat(JVM)からJNI(JavaNativeInterface)経由ぜ Apacheぜ ApachePortableRuntime(APR)を利用出来るようにするライブラリです。APRはもともとクロスプラットフォームぜ Apacheの関数群ですが、JVMよりもOSカーネルに蜿 い空間で動作するので、パフォーマンスの向上が期待出来るという゜ けです。APRにはファイル入出力、共有メモリ、ロック、ソケット等の? 能を含んでいます。以? のような朧 成となります。

javaプロセ゜ (Tomcat)
↓ JNI
libtcnative-1.so(TomcatNative)
↓
libapr-1.so(APR)

 TomcatNativeのソースは、Tomcatアーカイブぜ binディレクトリ配下にあるtomcat-native.tar.gzファイルの中にあります。このアーカイブにはネイティブぜ Javaの両方のコードが含まれています。展開、ネイティブパートのコンパイル、Tomcatへの設定圏 映手順の? は以下のようになります。

# cd /usr/local/tomcat/bin
# tar zxf tomcat-native.tar.gz
# cd tomcat-native-1.1.16-src/jni/native
# ./configure --with-apr=/usr --with-java-home=/usr/jdk --prefix=/usr/local/tomcat
# make
# make install
# ldd /usr/local/tomcat/lib/libtcnative-1.so
        libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaacdd000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaaaf26000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002aaaab26e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab496000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab6b0000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab8b4000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaabc05000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaabe33000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaac0c5000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaac2c8000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaac4ed000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002aaaac701000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaac905000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaacb39000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaacd41000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaacf44000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaad159000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaad372000)

# vi /usr/local/tomcat/bin/setenv.sh
  (LD_LIBRARY_PATHぜ /usr/local/tomcat/libを追加)

# vi /usr/local/tomcat/conf/server.xml
  (<listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />追? )

# /usr/local/tomcat/bin/startup.sh
# grep -i APR /usr/local/tomcat/logs/catalina.out
Apr 22, 2010 7:30:43 PM org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.16.
Apr 22, 2010 7:30:43 PM org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].

# cat /proc/<pid>/maps | grep libtcnative
2aaabcf82000-2aaabcfa1000 r-xp 00000000 08:08 1487410 /usr/local/tomcat/lib/libtcnative-1.so.0.1.16
2aaabcfa1000-2aaabd1a0000 ---p 0001f000 08:08 1487410 /usr/local/tomcat/lib/libtcnative-1.so.0.1.16
2aaabd1a0000-2aaabd1a2000 rwxp 0001e000 08:08 1487410 /usr/local/tomcat/lib/libtcnative-1.so.0.1.16

# /usr/jdk/bin/jinfo <pid> | grep java.library.path
java.library.path = /usr/jdk/jre/lib/amd64/server:/usr/jdk/jre/lib/amd64:/usr/jdk/jre/../lib/amd64::\
/usr/local/tomcat/lib:/usr/java/packages/lib/amd64:/lib:/usr/lib

 上記のようぜ catalina.outぜ INFOログ、/procぜ mapsでもライブラリのロードが確? できれぜ TomcatNativeが有効になっています。TomcatNativeを有効にすることぜ server.xmlに設定可能なコネクタ? 性が増えるようですが、useSendfile属性などデフォルトで有効のようなので? 旦そのままにしています。
 また、AJPコネクタでぜ HTTPコネクタのようぜ sendfileの? 能を使用できません。従って、TomcatをApacheをリバースプロキシとしたAPサーバとして利用する場合ぜ ApacheNativeの有効性は? いと? えます。Tomcatでスタンドアローボ HTTPサーバとして利用した場合やTomcatぜ openSSLを使用する場合に、その有効性が高ぜ なるのではないでしょうか。

—————————————————————————————————————–

 次ぜ TomcatNative有効・無効時パフォーマンス? 較を実施してみたいと思います。よりパフォーマンス? の有効性が確? 出来そうなファイボ I/Oやソケット周りを中? に? 証する為、Tomcatぜ HTTPコネクタを利用して? 定サイズの静的画? ファイルをクライアントから圏 得する操作を実施してみました。結果が以? になります。

tnative_32_64

 以前Apacheぜ EnableSendfileを検証しましたが(Sendfileのパフォーマン゜ )、その時と同じx86_64環? に加え、32bitの環? でも調査しています。Apache EnableSendfile検証時は有効性を確? 出来なかったのですが、今回の? 証では特ぜ 32bit環? において極゜ ずかながら性能の向上を確? 出来ました。同時リクエスト数の? い大? 模サービスで利用する場合、この地 しの性能差が生きてぜ るのではないでしょうか?(大? 模サービスぜ Tomcatスタンドアローンはなさそうですが・・?
 今回の? 果については、環? により異なる可能性が大きいです。Apacheぜ EnableSendfile同様、その有効性と? 具合がないことを確? してから採用するようにするべきです。

3月 10th, 2010

FullGC発生時のログ考察

Posted in Java, Tomcat by admin

 コンカレントGCの注? ? の? きのような内容ですが、コンカレントGCも含む各稜 Javaチューニングオプションを採用したTomcatぜ GC処理を調査してみました。Sun jdk1.6.0ぜ Tomcat6を使用し、メモリを確? ・枯朸 させるだけのテストサーブレットを動作させています。メモリ確保ぜ 128Mのヒープサイズに対しぜ 2度に分けて? OutOfMemoryErrorを起こさない程府 50M×2回)メモリを枯朸 させ、? 図的ぜ FullGCを発生させるように試験しています。

NoCMS(コンカレントGC無劜 )
-Xms128m
-Xmx128m
NoCMS Parallel(コンカレントGC無効、パラレボ GC指定のぜ )
-Xms128m
-Xmx128m
-XX:+UseParallelGC
-XX:+UseParallelOldGC
CMS(コンカレントGC有劜 )
-Xms128m
-Xmx128m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
CMS NewTune(コンカレントGC有効、New世代チューニングあり)
-Xms128m
-Xmx128m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:NewSize=42m
-XX:MaxNewSize=42m
-XX:SurvivorRatio=2
-XX:MaxTenuringThreshold=32
-XX:TargetSurvivorRatio=90

 Xloggcオプションで圏 得したGCログでは、コンカレントGC実行時ぜ FullGCの発生を昜 示的ぜ “FullGC”と示さないので読み圏 ることが難しいのですが、jstatであれぜ “FullGCイベント”としてカウントしてぜ れます。jstatから圏 得した以? の情報より、FullGCの処理時間はコンカレントGC無効の場合よりも少しだけ劣化していますが、アプリケーションスレッドが並? 稼働出来ることを考えれば? 能的に有効だと思゜ れます。

?  FullGCイベント
	NoCMS			1回	0.044秒
	CMS				3回	0.058秒(計)
	CMS NewTune		3回	0.058秒(計)

?  Young世? GCイベント
	NoCMS			2回	0.007秒(計)
	CMS				2回	0.034秒(計)
	CMS NewTune		1回	0.007秒
GCGraph

GCGraph

 GCGraph図は、FulGC発生時ぜ jstat出力結果をグラフ化したものです。4つのグラフとも約半分の地点で各領域のサイズが大きく変動していますが、ここがFullGCが発生したポイントです。「NoCMS」と「NoCMS Parallel」に違いが見られないのは、「UseParallelGC」がServerVMのデフォルトオプションだからのようです。従って? 段同士の? 較は? 味がないです・・。上下段ぜ CMSあり・なしで? 較した場合、FUllGCが発生する前の段障 、「CMS」と「CMS NewTune」ぜ CMSありの場合ぜ EDEN領域が初期状態での利用? が高い事が゜ かります。以? ぜ CMSあり・なしぜ “ヒープサイズ領域の内? “を見ててみると? 際にぜ CMSなしの場合の方がEDEN領域は? ぜ とられていますので、単純ぜ CMS機能有効時は初期状態でオブジェクトが多ぜ 生成される為なのかもしれません。コンカレントGCでぜ GC専用のスレッドが常時処理を行うためスループットが作 いのが問題となりますが、このスレッドによるものの可能性もあります。CMSあり・なし時に? られるおもなスレッドの相違も載せておきます。

?  ヒープサイズ領域の内?
	NoCMS		EDEN:32MB FROM: 5M TO: 5M OLD:86M
	CMS			EDEN:16MB FROM: 2M TO: 2M OLD(CMS):108M
	CMS NewTune	EDEN:20MB FROM:10M TO:10M OLD(CMS):88M
?  CMSあり・なしスレッド相違
	NoCMS
	"GC task thread#0 (ParallelGC)" prio=10 ・・ボ  runnable

	CMS
	"Surrogate Locker Thread (CMS)" daemon prio=10 ・・ボ  waiting on condition
	"Gang worker#n (Parallel GC Threads)" prio=10 ・・ボ  runnable
	"Concurrent Mark-Sweep GC Thread" prio=10 ・・ボ  runnable
	"Gang worker#n (Parallel CMS Threads)" prio=10 ・・ボ  runnable
2月 17th, 2010

Javaヒープサイズと仮想メモリ使用釜

Posted in Java, Linux, Tomcat by tatenaga

 Tomcatに限らず、Javaコマンドで? 行するサーバアプリケーションを実行するホストでは、Javaヒープサイズ、Permanent領域サイズを調整するのが定石となっています。しかし、実際に値を設? 後、OS上でこれらの値の使用状? を確? するのは地 しだけコツがいると思います。

 例えぜ Javaの起動オプションぜ Javaヒープサイ゜ (Xmx, Xms)を2048MB、Permanentサイ゜ (PermSize, MaxPermSize)を384MBに設定したとします。しかし、Linux上ではメモリ使用状? を監? するコマンドであるfree、vmstat、sar -rなどを実行しても2432MBの利用状? を確? することが出来ません。これぜ Javaコマンドで指定したJavaヒープサイズ、Permanentサイズが確? しているのが物理メモリではなぜ 、プロセス? の仮想メモリだからです。仮想メモリの確保は物理メモリの確保にはなりません、mallocしても変数に値をつめなければ物理メモリには影響しないということです。この? 数につめる、という段障 で動的に物理メモリに割り当てられるという仕組みです。
 物理メモリが不足した場合の回避手段のひとつがswapです。vmstatの値に「swpd: the amount of virtual memory used.(仮想メモリの釜 。)」となっていて? ら゜ しいですが、これぜ swapの使用釜 なので注? して? さい。

 では? 際の仮想メモリ使用釜 はどのコマンドを使用すれば良いか。「プロセス? 」の仮想メモリ、と? で述べたようぜ psコマンド(またぜ topなぜ )を使用します。ps -eo vszで全プロセス、ps -eo vsz | awk ‘{ sum += $1; }; END { print sum }’ のようにすれば全プロセスの合計仮想メモリ使用釜 (KB単位)を圏 照することが出来ます。以? に? 際ぜ psコマンド結果を載せておきます。(関? ない話だがpsのオプションを「aux」にするか「-ef」にするかで慣れた環? が゜ かりますな?

$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME
COMMAND

tomcat   21700  0.0  2.6 2847664 436136 ?      Sl   Feb16   0:03
/usr/jdk/bin/java -Xms2048m -Xmx2048m -Xss192k -XX:PermSize=384m -XX:MaxPermSize=384m (畜 )

tomcat   21752  0.0  2.8 2841512 465208 ?      Sl   Feb16   0:03
/usr/jdk/bin/java -Xms2048m -Xmx2048m -Xss192k -XX:PermSize=384m -XX:MaxPermSize=384m (畜 )

 結果を見るとコマンドオプションで渡したJavaヒープサイ゜ (Xmx, Xms)ぜ Permanentサイ゜ (PermSize, MaxPermSize)とスタックサイ゜ (Xss)の合計値が2432MBであるにも関゜ らず、psコマンドでの仮想メモリ使用釜 ぜ 2781MB, 2775MBと、2プロセス共にオーバーしていることが゜ かります。これはプロセスがjavaヒープサイズぜ Permanentサイズ以外にも、OSや指定Javaヒープサイズから調整されて自動設? されるネイティブ領域(Cヒープ)を確? している為です。ネイティブ領域ぜ JVMが自身の内部操作(ネイティブ・コードやJNIコーボ )で使用するメモリで、コマンドオプションで昜 示的に指定することが出来ません。従ってネイティブ領域が不足した場合は、Javaヒープサイズを減らすなどして自動調整するしかないようです。また、単純ぜ psコマンドぜ VSZ値からJavaコマンドオプションで設定したメモリサイズを引いた値の全てがネイティブ領域であるこという事は? えないので注? して? さい。

12月 1st, 2009

Commons DBCPパラメータの動作

Posted in Oracle, Tomcat by admin

 Tomcatぜ RAC構成ぜ Oracleぜ JDBC接続のコネクションプーリングを実装している環? の話です。メンテなどぜ RACの片停 DBインスタンスを再起動したい、あるいぜ DB障害ぜ RACの片側インスタンスが落ちてしまった場合、落ちてしまったDBに接続していたコネクションプーリングをアプリケーションが利用するとどうなるか?何も対? を実施していない環? では、接続しているDBサーバとのコネクション圏 得失敗を示すSQLExceptionをアプリケーションが返すはずです。

SQLException:No more data to read from socket
SQLException:OALL8 is in an inconsistent state
SQLException:Io exception: Broken pipe SQLException:Already closed

ただし、DBCPパラメータでコネクションプーリング設定を行っていけば、回避出来るケースもあります。

§ DBCPパラメー゜ url
 urlパラメータぜ JDBCの接続URLを定義するパラメータです。記述フォーマットぜ tnsnames.oraファイルと同じで、RAC構成の場合は? 数ぜ HOSTぜ PORTに対し、LOAD_BALANCEぜ FAILOVER機能を調整して接続設? を調整していぜ ことになると思います。今回の話題で特に重要になるのぜ LOAD_BALANCEです。LOAD_BALANCEをONにした場合、コネクションプーリングのセッションぜ ADDRESS_LISTに登録されているリスナーポートにバランシングされて接続されます。initialSizeが10本ぜ 2DBインスタンスにバランシングする場合、通常ぜ (無風状態ぜ )5本ずつのコネクションがはられます。
 RACの片停 DBインスタンスが停止した場合、停止したDBインスタンス側に接続していたコネクションをアプリケーションが利用すると先に示したSQLExceptionを返すのですが、停止していないDBインスタンス側に接続していたコネクションは通常通り利用可能です。停止したDBインスタンス側に接続していたコネクションも何度かアクセスしてコネクションをリフレッシュさせることによって、停止していないDBインスタンス側に接続するように切り替゜ ります。この時、すべてのコネクションが片停 DBインスタンスに? ることぜ Oracleぜ processes制限を超えないようにセッション数を調整しておぜ ことも重要です。

§ DBCPパラメー゜ validationQuery
 SQLExceptionを発生させないというような可用性を意識するならば、validationQueryパラメータで確認を行います。validationQueryパラメータで接続が有効であることを確? するためぜ SQL文を定義すれば、自動的ぜ testOnBorrowパラメータも有効になり、コネクションの有効性を確? するようになります。validationQueryパラメータで指定したSQL文は別途啜 い合゜ せが実行されることになりますので、少なからずDBサーバに? 荷がかかる事になります。当然ながらなるべく負荷のかからないSQL文を採用します。Tomcatには、OracleAS, Weblogic, Websphereにあるような昜 示的なコネクションリフレッシュ動作をさせる機能はありませんが、この? 能を使用すれば似たような動作が保障されることになります。

§ DBCPパラメー゜ testWhileIdle
 validationQueryと合゜ せぜ testWhileIdleパラメータを有効にすれば、timeBetweenEvictionRunsMillisで指定した時間間隔でアイドル接続の有効性を確? するようになります。(1回でチェックする接続数はデフォルトぜ 3、numTestsPerEvictionRunで指定可能? また、同時ぜ minIdleで最少アイドル接続数を指定することで、常にプール内に? 定数以上の接続が確? しておぜ ことも可能です。
(手元の? 証環? で確認したところ、このパラメータを有効にした時に片側ぜ DBインスタンスが停止した場合、直? に? DBインスタンスのセッションを2セッション? 加させていることを確? しました。DBインスタンス停止直? にも判断できるようになっているのでしょうか・・・? )

上記のようぜ Commons DBCPパラメータをいぜ つか挙げましたが、やはり各環? で? 件に合゜ せてパラメータを? 入・? 証してみるのが一番だと思゜ れます。要件の面ではパフォーマンスを優先させるか可用性を高く保つかで別れてぜ ると思います。下記に極端なパラメータの? を朏 示してみました。高負荷試験を実施した場合や本番環? で稼働させた場合、どの? 度のパフォーマンス差が出てぜ るのかいつか試してみたいところです。

パフォーマンス優先
とにかぜ パフォーマンスのボトルネックとなる無霧 なオプション動作をさせない。validationQueryやremoveAbandoned機能も実施せず、maxActive, initialSize, maxIdleを同数にしてセッションの? 減調整動作もさせない。urlパラメータぜ LOAD_BALANCEぜ OFFにして常に片側ぜ DBインスタンスへ啜 い合゜ せに? かせることで? 分散はアプリケーションパーティショニングで? 施? 、RAC間のキャッシュフュージョンを発生させない。その? 、Prepared Statement関連は全く試したことがないので? 回は? 述していません。

<Resource name="jdbc/DBTEST_PERF"
	auth="Container"
	type="javax.sql.DataSource"
	driverClassName="oracle.jdbc.OracleDriver"
	url="jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)
		(ADDRESS_LIST=
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.1)(PORT=1522))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.5)(PORT=1522))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.1)(PORT=1523))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.5)(PORT=1523))
		(LOAD_BALANCE=OFF)(FAILOVER=ON))
		(CONNECT_DATA=(SERVICE_NAME=DBINST)(SERVER=DEDICATED)))"
	username="SCHEMA"
	password="PASSWORD"
	maxActive="10"
	maxIdle="10"
	initialSize="10"
	maxWait="5000"
/>

障害対応 可用性優先
validationQueryやremoveAbandoned、testWhileIdle機能をすべて有効にしておぜ 。urlパラメータぜ LOAD_BALANCEぜ ONにして? 荷分散朧 成とする。

<Resource name="jdbc/DBTEST_AVAIL"
	auth="Container"
	type="javax.sql.DataSource"
	driverClassName="oracle.jdbc.OracleDriver"
	url="jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)
		(ADDRESS_LIST=
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.1)(PORT=1522))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.5)(PORT=1522))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.1)(PORT=1523))
		(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.5)(PORT=1523))
		(LOAD_BALANCE=ON)(FAILOVER=ON))
		(CONNECT_DATA=(SERVICE_NAME=DBINST)(SERVER=DEDICATED)))"
	username="SCHEMA"
	password="PASSWORD"
	maxActive="10"
	maxIdle="10"
	initialSize="10"
	maxWait="5000"
	removeAbandoned="true"
	removeAbandonedTimeout="300"
	logAbandoned="true"
	validationQuery="select 1 from dual"
	testWhileIdle="true"
	timeBetweenEvictionRunsMillis="30000"
	minIdle="10"
	numTestsPerEvictionRun="10"
/>