![http://www.be9.io/2015/09/21/memory-leak/](https://cdn-ak-scissors.b.st-hatena.com/image/square/9d55cb67e2610feef3a4264c04bb3c30317c85e9/height=288;version=1;width=512/http%3A%2F%2Fwww.be9.io%2Fassets%2Fimages%2Fheroku_metrics_noleak.png)
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 iPhone6/6 Plusのメモリが1GBしかない理由 この記事が突っ込みどころが多いと話題になっています。初期の頃はiOSのなめらかな動きと比べたらAndroidは劣化版と言われても反論できない感じでしたが、Nexus 4/Nexus 5ともなるとだいぶ快適で乗り換えても違和感なく使えるようになりましたが、同じぐらいの快適さが得られるハードウェアを比べてみると、メモリも半分で、コア数も半分で、クロック周波数も半分で、バッテリーにやさしいハードウェアになっていることは確か。なぜそれでやっていけるのか、ということについて僕なりの理解をまとめます。元の英語記事は読んでません。 メモリ管理方式の違い Androidはマーク・アンド・スイープ方式のGCで、iOSはNSAutorele
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 mod_mrubyはmrubyのmrb_stateをApacheのサーバプロセス上で使いまわすアーキテクチャをとっています。基本的にプロセスは起動しっぱなしなのですが、リクエストを大量に処理すると、プロセスのメモリがどんどん太っていく問題がありました。 これは、mruby-uv等でも報告されており、どうにか改善したいと思っていました。そこで、twitter上でいくつかmatzさんとやり取りしながら、valgrindでメモリのLEAKとHEAPを調査の上、mallocのフラグメントを疑い、jemallocでmallocをフックするとどのようにメモリ使用量が改善するかを実験しました。 valgrindでApacheをデバッグ valgrindでA
Download Visual Leak Detector 1.0 - 476 Kb Download the 1.9d beta version of Visual Leak Detector (includes source) - 728 Kb Download the source code (version 1.0) - 50.3 Kb Table of Contents Introduction What's New? Using Visual Leak Detector Making a Memory Leak Detector Key Parts of the Source Code Known Bugs and Restrictions Credits References License History Introduction Visual C++ provides
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く