HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド
Java Platform, Standard Edition (Java SE)は、デスクトップで使用される小さなアプレットから大規模なサーバーで運用されるWebサービスまで、様々なアプリケーションで使用されています。Java HotSpot VMは、このように多様なデプロイメントに対応して、それぞれ異なる要件を満たすように設計された複数のガベージ・コレクタを備えています。Java SEは、アプリケーションが動作するコンピュータの種類に基づいて、最適なガベージ・コレクタを選択します。ただし、すべてのアプリケーションに対して最適な選択になるとはかぎりません。厳しいパフォーマンス目標などの要件が課せられたユーザー、開発者および管理者は、必要なレベルのパフォーマンスを達成するため、場合によってはガベージ・コレクタを明示的に選択して、特定のパラメータを調整する必要があります。このドキュメントでは
Java 11のガベージ・コレクション・チューニングガイドを読む - CLOVER🍀
Java 8以降になってAPIドキュメント以外をあまり見ていなかったのですが、いろんなドキュメントが見やすくなって いるんだなぁと。 JDK 11ドキュメント - ホーム で、こちらのドキュメントがちょっと気になりまして。 ガベージ・コレクションのチューニングの概要 Java 8の頃に比べると、だいぶ差が。 Java Platform, Standard Edition HotSpot Virtual Machineガベージ・コレクション・チューニング・ガイド, リリース8 どうしてこのあたりを見ているかというと、Java 9以降でデフォルトになったG1GCですがどれくらいのヒープサイズ以上が 目安なのか、どこかに書いてあったかなぁということで探してみたと。 書いてありました。 最大10GBまたはそれ以上のヒープ・サイズ(Javaヒープの50%超がライブ・データで占められている)。 ガベー
On the Performance of User-Mode Threads and Coroutines – Inside.java
Discussions of coroutines and user-mode threads — like Project Loom’s virtual threads or Go’s goroutines — frequently turn to the subject of performance. The question I’ll try answering here is, how do user-mode threads offer better application performance than OS threads? One common assumption is that this has to do with task-switching costs, and that the performance benefit of user-mode threads
メニコア環境におけるJavaコンテナのパフォーマンス低下 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018/04/08追記： まとめにJava10に関する記載を追加しました。 2017/06/02追記： 調査内容をまとめて記載を大幅に更新しました。 2017/06/01追記： 記事の最後に「JDK8/9以降の本問題の取り組み」を追加しました。OpenJDK8の8u121.b34、8u131.b06で対処済みのようです（本当に修正されているかは別途確認する予定）。 どちらの対処版も2017年以降にリリースされているため、頻繁にJDK/JREを更新してない場合は確認しておくとよいです。 まとめ (Java10以降) Java10では、正
JVMのチューニング - ITエンジニアとして生きる
前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体（New領域＋Old領域）の初期値 -Xmx ・・・ ヒープ全体（New領域＋Old領域）の最大値 くらいしか話題に上がらないし意識しないことが多い（気がする）。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下２つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
最強のJVMチューニング・ツール: GCログを可視化するGCViewerとリモート接続でプロファイリング可能なVisualVM
まずは倍率を１０００倍から５０００倍に上げます。 Data Panelも一旦非表示にします。 さて、これを見ると、使用済みヒープと使用済みNew領域は比例しつつ一定の間隔で上下しています。 ここからは特異点は見えないので、一旦非表示にします。 イニシャル・マークレベル（黄色の線）も一定で、分析対象としづらいので非表示にします。 すっきりして少し見やすくなりました。 ここから、 最も時間がかかっているのはイニシャル・マーク イニシャル・マークは1分間に２回程度発生している ということが読み取れます。 イニシャル・マーク では、そもそも、コンカレントGCにおけるイニシャル・マークとは何なのでしょうか。 OracleのドキュメントのReviewing GC with the CMSによると、New領域から参照されているオブジェクトをマークするのだと。 Stop the Worldを伴い、マイナー
JJBugでJava VMの起動高速化の話をしました - nekop's blog
Japan JBoss User Group - 灼熱の JBossでJava VMの起動高速化の話をしました。非圧縮jarによる高速化はみなさんも使っている有名なソフトウェアで採用されていますが、あまり知られていないチューニングだと思います。大抵の場合200%くらいの高速化ができます。 Java Drag Race Tuning from nekop CMS GCを使わないほうがちょっとだけ速い、とか効果が小さめなオプションについては特に解説していません。 あと話すの忘れてましたがScalaがチューニングしてもあまり変わっておらず、最初から高速なのはデフォルトでbootclasspathを使っているからです。bootclasspathはクラス検証されないので、-Xverify:noneが既に適用されてるのと一緒です。 紹介したのは主にクラスローディングを高速化することによりJavaで書か
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
Java Performance Tuning
NEW: FEBRUARY 2025 NEWSLETTER We list all the latest Java performance related news and articles "Finally synchronization no longer pins carrier threads! But there are still two cases where carrier threads can effectively be pinned: native calls, and file IO" All the latest Java performance tips extracted in concise form "To make the most of AOT caching: make sure your training run matches producti
Java パフォーマンスチューニングニュース (日本語版)
■Java Performance Tuning News no.47 (2005.10.18) [NEW!] 同期処理のABC / Java スレッド 第３版より抜粋 / キャッシュによる J2EE アプリケーションのパフォーマンス向上 / J2EE デザインパターン / 今月の質問：性能対決 EJB 対 JDBC 直接呼び出し ■Java Performance Tuning News no.46 (2005.3.30) スレッドの悩み解決 / WebSphere でコマンドをキャッシュする / Java NIO で構築する高スケーラビリティを持つサーバ / MIDP 2.0でAlertを使う / 大規模バッチトランザクションの処理 / Java 5.0 の新しい並列性ユーティリティクラスを使う / その他の Java2 Standard Edition 1.5 の新機能 / Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
