Shenandoah GCShenandoah is the low pause time garbage collector that reduces GC pause times by performing more garbage collection work concurrently with the running Java program. Shenandoah does the bulk of GC work concurrently, including the concurrent compaction, which means its pause times are no longer directly proportional to the size of the heap. Garbage collecting a 200 GB heap or a 2 GB he
情報を発信する人のところに情報が集まることを日々実感しているので、Linuxのメモリ管理に特に詳しいわけではないのですが最近遭遇した問題について自分の理解を書いておきます。ざっと調べても同じことを書いている人を見つけられなかったので、公開には意義があると考えています。識者の方がフィードバックをくださると嬉しいです。 ※ AIの出力をベースに書いているのでいつもと少し文体が違います。 背景 要約 調査 再現の難しさ Goアプリケーションの調査 pprofによる分析 GCログの調査 Linuxの調査 Goランタイムの調査 GoのGCとTHP khugepagedの問題 Goランタイムにおける回避策 回避策の削除 max_ptes_noneのデフォルト値について MADV_NOHUGEPAGEをやめた理由 調査内容まとめ 解決策 検証 C言語 Go言語 まとめ 背景 Go言語で書かれたOSSのア
JDK 17 has been out for a few months and it’s not just packed with new language features. The performance boost compared to older JDK versions is also really significant. It becomes especially clear when compared to the previous LTS releases, JDK 8 and JDK 11. Much of the improved performance comes from new features and optimizations in the JVM and in this post the focus will be on the improvement
IntroductionAs described in JEP 248, in JDK 9 the default garbage collector will switch from Parallel Garbage Collector (Parallel GC) to G1 Garbage Collector (G1GC). This wiki-page aims to outline the basic JVM parameters switching to G1GC, and how you can help collecting data comparing the G1GC and Parallel GC. Usually we would like to ask for gc logs, printed with '-XX:+PrintGCTimeStamps -XX:+P
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEのメッセンジャーアプリのサーバサイドエンジニアをしている'18卒のエンジニアのbitter_foxです。この記事はLINE Advent Calendar 2018の18日目の記事です。 弊社では夏休みの1ヶ月間〜2ヶ月間、学生に実際の業務を体験してもらう就業型のサマーインターンシッププログラムを実施しております。 弊社の就業型インターンでは社内のチームにジョインし、ある程度大きめのプロジェクトに1ヶ月間〜2ヶ月間、取り組んでもらいます。 私の所属するチームでも今夏、学生を受け入れ、「HBaseをJDK 11で動かしZGCを評価する」というプロジェクトに1ヶ月間取り組んでもらいました。 本記事ではそのインタ
※本記事は、Raoul-Gabriel Urma と Richard Warburtonによる”Understanding the JDK’s New Superfast Garbage Collectors“を翻訳したものです。 ZGCとShenandoah、そして改善版のG1により、今までになく停止しないJavaが実現 著者:Raoul-Gabriel Urma、Richard Warburton 2019年11月21日 ここ半年間で行われてきた開発のうち、特にエキサイティングなものがJDKのガベージ・コレクタ(GC)の内部処理に関するものです。本記事ではさまざまな改善について説明しますが、その多くはJDK 12で初登場し、JDK 13でも引き続き行われているものです。まずは、Shenandoahについて説明します。Shenandoahは低遅延GCで、アプリケーションとほぼ同時に処理さ
G1 GC is an adaptive garbage collection algorithm that has become the default GC algorithm since Java 9. We would like to share a few tips to tune G1 Garbage collector to obtain optimal performance. 1. Maximum GC Pause time Consider passing ‘-XX:MaxGCPauseMillis’ argument with your preferred pause time goal. This argument sets a target value for maximum pause time. G1 GC algorithm tries it’s best
Learn about how to adapt and tune the G1 GC for evaluation, analysis and performance. The Garbage First Garbage Collector (G1 GC) is the low-pause, server-style generational garbage collector for Java HotSpot VM. The G1 GC uses concurrent and parallel phases to achieve its target pause time and to maintain good throughput. When G1 GC determines that a garbage collection is necessary, it collects t
Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド 目次 前 次 この項では、評価、分析およびパフォーマンスのためにガベージファースト・ガベージ・コレクタ(G1 GC)を適応してチューニングする方法を説明します。 ガベージファースト・ガベージ・コレクタの項で説明したように、G1 GCはリージョン単位の世代別ガベージ・コレクタであり、そこではJavaオブジェクト・ヒープ(ヒープ)が多数の均等サイズのリージョンに分割されます。 Java仮想マシン(JVM)では、起動時にリージョン・サイズが設定されます。 リージョン・サイズは、ヒープ・サイズに応じて1MBから32MBになる場合があります。 リージョンを2048個以内に抑えるためです。 Eden、Survivorおよび古い世代は、これらのリージョンの論理セ
GCは,プログラムが使用し終わったメモリ領域を自動的に回収して,ほかのプログラムが利用できるようにするための技術です。 GCの実行中は,プログラムの処理が停止します。このため,GCを適切に実行できるかどうかが,システムの処理性能に大きく影響します。 プログラムの中でnewによって作成されたJavaオブジェクトは,JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を,Javaオブジェクトの寿命といいます。 Javaオブジェクトには,寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合,リクエストやレスポンス,トランザクション管理などで,多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは,その処理が終わると不要になる,寿命が短いオブジェクトです。一方,アプリケー
OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 (この記事はJava8が対象となります。) OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no
ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine(以下、JVM)上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ
HotSpot JVMを使うとき、どのようにGCを設定していますか? 検索して出てきたホームページを見て 「とりあえずこのホームページにあるように最新のGCを指定したし、同じようにオプションを設定したから大丈夫だろ」 と思ってしまう話をよく見聞きします。 図1 誤ったGCの選択 しかし、たとえばバッチのようにスループットを意識すべき処理にもかかわらず、レスポンスタイム重視のGCを選んでしまうのは適切ではありません。 最終回となる今回は、HotSpotにはどのようなGCがあり、どのようにそれらを選択すれば良いのかを紹介します。 4つのGCを使いこなす HotSpot JVMには、以下の4つのGCが実装されています。 シリアルGC パラレルGC コンカレント マーク&スイープGC(CMS) ガベージファーストGC(G1GC) 1つずつ見ていきましょう。 シリアルGC このGCの特徴は、ヒープの
どうも!@yokotaso です! 2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。 現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。 発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます! 発表資料は、speakerdeck にあります。はじまり〜はじまり〜 はじめに 今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。 現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。 さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。 次にShenandoahGC、ZGC、E
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く