タグ

JVMとjvmに関するskypenguinsのブックマーク (5)

  • TOMCAT殺害事件 - Qiita

    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

    TOMCAT殺害事件 - Qiita
  • JVMのヒープサイズとコンテナ時代のチューニング | Folioscope

    最近 JVM のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ

  • CodeIQについてのお知らせ

    2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

    CodeIQについてのお知らせ
  • 最小 Hello World! チャレンジ

    3. まずは Java で class J { public static void main(String args[]) { System.out.println("Hello World!"); } } -rw-r--r-- 1 kawachi staff 408 Mar 3 23:07 J.class javac して… 408 bytes 4. javap -c でみてみる $ javap -c J.class Compiled from "A.java" class J { J(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/ Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: getstat

    最小 Hello World! チャレンジ
  • 恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、

    恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ
  • 1