2017-10-05 2 views
18

Java 9(最新のJava 8から)に1インスタンス(2 vCPU、2GB RAM、負荷〜4k req/sec)を切り替えました。しばらくの間、すべてがうまくいき、CPU使用率は以前と同じでした。しかし、〜6時間後には、理由なくCPU消費量が4%増加しました(21%から25%へ)。私はトラフィックスパイクを持っていませんでした。 メモリ消費は増加せず、メトリックの変更もありませんでした(コード内のすべてのメソッドに対してカウンタがあります)。何もない。実際に負荷が増加することなく、Java 9 G1の作業から約6時間後にパフォーマンスが低下するのはなぜですか?

私はそれが戻って戻ります期待〜12時間そのまま、このインスタンスを残しました。しかし何も変わっていない。それはちょうどより多くのCPUを消費し始めました。

topコマンドは、インスタンスがJavaサーバ・プロセスのために通常よりも多くのCPUスパイクを有することを示しました。私は最近、G1が高スループットには適していないと読んでいます。だから私は理由がG1にあるとの結論を下しました。

は私がして、インスタンスを再起動:

java -XX:+UseParallelGC -jar server-0.28.0.jar 

と監視の〜20時間後に、すべてが以前のように細かいです。 CPU使用量は数日前と同じ21%です。

enter image description here

:7時間+ 12時間 "そのまま"(7Dスケール)後

enter image description here

CPU増加:

CPU使用権のJava 9配備(6Hスケール)後CPU後 - XX:+UseParallelGC(24時間スケール):

enter image description here

だから私の質問をされた - G1の期待する動作でありますか?他の誰かが同様のことを見ていますか?

のUbuntu 16.04のx64

java version "9" 
Java(TM) SE Runtime Environment (build 9+181) 
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) 
+2

あなたは、時間(6時間スケール)にその時点でGCログを見るために起こりましたか。 GCに関する疑わしい*疑惑を除外するのは良いことであり、正確な原因を知るための自信を持っていたでしょうか。 – nullpointer

+0

はありません。:(これはので、私はそこに危険を冒したくなかった本番インスタンスである。 –

+3

ええ...ログなしで、これは(私は仮定推測する以外に)不可能ミッション – Eugene

答えて

-4

私は決定的な答えを持っていないが、我々は我々のJVMを監視するためにpsi-probeを使用している(私たちのアプリケーションコンテナ - Tomcatの8+は、動的ページを提供するためにJDK 1.8を使用している)をすることができます

..あなたにうまくいけば、あなたは職場で入れているガベージコレクタアルゴリズムの問​​題を見るのに役立ちますCPU使用率、一緒にJVMメモリ使用率(エデン、サバイバー、旧世代、等。)の大きな絵を提供

psi-probeは、生産や開発などあらゆる環境に簡単に導入できます。もし私があなただったら、私は先に進んで、gcロギングをあなたのDEVEL環境で可能にし、いくつかの負荷テストを行います(私はいつもJMeterをこのような場合は非常に便利なツールと見ています私は問題を再現することができます。異なる負荷をプッシュし、psi-probeを使用してJVMの動作をリアルタイムで観察します。

+0

この回答は、あまり有益な情報を提供していません。 psi-probeはtomcatに使用されていますが、OPはtomcatの使用について言及しておらず、一般にJava 9に焦点を当てています。 –

関連する問題