cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "FAQ_JP" by MakiWatanabe
Date Wed, 30 Mar 2011 02:20:03 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "FAQ_JP" page has been changed by MakiWatanabe.
The comment on this change is: Translate batch_mutate, mmap.
http://wiki.apache.org/cassandra/FAQ_JP?action=diff&rev1=76&rev2=77

--------------------------------------------------

  <<Anchor(batch_mutate_atomic)>>
  
  == batch_mutateはアトミックな操作ですか? ==
- As a special case, mutations against a single key are atomic but not isolated. Reads which
occur during such a mutation may see part of the write before they see the whole thing. More
generally, batch_mutate operations are not atomic. [[API#batch_mutate|batch_mutate]] allows
grouping operations on many keys into a single call in order to save on the cost of network
round-trips. If `batch_mutate` fails in the middle of its list of mutations, no rollback occurs
and the mutations that have already been applied stay applied. The client should typically
retry the `batch_mutate` operation.
+ 特殊な例として、単一のキーに対するbatch_mutationを考えると、それぞれのmutationはアトミックですが、アイソレーションはされていません。このようなmutationの最中にreadを行うと、部分的に更新された状態が見える可能性があります。
+ 一般的に言うと、batch_mutateはアトミックではありません。ネットワークのラウンドトリップコストを削減するため、
+ [[API#batch_mutate|batch_mutate]]
+ は複数のキーに対する操作を単一の呼び出しにまとめることを許しています。`batch_mutate`がmutationの途中で失敗した場合、既に適用されたmutationはそのまま残ります。ロールバックはされません。
+ このような場合、一般的にはクライアントアプリケーションは`batch_mutate`をリトライする必要があります。
+ 
  
  <<Anchor(hadoop_support)>>
  
@@ -446, +451 @@

  == Compactionを実行してもディスク使用量が減らないのはなぜでしょうか?
==
  SSTables that are obsoleted by a compaction are deleted asynchronously when the JVM performs
a GC. You can force a GC from jconsole if necessary, but Cassandra will force one itself if
it detects that it is low on space. A compaction marker is also added to obsolete sstables
so they can be deleted on startup if the server does not perform a GC before being restarted.
Read more on this subject [[http://wiki.apache.org/cassandra/MemtableSSTable|here]].
  
+ 
  <<Anchor(mmap)>>
  
  == topコマンドの出力で,CassandraがJava heapの最大値よりも大きなメモリを使用しているのはなぜでしょうか?
==
- Cassandra uses mmap to do zero-copy reads. That is, we use the operating system's virtual
memory system to map the sstable data files into the Cassandra process' address space. This
will "use" virtual memory; i.e. address space, and will be reported by tools like top accordingly,
but on 64 bit systems virtual address space is effectively unlimited so you should not worry
about that.
- 
- What matters from the perspective of "memory use" in the sense as it is normally meant,
is the amount of data allocated on brk() or mmap'd /dev/zero, which represent real memory
used.  The key issue is that for a mmap'd file, there is never a need to retain the data resident
in physical memory. Thus, whatever you do keep resident in physical memory is essentially
just there as a cache, in the same way as normal I/O will cause the kernel page cache to retain
data that you read/write.
- 
- The difference between normal I/O and mmap() is that in the mmap() case the memory is actually
mapped to the process, thus affecting the virtual size as reported by top. The main argument
for using mmap() instead of standard I/O is the fact that reading entails just touching memory
- in the case of the memory being resident, you just read it - you don't even take a page
fault (so no overhead in entering the kernel and doing a semi-context switch). This is covered
in more detail [[http://www.varnish-cache.org/trac/wiki/ArchitectNotes|here]].
+ Cassandraはzero-copy readのためにmmapを使用しています。即ち、sstableデータファイルをCassandraプロセスのアドレス空間にマップするためにOSの仮想メモリシステムを使用しているのです。これが仮想メモリが多量に使用されているように見える理由です。実際に使用されているのは仮想アドレス空間ですが、topなどのツールでは仮想メモリの消費としてレポートされます。64ビット環境ではアドレス空間はほぼ無限大ですので、あまり気にする必要はありません。通常の意味でのメモリ使用量の観点から問題となるのはbrk()でアロケートされたデータの量やmmapされた/dev/zeroです。これは使用された実メモリ量を示しています。
+ mmapされたファイルについて注意すべき点は、それらを物理メモリに保持する必要がないということです。つまり物理メモリに保持されたmmapファイルは基本的にはキャッシュとみなせます。これはちょうど通常のI/Oによってread/writeしたデータがカーネルのページキャッシュに保持されるのと同じです。
+ 通常のI/Oとmmap()の違いは、mmap()がメモリをプロセスにマップするため、topでレポートされる仮想メモリサイズに影響することにあります。
+ 通常のI/Oに替えてmmap()を使う主な利点は、メモリにアクセスするだけでreadが完了する点にあります。そのメモリ領域が実際にロードされている(residentである)場合は、正にそれを読むだけで、ページフォルトも不要です。(カーネル空間に入ったり、コンテキストスイッチするオーバーヘッドも必要ありません)
+ 詳細については次のリンクを参照してください。[[http://www.varnish-cache.org/trac/wiki/ArchitectNotes]]
  
  <<Anchor(jna)>>
  

Mime
View raw message