19.1 OutOfMemoryError発生時の対処
Javaアプリケーション実行時にOutOfMemoryErrorが発生した場合、次の原因が考えられます。 Javaで使用するメモリ(ヒープ域)不足 通常、OutOfMemoryErrorは、このケースで発生します。 Javaの使用するメモリは大別すると次の3つに分かれます。 New世代領域 Old世代領域 Permanent世代領域 仮想メモリ不足 ヒープ域以外にシステムの仮想メモリが不足した場合にもOutOfMemoryErrorが発生します。このような場合、仮想メモリを増やすように変更をお願いします。 なお、仮想メモリが不足してスレッドが生成できない場合、OutOfMemoryErrorに次の情報が付加されます。 java.lang.OutOfMemoryError: unable to create new native thread Javaプロセスのユーザ空間不足 ヒープ域やシス
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
JavaVMのメモリ管理に関するまとめ（Javaヒープ、GC、ダンプ等） - ぺーぺーSEのブログ
本ブログはJava8（特にMetaspace）に対応していない。 下記にJava8以降に対応した記事を記載する（予定）。 blog.pepese.com JavaVMのメモリ領域について JavaVMが管理するメモリ領域について 階層1 階層2 階層3 説明 Javaヒープ JavaVM上で起動するJavaプログラムのリソースを管理する領域。New領域とOld領域で構成される。 ｌ" New領域 新規オブジェクトと閾値（-XX:MaxTenuringThreshold）未満のオブジェクトが配置される。（Young領域とも呼ばれる） ｌ ｌ" Eden領域 新規のオブジェクトが配置される。 ｌ ｌ" From領域 CopyGC(ScavengeGC、マイナーGC)が実行された際に、使用中のオブジェクトはここへコピーされる。（S0やS1とも呼ばれる） ｌ ｌー To領域 CopyGC(Scav
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
リソース監視・確認コマンド逆引きメモ(Java編) - Qiita
JVMのリソース監視、確認に使うコマンド集 以下はOracle Hotspot JVM version 1.7.0_79 、 OSはCentOS 6.3で確認したもの。 [root@localhost opt]# java -version java version "1.7.0_79" Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) [root@localhost opt]# cat /etc/issue CentOS release 6.3 (Final)
JVMのメモリ使用量 - ふなWiki
参考 https://i-beam.org/2019/08/15/jvm-heap-sizing/ JVMのメモリの使用量 http://promamo.com/?p=2828 JVMはヒープ以外にもかなりメモリを使っている。 Eden領域 new演算子によって作成されたJavaオブジェクトが最初に格納される領域である。 Survivor領域 New領域に格納されていたJavaオブジェクトのうち，ガベージ・コレクション実行時に破棄されなかったJavaオブジェクトが格納される領域である。Survivor領域は，From空間とTo空間で構成される。From空間とTo空間のサイズは同じ。 Tenured領域 長期間必要であると判断されたJavaオブジェクトが格納される領域である。Survivor領域で指定回数を超えてガベージ・コレクションの実行対象となり，破棄されなかったJavaオブジェクトが，
Javaヒープ領域の使用量と容量をコマンドラインから取得する #java - nori3tsu's blog
JDKに標準で入っているjstatコマンドを使います。jstatコマンドではJavaヒープ領域中のNew領域・Old領域・Permanent領域の使用量・容量・最小容量・最大容量などを取得することができます。 ※ 2015/06/24追記: こちらはJava7までのヒープ領域についての記事です。Java8はPermanent領域がないなどの違いがあるため、別途Java8のjstat公式ページを参照してください。 Javaヒープについて Javaヒープ領域を指定するJVMオプションは-Xms,-Xmxです。このオプションで指定しているJavaヒープ領域のサイズはNew領域とOld領域を合算したものとなり、Permanent領域は含まれていません。また、New領域はSurvivor領域0(From)+Survivor領域1(To)+Eden領域の合算です。 取得方法 -gcオプションでJava
「メモリーを意識してみよう」第3回 ヒープのチューニング
Java2Demoの起動が確認できたら，jconsoleを起動してみましょう。 先々週と同様に，jconsoleの「メモリ」タブで各領域の使用状況を参照できます。 左上のコンボボックスにはデフォルトで「ヒープメモリの使用状況」が選択されています。このコンボボックスを展開するとEden，Survivor，Tenuredなどが並んでいます（図1）。Perm Genなどの項目はヒープではない非ヒープ領域に属している領域です。 Survivor領域は実際には二つありますが，常にどちらかは空なので，一つにまとめて扱われているようです。 この中から，Eden領域を選択してみましょう。 Eden領域の使用量は，だいたい0から1MB程度の範囲に収まっています（図2）。 左下の詳細の部分を見ると，確定（MemoryUsageのcommitted）が1MB，最大が4MBであることがわかります。 つまり，Ede
＠IT：Javaパフォーマンスチューニング 第3回
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
「Java のヒープサイズ」についての簡単な説明
Java のヒープ領域及び 非ヒープ領域、メモリ管理について簡単に説明いたします。 ヒープやヒープサイズはガーベジ・コレクション：GC ( Garbage Collection ) と密接な関連があります。以下のページも合わせて参照ください。 ガーベジ・コレクション：GC ( Garbage Collection ) についての簡単な説明と調査方法 Java のオブジェクトは、大きく分けて、New、Old 、Permanent というメモリ領域で管理されます。 新しいオブジェクトを格納するのが New 領域と呼ばれ、古いオブジェクトを格納するのが Old 領域と呼ばれます。 Permanent 領域にはクラスやメソッドなどの情報が格納されます。 ( これらは Permanent Generation, Tenured Generation, Young Generation とも
ふわっと JVM のヒープ領域監視について考える | iret.media
ども、かっぱです。 はじめに Java アプリケーションを運用する上では避けて通れないであろうヒープ領域の監視についてフワッと考えてみた JVM には幾つか領域があるがヒープ領域に焦点を当てる 参考 http://www.whitemark.co.jp/tec/java/javaHeap.html http://www.whitemark.co.jp/tec/java/javagc.html http://d.hatena.ne.jp/ogin_s57/20120623/1340463194 http://d.hatena.ne.jp/ogin_s57/20120709/1341836704 https://docs.oracle.com/javase/jp/1.5.0/guide/management/agent.html http://chonaso.hatenablog.com/en
Swiftの循環参照問題におけるunownedとweakの使い分けについて - Qiita
循環参照するか、しないかの切り分け 循環参照するか、しないかの切り分けはエンジニアが考慮する必要があります。この切り分けはObjCと同様なので、ここでは詳細には触れません。 ちなみに、Xcode6 Beta5のSwiftではコンパイルワーニングで循環参照を知らせてくれません。とはいえ循環参照のコンパイルワーニングはObjCでも全部網羅されていないので、最終的にはエンジニアが考慮する必要があるのはかわらないのですが。 対象の変数をweakで対応し、実行時に変数がnilになる可能性の切り分け そもそも、実行時に循環参照する対象の変数がnilになる可能性で判断ではなく、対象の変数定義がOptional定義かどうかで判断できないか 常にOptional定義かどうかで判断できないのではと思っています。例えばselfはself!としてunwrapしてアクセスしないので、selfはOptionalではな
Linux/メモリ確保とVSZとRSS - discypus
(2003-12-14 新規作成) Linuxでメモリ確保したときのVSZ,RSSとfreeの値の変化。 RedHat 7.2 (kernel 2.4.7-10) + apt(freshmeat.net)使用。 [編集]課題 # VSZとRSSの合計を表示すると、 $ ps -eo vsz,rss | awk '{v+=$1;r+=$2}END{print v,r}' 53212 25264 freeより少ないのだが、なにがメモリ(50MB以上)を使っているのか？ プロセスがスワップされるとps uxのSTAT欄がSWになるはず。 このとき、VSZ,RSSの値は0になった‥‥と思うが、本当にそうか？ （Linux-users-MLで話題になったと思う） LibraryとSystemCallの確認 (timestampつき) $ ltrace -r -o ltrace.log ./vsz $
ハードウェアによる仮想化はソフトウェアによるものより本当に高速なのか？ - 教育は参考ブログ
VMware | A Comparision of Software and Hardware Techniques for x86 Virtualization (PDF) Slashdot | Hardware Virtualization Slower Than Software? VMware の研究者が面白い論文を発表*1している。現状の VT-x/SVM を使った x86 の仮想化はソフトアシストによるものよりも必ずしも高速にならないとのこと。 問題はハードウェアの仮想化支援は MMU まで及んでおらず、MMU をハードウェア VT + ソフトトラップするよりはソフトウェアのみで処理した方が現状では速いとのこと。 従って AMD の Nested Pageing や Intel の EPT が出てくると話が変わるかもしれない。 P.S. この論文をよく読んでみると、凄いことが色
MySQLメモリ使用量の計算 « kawama.jp
って、どうやればいいんだろう？？ と思って調べてみたらドンピシャのエントリを発見。 http://antas.jp/blog/ina/archives/2007/05/mysql_1.html max_connections * (sort_buffer_size ＋ join_buffer_size ＋ read_buffer_size ＋ read_rnd_buffer_size ＋ max_allowed_packet) <-- カッコ内は1接続あたりの使用メモリ ＋ key_buffer_size ＋ query_cache_size ＋ innodb_buffer_pool_size ＋ innodb_additional_mem_pool_size ＋ innodb_log_buffer_size ということです。参考にさせていただきました。 ツール amazon商品情報ビュー
ダンプ解析講座 VA Linux Systems Japan
ダンプの解析を行なうためには、ダンプの構造を理解しておく必要があります。 前回、ダンプはメモリの内容を吐き出したものだと説明しましたが、実際の中身は、どのような形式になっているのでしょうか。ダンプの中身の形式は、ダンプ採取機能によって異なることがあります。kdumpでは、ELF形式で吐き出しています。 ELF形式なので、readelfコマンドで中の形式を覗くことができます。早速、覗いてみましょう。 タイプが「CORE」と言うことで、プロセスのコアファイルと同じ形式になっています。ただし、プロセスのコアファイルは、プロセスの仮想アドレス空間を吐き出したものですが、ダンプの場合は物理アドレス空間を吐き出したもので、意味が異なっているので注意してください。ダンプは、カーネルの仮想アドレス空間を吐き出したものではありません。ダンプのフォーマットにコアファイルのフォーマットを借用しているというのが正
メモリダンプを眺めてみる - One By One - norizo333's Blog -
必要に迫られまして、Cもアセンブラもサッパリなのにクラッシュダンプの解析を試みようかと思い立った今日この頃。 とりあえず稼働中のシステムのメモリでも眺めながら、纏めて勉強するかということで、まずはメモリダンプが見れるとこまで。 環境： MacBook (OS X 10.5.3) で VMware Fusion に CentOS 5.1 yumのリポジトリにはkernel-debuginfoパッケージが見当たらなかったので、ソースからリビルドするかなと思いつつ一応ググってみると http://debuginfo.centos.org にパッケージを発見しました。 kernel-debuginfoパッケージをインストール $ wget http://debuginfo.centos.org/5/i386/kernel-debuginfo-2.6.18-53.el5.i686.rpm $ wge
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Charming Python: Functional programming in Python, Part 3
Togetter - 「autoreleaseのひみつ」
IBM Developer
