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

OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
y_uuki 2014/08/22
JVM
リンク
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
y_uuki 2014/04/08
jvm

GC
リンク
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
y_uuki 2014/03/31
JVM

GC
リンク
1