とある愚直のリニアサーチ - 神様なんて信じない僕らのために
前のエントリで線形探索のメモリアロケータは駄目だ駄目だ、と言いました。 で、まず線形探索の何が駄目って、メモリは以下のようになっています。 最初は「未使用領域（青）」しかありません。ここからどう領域をとっても良いです。 ただ、使っていくうちに「使用領域（赤）」と「未使用領域（青）」の数珠つなぎになりがちです。 new/deleteの順番を意識すればこういったメモリの配置問題が解決できることもありますが、 実際には「クラスがメモリの状態に束縛される」とすると非常に面倒です。 なので、効率的なアロケータは必須なのです。 あなたが下のような断片化した領域をつなぐ双方向リストを持っていると仮定してください。 ここから効率よくメモリを探すことは絶対にできません。 ソートしておくといったことも考えられますが、ソートすると解放された領域のマージが困難です。 （freeされた隣接した領域はより大きなメモリ
Google が公開しているソフトウェアの解説（その4）- Performance tools -
Google が Google Code でオープンソースとして公開しているソフトウェアの解説シリーズ(前回のエントリ)の第 4 回です。今回は Performance tools について紹介します。この Performance tools は、実際に Google 社内で広く使われており、特に、C++ でテンプレートを使用するマルチスレッドアプリケーションを開発する際に役立ちます。Linux 環境を主に対象としています。 Performance tools とは? C や C++ でプログラムの書いたことのある多くの人は、「プログラムを高速化したいけれど、どこが一番のボトルネックか分からない」とか、「メモリリークがあるようだけれど、どこで発生しているか分からない」といった問題で苦しめられた経験が一度くらいはあると思います。もちろん、こうした問題の解決策として、アドホックにプログラムをチ
C/C++セキュアコーディング 動的メモリ管理：dlmalloc
C/C++ セキュアコーディング 動的メモリ管理：dlmalloc 2010年3月23日 JPCERTコーディネーションセンター Japan Computer Emergency Response Team Coordination Center : Japan Computer Emergency Response Team Coordination Center DN : c=JP, st=Tokyo, l=Chiyoda-ku, email=office@jpcert.or.jp, o=Japan Computer Emergency Response Team Coordination Center, cn=Japan Computer Emergency Response Team Coordination Center : 2010.03.23 17:53:49 +09'00'
第2回 memcachedのメモリストレージを理解する | gihyo.jp
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
Windows で Large Page は「使える」か？ - NyaRuRuが地球にいたころ
VirtualAlloc で実験していたネタもついでに放出． Firefox 版 jemalloc のソースを読んでいて，デフォルト chunk size が 1 MB と比較的大きかったので，「それなら Large Page 割り当てても良いんじゃなかろうか？」と調べてみました．もっとも，結論から言えば，Windows 環境の Firefox のメモリアロケータに Large Page を使うのは，全く現実的ではないということが分かっただけでしたが． Large page support Windows Server 2003 から，ユーザーモードアプリケーションでも large page が使用できるようになった．Windows Vista でもサポートされる．VirtualAlloc に MEM_LARGE_PAGES フラグを付ける．large page の最小サイズは GetLa
Linuxメモリ管理の最先端を探る（1/2） － ＠IT
小崎 資広 2008/5/22 この記事では、Linux Kernel Watchの番外編として、Linuxの最近のメモリ管理周りの動きと、その背景のモチベーションについてお伝えしたいと思います。 メモリ管理は変更時のインパクトが大きいため、通常、Stable Tree（安定ツリー）ではあまり変更はなされません。しかし、Linuxカーネルメーリングリスト（LKML）の議論では「もうカーネル2.7は出ない」ともいわれており、十分なテストがなされたものであれば、アグレッシブなパッチでも受け入れられるようになっています。 また、メモリの急速な大容量化により、いままで問題にならなかった部分にスケーラビリティ上の問題が発生したという報告もちらほら出てきました。それを解消するためのさまざまな改善が提案されています。 こうした背景により、2007年から2008年にかけては相当面白いパッチが出てきました。
革命の日々！ MALLOC_TRIM_THRESHOLD_ と MALLOC_MMAP_MAX_ パラメタについて
どうもあまり有名ではないらしいので、ここで書いてみる。 http://mkosaki.blog46.fc2.com/blog-entry-241.html で書いた事とほぼ同じだけれど。 Linuxにおいて、CPU負荷を測定するベンチマークでは以下の環境変数を設定すると往々にして性能があがる。 % setenv MALLOC_TRIM_THRESHOLD_ -1 % setenv MALLOC_MMAP_MAX_ 0 MALLOC_TRIM_THRESHOLD_ はOSに未使用になったメモリを返却する契機をあらわしていて、－１は決して返却しない事を表す。 MALLOC_MMAP_MAX_ は最大mmap数で０は決してmmapせず、どんなに大きなメモリでもbrkを使ってメモリを取る事を意味する。 で、性能に効くのは（たいてい）MALLOC_MMAP_MAX_のほう。 glibcはアンチフラグ
google-perftools(tcmalloc)の使い方 - moratorium
google-perftools(tcmalloc)の使い方 2007-12-17 (Mon) 22:59 Google OSS PFIでは毎週１人適当な話題で発表しているのですが、この間「GooglePerfToolsの使い方」という軽いお題で発表した資料を公開してみます。メモリ周りの問題は大変ですよね…。 google-perftools - Fast, multi-threaded malloc() and nifty performance analysis tools 肥え続けるTomcatと胃を痛めるトラブルハッカー ローテクなメモリ使用量監視方法 特にC++で長期運用中のメモリリークに苦しんでおられる方には役立つかと思います。基本的にドキュメントの日本語訳ですが。SlideShareだとなぜか図がずれるので、元ファイルをこちらに置いておきます。 | View | Upload
jemalloc (#1172213) | Netcraft Web Server 調査結果、Googleが突如シェア取得 | スラド
サーバーアプリケーションの比較しか話題にのぼっていませんが、良く考えるとGoogleのサーバーが世界の全てのWebサーバーの約4%を占めるということですよね。1社だけでここまでのシェアを持っているというのは驚くべき事のように思います。 Yahoo!はFreeBSDにaccept_filterなどの形で還元していますけれど、Googleも何かそういう活動をしていたのかしらん。ちなみに、accept_filterというのは特定のメッセージ列がカーネル内でバッファリングされるまでacceptシステムコールの返事をするのを遅らせることで、コンテキストスイッチを何回もすることによるオーバーヘッドを削減するという機構です。メッセージ全てがバッファリングされていると、read一発で読めますからね。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ActiveState Community