You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
This is something I am pretty excited to tell you about. But first, some motivation. In managed applications, there’s a huge number of tools and ways to inspect the manage heap contents. You can use a memory profiler to see references between objects and inspect individual objects. You can use WinDbg with the SOS extension to dump all objects of a particular type and execute additional scripts and
Introduction Memory leak is a time consuming bug often created by C++ developers. Detection of memory leaks is often tedious. Things get worst if the code is not written by you, or if the code base is quite huge. Though there are tools available in the market that will help you in memory leak detection, most of these tools are not free. I found Windbg as a freeware powerful tool to solve memory le
読み直してみると、読みたくなくなる記事だなwwww なので端的に… 1. Global Flagsを使って設定 2. WinDbgを実行 3. !heap -stat -h 0 4. プロセス実行 5. !heap -stat -h 0 6. 1.と3.の結果を比較 7.!heap -flt s サイズ 8.!heap -p -a アドレス この8手順を踏めば、メモリリークの(おそらく)原因の場所が突き止められます。 さて読みにくい本編です。 外部DLLを使っているので、.NETでおきているのか、外部DLLでおきているのかさっぱり解らなかったが このツールを使ってみると、なんとなーくみえてきた。 で、その使い方と注意事項をまとめてみました。 使ったツール: WinDbg Global Flags ダウンロードファイル:(2012年5月現在) winsdk_web.exe URL:http:
ANOOB BACKER Technical Blog about C, C++, Java, C#, SharePoint, Algorithms, Shell Script Tips, Tricks, Tweaks and Hacks Windbg is a tool from the house of MS. It come handy when debugging in a production enviornment as it is light weight. I have been using Windbg for the last few weeks and I would like to share some tips. Let us start of with memory leak analysis! Download Location: Debugging Tool
– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 – その5: Memory Analyzer でヒープダンプを解析(最終回) 延々と連載してきたメモリリークトラブルシューティング記もいよいよ最終回です。 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプ
原文: チャールズ=オリバー=ナター 前回の記事「JRubyでメモリを観察するには」の後、何人かの人からEclipse MATのJRubyでの使い方について書いてみたらどうかとの意見を貰いました。これを早速取り上げる事にします。 Eclipse Memory Analyzerは他のEclipseを基盤にしたアプリケーションの例に外れる事なく、起動すると基本ページから個々の作業向けのページへと移動します。 MATは、jhatに較べてもっとインタラクティブにヒープダンプを解析する事が出来ます。MATはjmapのダンプファイルを解析出来ますので、メモリリークを起こしているRailsのアプリケーションからダンプを取ってくる事にしましょう。 このコントローラをアプリケーションに加えました。 class LeakyController < ApplicationController class MyD
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
最適化処理など膨大なデータを繰り返し使う処理で、処理が先に進むほど処理スピードが遅くなったり、OutOfMemoryError例外が発生してしまうことがあります。このような場合はまずプログラムが使用するメモリ量を拡張してみます。それでも解決できない場合はメモリの開放漏れ(メモリリーク)の可能性がありますので「Eclipse Memory Analyzer」を使って調査をします。以下はその手順です。 プログラムが使用するメモリ量を拡張する javaプログラムの起動時に使用するメモリー量の初期ヒープサイズ(-Xms)、最大ヒープサイズ(-Xmx)、New世代領域サイズ(-Xmn)を指定します。以下が入力例ですが200mのように数字の後ろについているmはメガを意味します。私の場合、かなり負荷の高い最適化でも以下の設定であれば快適に動きます。 「Eclipse Memory Analyzer」でメ
New Releases Zend Server 2018 improves the performance and scale of your apps with multiple deployment options, caching insights, and improved support. Klocwork 2018.1 features industry-leading support for C++17 analysis, improved standards coverage, and better support for DevOps environments. TotalView and CodeDynamics 2018 improves mixed language debugging and streamlines your debugging sessions
Introduction Memory Leak is a decease and OutOfMemoryError (OOM) is the symptom for that. However all OOM doesn’t necessarily implies Memory Leak. OOM can happen due to the generation of large number of local variables – particularly with large number of concurrent requests (in the case of server applications). On the other hand all memory leaks not necessarily manifest into OOM – especially in th
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
google-perftools(tcmalloc)の使い方 2007-12-17 (Mon) 22:59 Google OSS PFIでは毎週1人適当な話題で発表しているのですが、この間「GooglePerfToolsの使い方」という軽いお題で発表した資料を公開してみます。メモリ周りの問題は大変ですよね…。 google-perftools - Fast, multi-threaded malloc() and nifty performance analysis tools 肥え続けるTomcatと胃を痛めるトラブルハッカー ローテクなメモリ使用量監視方法 特にC++で長期運用中のメモリリークに苦しんでおられる方には役立つかと思います。基本的にドキュメントの日本語訳ですが。SlideShareだとなぜか図がずれるので、元ファイルをこちらに置いておきます。 | View | Upload
I fixed the Angerwhale leak. The main problem was knowing where to look for the leak, but Alias++'s Devel::Leak::Object cleared things right up. I ran angerwhale like this: ANGERWHALE_EXIT_OK=1 perl -MDevel::Leak::Object=GLOBAL_bless script/angerwhale_server.pl -d Then I hit it a few hundred times to exaggerate the per-request leaks: ab -n 300 http://localhost:3000/ Then I told it to exit, so I co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く