read(2) vs mmap(2) の迷信
この記事は、シェルスクリプトの記事よりも前に読んだような気がする。同じくらい古い記事だけれど、ちょっと書いてみる。記事への反論はいくつか検索すると見つかって、たぶんみんな知っていることなのだと思うけれど、まとまって書かれている文章はないみたい。 tl;dr read(2) と mmap(2) の性能差に絶対的な回答はない。どちらか一方が常に高速だと主張している文章は、根拠が証拠とともに明確に書かれていない限り信用しないほうが良い。 メモリコピーのコストが高かった時代と、L1キャッシュが巨大になってメモリコピーのコストが低くなった時代と、SMPが一般的になってメモリのマッピング処理のコストが高くなった時代とで、この性能差は頻繁に入れ替わっている。少なくともスループットとレイテンシを分けないで分析できるものではない。 まず当該記事には技術的な間違いがいくつかある。 「mmap()はユーザランド
Mappedbus: A library for low latency IPC between multiple Java processes/JVMs
A library for low latency IPC between multiple Java processes/JVMs Mappedbus is a Java based high throughput, low latency message bus, using either a memory mapped file or shared memory as transport Mappedbus was inspired by Java Chronicle with the main difference that it's designed to efficiently support multiple writers – enabling use cases where the order of messages produced by multiple proces
続:memory mapped file が消せない - odz buffer
memory mapped file が消せないの続き。 なんか、Java APIドキュメントのFileChannel#map の項目を良く見ると、 バッファとこのバッファが示すマッピングは、バッファ自体がガベージコレクトされるまで有効です。 とか書いてやがる。で、試しに File#delete を call する前に明示的に GC するようにしてみた。 File = new File("foo.txt"); FileInputStream in = new FileInputStream(file); FileChannel channel = in.getChannel(); MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, 0, file.length()); channel.close(); b
細かすぎて伝わらないmdbm
おまけ話として、mdbmはLinear Hashingと呼ばれるハッシュアルゴリズムの影響を強く受けています。 Linear Hashingの詳細はwikipediaをご覧ください。 http://en.wikipedia.org/wiki/Linear_hashing このアルゴリズムによりmdbmは、扱うデータサイズが大きくなれば、動的にHashTableを拡大することができる非常に便利な特性を持っています。 しかし、冷静になって考えてみてみましょう。このLinear Hasingの管理用のテーブルを走査する計算コストは可能なら避けるべきです。 mdbmをはじめ、多くのKVSでは最終的なデータのサイズの予想がつくのであれば、あらかじめ大きめのサイズでデータベースファイルを作成する方が好ましいでしょう。 この辺の話に興味がありましたら、コードの「hashval_to_pagenum()」
Intro to IPC | Interprocess Communication
Interprocess communication is defined as follows on Wikipedia: In computing, inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. More or less it is exactly what you would expect, the transfer of data between processes. This may sound straight forward
Off Heap concurrent counter
Concurrent counter are part of almost every system, it is used to collect data, thread synchronization etc. Java has good support of heap based counter. There could be use case when you need counter that can be shared between processor. How to build inter process countersDatabaseThis is first option that comes to mind, database sequence is counter that can be used by multiple process. All concurre
HDFSが高速に？mmapによるzero-copyでの読み込み
通常、アプリケーションはread()などのシステムコール経由でファイルを読み出します。 このHDFS-4953はmmap()システムコールを使用することで、読み取り時にかかるオーバーヘッドを減らそうというもののようです。 参考までに、通常アプリケーションがファイルを読み出す場合、以下のようなフローでカーネルからの読み込み処理が行われます。 アプリからの読み込み要求 v fread()など (stdlib) v read()システムコール(glibc) v （以下カーネル空間） v sys_read() v vfs_read() v …. 参考資料：ページキャッシュのメモ P.12 アプリケーションからの読み出し要求によりシステムコールが呼ばれるのは上記の通りですが、問題となるのは、 read()が頻繁に呼びだされる場合、コンテキストスイッチが多く発生してコストがかかる※コストの計測には s
メモリ管理
メモリマップドファイル オペレーティングシステム http://funini.com/kei/mmap/ 今日の流れ (12/10) デゖスクの話の残り デゖスクを高速に使う工夫 メモリとデゖスクの簡単なまとめ メモリマップト・フゔル (mmap) http://funini.com/kei/mmap/ デゖスク (ハードデゖスク, DVDなど) 電源を切っても消えない 物理的にはシリンダ・ブロックに分かれている OSによって抽象化され，フゔル単位でデータ を管理できる ゕクセスはメモリに比べて遅い →高速化する工夫 ディスクについて (前回の続き) http://funini.com/kei/mmap/ 連続した領域への割り当て 一度に読み出すのに都合の良いブロック (例: 同じシリンダ(円周)内の全ブロック)に フゔルの連続した領域を割り当てる cf. い
sortdb - static key value database
As dataset sizes grow, you need to buy larger/faster database machines, or shard data across multiple machines. sortdb is a database server we have written to help fill a specific need for performant access to static data. One observation about many datasets is that there is often a small dataset that is heavily updated, and a larger older related dataset that does not change. It is this second ca
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
SQLite Now Faster With Memory Mapped I/O - Phoronix
SQLite Now Faster With Memory Mapped I/O Written by Michael Larabel in Free Software on 21 May 2013 at 04:31 PM EDT. 5 Comments SQLite 3.7.17 was released yesterday. What makes this new release of the popular lightweight SQL database software noteworthy is that it introduces support for memory-mapped I/O. Rather than using read/write system calls for dealing with database disk files, SQLite 3.7.17
Day-4 : Too Big to Fail: Top Tips for Massive, Mission-Critical Enteprise Applications - 谷本 心 in せろ部屋
大規模ミッションクリティカル系システムのためのTips。 たった1分遅れただけで、満席になってて座れないぐらいの人気セッションでした。 内容的にも、知らなかったTipsが多い、得るものの多いセッションでした。 このセッションで対象にするシステムは、メモリが16〜100GBぐらい、 スレッドが10〜100ぐらい同時に動くような規模のもの。 1. Heapを抑えるために、Composed OOPS (COOPS) を使いなさい。 方法 : -XX:+UseCompressedOOPS 効果 : ヒープに長く残っている情報を圧縮する。実際2.76GB → 2.27GBになった。 2. 1スレッドで（1リクエストで）たくさんのオブジェクトを生成する場合は、NUMAを使いなさい 方法 : -XX:+UserNUMA 効果 : GCの効率が改善する 3. 共有メモリを良いパフォーマンスで読み出したいな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
StefanKarpinski/bam · GitHub - Bam: fast, simple TSV key-value server
ArrayList Using Memory Mapped File
Memory performance comparison in java - Senior Java Developer
http://www.tbray.org/ongoing/When/200x/2003/03/22/Binary
GitHub - gstrauss/mcdb: mcdb - fast, reliable, simple code to create and read constant databases
The Design of A Big, Fast, and Persistent Queue - Abstraction Builder
Map<D,B>
GitHub - xerial/larray: Large off-heap arrays and mmap files for Scala and Java
