TomcatやJBossでHTTPリクエスト単位で並行実行数を制限するサーブレットフィルタ - nekop's blog
WebLogicからの移行とかで、HTTPリクエスト単位で流量制御などの目的で並行実行数を制限したいという要望がたまにある。WebLogicではWork Managerというのがあって、これがHTTPリクエスト単位での設定なのだそうだ。 TomcatやJBossではApache httpdのMaxClientsと同じく、リクエスト単位ではなくクライアント単位(ソケット単位)でスレッドを割り当てる。このモデルでは、例えばmaxThreads="20"とかにしたら常に同時に20個のリクエストをさばいてくれる、という仮定は成り立たない。クライアントがkeep aliveで接続している間はスレッドも待ち続けるので、21番目のリクエストは先に接続した20のクライアントがkeep aliveを終了してコネクションを切断するまで処理されない。MaxClientsは名前の通りMaxClientsなのであっ
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
