タグ

javaとmemoryに関するoinumeのブックマーク (27)

  • 富豪的 Android プログラマの為の Eclipse Memory Analyzer Tool 入門 - sandbox

    はじめに Android プログラマのみなさん、こんにちは。 今日も元気に Out Of Memory してますか? ということで、この記事では日々 OOM に悩まされる Memory 的な意味で富豪的な Android プログラマの為に、Eclipse Memory Analyzer Tool、通称 MAT の基的な使い方を紹介します。 尚、この記事は [twitter:@youten] さんが企画された裏 Android Advent Calendar 12/20 の記事ですが、内容的には比較的オモテなものになっています。 対象読者 Andoid アプリ作ってる/はじめたけど、まだ MAT を使ったことがない方 MAT を使ってみようした事はあるものの、画面から難しそうな雰囲気を察知し、起動10秒後にはそっとタブを閉じてしまった経験がある方 DDMS の基的な使い方を理解している方

    富豪的 Android プログラマの為の Eclipse Memory Analyzer Tool 入門 - sandbox
    oinume
    oinume 2014/01/18
    Eclipse Memory Analyzerのわかりやすい解説
  • ガベージコレクションエルゴノミクス

  • JVMのチューニング - ITエンジニアとして生きる

    前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体(New領域+Old領域)の初期値 -Xmx ・・・ ヒープ全体(New領域+Old領域)の最大値 くらいしか話題に上がらないし意識しないことが多い(気がする)。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下2つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時

    JVMのチューニング - ITエンジニアとして生きる
    oinume
    oinume 2013/06/20
    なるほど。「New領域のチューニングにおける関心事は「最大ヒープサイズ(-Xmx)の何分の1とするか?」であるため、「-XX:NewRatio」にて設定をする方が良いと思う。」
  • オンラインマニュアル ページ移転のお知らせ:ミドルウェア:ソフトウェア:日立

    日立オープンミドルウェアは、お客様の既存の財産を生かしながら、高い信頼性と柔軟性、自律性を備えたITシステムの実現を支えています。

  • Javaのメモリ管理

    日のカクテルは「Javaのメモリ管理」です。 ネタ元はかつのりさんのBlogです。 GCについて勘違いしている人が結構多い JavaというとGC(ガーベッジコレクション)によって不要となったオブジェクトが回収される仕組みになっていますので、一般のプログラマはメモリの確保、解放について考える必要がありません。 ただし、プロフェッショナルなプログラマの方は一般のプログラマの分まで背負い込んで考えてもらう必要があります。 C言語のようにメモリの割り当てと解放を直接管理することはありませんが、まったく別種のメモリ管理が必要となってきます。 参照の種類 「要するに、参照がなくなればGCに回収される、参照があれば回収されない、それだけのことだろう?」 こうおっしゃるお客さんは沢山いらっしゃいます。では、参照にも種類があることをご存じですか? 強い参照 (strong reference) ソフト参照

  • @IT:事例に学ぶWebシステム開発のワンポイント(6)APサーバからの応答がなくなった、なぜ?

    今回のワンポイント アプリケーション・サーバから応答がない、いわゆる無応答状態は、ベンダのサポートセンターに寄せられる質問でも数が多いといわれている。無応答状態の原因の多くはGC(ガベージ・コレクション)にあり、これはGCチューニングにより解消可能だ。今回の記事では、GCチューニングにより無応答状態を解決する道のりを紹介していく。 サーバから応答がない、なぜ? あるとき、長時間レスポンスが返ってこないという事象が発生した。定期的な応答時間の監視から、無応答状態はアプリケーション・サーバを起動してから数時間経過すると発生し、数分間無応答状態が続いた後に再び正常に処理を開始することが分かった。 無応答の原因を探る 筆者はこの現象を見て、無応答が数分間で終わっていることからガベージ・コレクション(GC)が原因であるとの仮説を立てた。GC実行中、アプリケーション・サーバのCPUはGCのためだけに使

    @IT:事例に学ぶWebシステム開発のワンポイント(6)APサーバからの応答がなくなった、なぜ?
    oinume
    oinume 2012/10/16
    SurvivorRatioについて
  • OutOfMemoryErrorはメモリー不足ではない | carblie – engineer, guitarist

    久々の書き込み。諸事情により書き込みペースが落ちます。落ちました。 apache + tomcat + database の組み合わせシステムって当たり前の時代になっていると思いますが、開発当初は資源の使い方をあまり精査せずに開発するので、プログラムの試験中に時折こういうエラーにぶち当たることがあります。 致命的: java.lang.OutOfMemoryError: unable to create new native thread java から発せられた OutOfMemoryError です。要はメモリー不足っていうわけ。 javaのメモリー不足と言ってもいろいろな種類があるんですよ。システム全体のネイティブメモリをはじめ、javaが確保したヒープメモリも。普通はそう言うところの資源が枯渇して起きたエラーだと思うものです。しかし、今回は違っていた・・・ サーバプログラムに

  • JavaのGC頻度に惑わされた年末年始の苦いメモリ

    JavaのGC頻度に惑わされた年末年始の苦いメモリ:現場から学ぶWebアプリ開発のトラブルハック(9)(1/3 ページ) 連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) Java言語を利用するようになって、システムを開発するうえで楽になった要素は何かというアンケートがあったとき、読者の皆さんならどのように回答するだろうか。私は迷わず、「メモリ管理」と回答する。 同時に、Javaを利用してシステム開発を行う際に、注意していること、悩まされたことは何かとアンケートがあれば、「GC(ガベージ・コレクション)」と回答するだろう。 多くのシステム開発の現場では、いまこの瞬間も、JavaのGCの挙動に悩まされ、GC

    JavaのGC頻度に惑わされた年末年始の苦いメモリ
  • Eclipse Memory Analyzer, 10 useful tips/articles

    Vatel said... Hello Markus, I would like to share my own experience of using MAT. MAT is really a great tool, but your should known well how to use it! Unfortunately, by default MAT shows some useless windows, so you may be disappointed. OK, below is my "How to", it would be great to compose a tutorial based on it and include it into MAT docs: =============================================== How to

  • Java コードから Java ヒープまで

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Java コードから Java ヒープまで
  • Solving OutOfMemoryError (part 6) – Dump is not a waste | Plumbr – User Experience & Application Performance Monitoring

    March 27, 2012 by Nikita Salnikov-Tarnovski Filed under: Memory Leaks Let us continue our series of posts about solving the OutOfMemoryError in our hypothetical production system. We have described  different methods to tackle the problem, and today’s post concentrates on what you can learn from heap dumps. Spoiler alert: with a bit of luck, you can get very close to solving the OOM. In retrospect

    Solving OutOfMemoryError (part 6) – Dump is not a waste | Plumbr – User Experience & Application Performance Monitoring
  • Oracle Java Technologies | Oracle

    Java Is the Language of Possibilities Java is powering the innovation behind our digital world. Harness this potential with Java resources for student coders, hobbyists, developers, and IT leaders.

  • JRubyのメモリを観察するには

    原文: チャールズ=オリバー=ナター Ruby言語の各実装において、どんなメモリ消費を解析するツールがあるのかが近頃ちょっとした話題になっています。 それもその筈、Rubyで書かれたアプリケーションの(不具合の調査は言うに及ばず)メモリ消費の具合を詳しく調べるのは容易い事ではありません。 JRubyを使わないのなら、そうです。 JRubyはJVM上で走るので、JVM向けに作られた何十ものツールの恩恵に授かる事が出来ます。 中にはJDKに同梱されているものを含め、メモリの調査、解析、レポートをするものもあります。 ヒープダンプが欲しければ、Hotspot系のJVM(SunまたはOpenJDK)に含まれるjmapやjhatが使えます。 もっと高度なツールが欲しければ、Eclipseを基にしたMemory Analysis Tool、 メモリ及びCPU性能解析ツールであるYourKit、 今では

    JRubyのメモリを観察するには
    oinume
    oinume 2012/03/01
    jmapとはjhatとかVisualVMとか。
  • メモリリークトラブルシューティング記 – その5: Memory Analyzer でヒープダンプを解析(最終回) – yusuke.blog

    – その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 – その5: Memory Analyzer でヒープダンプを解析(最終回) 延々と連載してきたメモリリークトラブルシューティング記もいよいよ最終回です。 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプ

    メモリリークトラブルシューティング記 – その5: Memory Analyzer でヒープダンプを解析(最終回) – yusuke.blog
  • “Stop the World”を防ぐコンカレントGCとは?

    この表2のパラメータは、動作させるマシンのCPUが2個以上かつ物理メモリが2Gbytes以上の場合には、自動設定される。 ■Heapの全体サイズを指定する コンカレントGCでも、スループットGCと同じくHeapの全体サイズを指定する。ヒープの全体サイズは、以下を考慮に入れて設定する。 OSの空きメモリ量 Heapの全体サイズは、ハードウェアの搭載物理メモリ量から、OSやそのほかのソフトウェアが必要とするメモリ量を引いた値以下にする。これは、Heapのサイズを大きくし過ぎると、スワップが発生し大幅に性能が劣化するためだ アプリケーションが必要とするメモリ量 ユーザーごとにHttpSessionに積み込むオブジェクトのサイズや、キャッシュされたオブジェクトのサイズなど、必要となるオブジェクトのサイズを積算し、それ以上の値にする 実際には、アプリケーションが必要とするメモリ量を積算することは難し

    “Stop the World”を防ぐコンカレントGCとは?
    oinume
    oinume 2011/08/02
    heapに12GBとか指定する場合はコンカレントGC使えばいいのかな。
  • ページが見つかりません | 日本HP

    ページが見つかりません。 目的のページは、移動または削除によって無効になっている可能性があります。申し訳ありませんが、検索またはリンク先よりお探しください。

    oinume
    oinume 2011/08/01
    このドキュメントしっかりしてる上にわかりやすい
  • メモリ使用量 - external storage 1

    余分に使用されるメモリの量 from(to) = NewSize / (1 + 1 + SurvivorRatio) 例 -Xms2560m -Xmx2560m -XX:NewSize=768m -XX:MaxNewSize=768M -XX:SurvivorRatio=8 768m / (1 + 1 + 8) = 77m eden 616m from(to) 77m [ParNew 655720K->141587K(2542848K), 0.5363089 secs] Heap after gc invocations=2: par new generation total 707840K, used 78592K [0xfffffd7f52a00000, 0xfffffd7f82a00000, 0xfffffd7f82a00000) eden space 629248K, 0% use

    メモリ使用量 - external storage 1
  • Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か

    GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは?(0.1秒未満ぐらいを目指したい?) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu

    Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
    oinume
    oinume 2011/07/04
    すごいいいまとめ
  • Ehcache - Off-heap Store

  • Java very large heap sizes

    If your application is not interactive, and GC pauses are not an issue for you, there shouldn't be any problem for 64-bit Java to handle very large heaps, even in hundreds of GBs. We also haven't noticed any stability issues on either Windows or Linux. However, when you need to keep GC pauses low, things get really nasty: Forget the default throughput, stop-the-world GC. It will pause you applicat

    Java very large heap sizes