yyamanoのブックマーク - はてなブックマーク

Java 7 CMS GCの基本的な情報の整理 - nekop's blog

バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve

yyamano 2014/10/09

“CMSClassUnloadingEnabled デフォルトfalse。ClassLoader.defineClass()を利用しているバイトコードエンハンサ使っていて、無尽蔵にクラスを動的定義してロードしてPerm埋まるような場合はtrueにする。”

リンク

G1GCのつかいどころメモ - nekop's blog

以下の環境とテストでCMSとG1GCを比較してみた。かなり急ぎでやったので間違っている可能性が多少ある。 16 cores, 32GB mem -Xms24g -Xmx24g 8 instances Infinispan 6.0.3.Final DIST cache, put 4GB data (1KB entry * 2M, 2GB data with one backup copy, 2GB * 2 = 4GB) CMS: -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=30 G1GC: -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=30 $ java -XX:+UseG1GC -XX:+PrintFlagsFinal

yyamano 2014/04/07

Java

リンク

JBoss AS7のロギング事情 - nekop's blog

JBoss Advent Calendar 2012の3日目のエントリです。ログというのはディスクなどのハードウェアリソースを使うものなので、基本的にデータベースコネクションやスレッド数などと同じように、ミドルウェアリソースに位置づけられ、アプリケーションサーバで一括管理できるようになっています。と言いたいところですが、現実的にはLog4j, commons-logging, JUL(java.util.logging), SLF4J, Logbackなどログライブラリは乱立しており、各アプリでは異なるログライブラリが利用され、ログ出力設定もバラバラになされていて実際には一元管理するのはすごく大変でカオスな状態です。 JBoss ASは6までLog4jをログ実装として利用していましたが、AS7ではJBoss LogManagerというJULをベースとした実装に変更されました。これに伴い

yyamano 2013/10/29

JBoss

リンク

JBoss Loggingプロジェクトの整理 - nekop's blog

JBoss Advent Calendar 2012の2日目のエントリです。今日はJBoss Loggingというプロジェクトを見ていきたいと思います。 https://github.com/jboss-logging/ このプロジェクトにはぱっと見どういう位置づけのものであるかわからない名前のプロジェクトがずらずら並んでいます。僕もたまに混乱するので、整理してみたいと思います。表中のJULというのはjava.util.loggingを示している語です。 jboss-logmanager JULを拡張したログ実装。JBoss AS7で使われている log4j-jboss-logmanager Log4jのフリをするけど実際にはJBoss LogManagerへログを出力するブリッジ slf4j-jboss-logmanager SLF4Jのフリをするけど実際にはJBoss LogMana

yyamano 2013/10/29

JBoss

リンク

64bit Java VMでも -XX:TieredStopAtLevel=1 で高速起動 - nekop's blog

64bitのJava VMにはClient VM(-clientオプション)が付属していなくて、Server VMだと32bitのClient VMほど速く起動しないなー、って思ってたんだけど、64bitでも-XX:+TieredCompilationと合わせてこのオプションつけると-clientとほぼ同じような最適化になるっぽい。JBossの起動だと30%くらい時間短縮する。

yyamano 2013/02/13

64bit JVMでも XX:+TieredCompilationと-XX:TieredStopAtLevel=1 で高速起動

Java

リンク

Java EE環境における非同期プログラミング - nekop's blog

Java EE環境では基本的にスレッドの生成は許されていません。この制限はEJB仕様書に記述されており、ブループリントなど他のドキュメントにも記載されています。これらの制限はかなり古い時代に考えうる最大の制限を記述したものであり、「ファイルにアクセスしてはならない」など今となってはあまり現実的ではない記述も多くなっています。しかしながら、「スレッドを生成してはならない」というのは依然多くのコンテナに適用される現在も有効な制限であり、実際にスレッドの生成などを行うと誤動作するケースがあります。今回は、なぜこのスレッドの制限があるのか、現実的にどうすれば良いのか解説します。コンテナは様々なものをスレッドに結びつけて管理しています。様々なものというのは例えばセキュリティ、トランザクション、データソースなどのコンテナリソースです。コードのほうがイメージしやすいでしょうから、以下に擬似コードを挙げ