`
haoningabc
  • 浏览: 1465774 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

转tokyotyrant张宴等性能相关

 
阅读更多
http://tech.it168.com/a2010/0419/875/000000875687_2.shtml

http://www.4pang.com/2010/09/06/%E5%BD%93%E5%BF%83ttservertokyo-tyrant%E5%9C%A8%E7%B3%BB%E7%BB%9F%E5%B4%A9%E6%BA%83%E6%88%96%E6%96%AD%E7%94%B5%E7%9A%84%E6%97%B6%E5%80%99%E4%B8%A2%E5%A4%B1%E6%95%B0%E6%8D%AE.html

http://korrespondence.blogspot.com/2009/09/tokyo-tyrant-tuning-parameters.html
Tokyo Tyrant tuning parameters
We've been working with Tokyo Tyrant for some large scale key-value lookups and the performance has been very nice, but has degraded over time. I've been poking around the various options to try to improve the performance and although there is documentation of various options, the pages are hard to read and figure out what's what. So I thought I'd collect them here for reference. I'll describe the results of tuning and tweaking in a future post.

The most recent authoritative references are here:

http://1978th.net/tokyocabinet/spex-en.html
http://1978th.net/tokyotyrant/spex.html#installation

Tokyo Tyrant (actually Tokyo Cabinet – the storage engine) supports various types of storage – B+ Tree indexing, hash index, etc. This is configured by setting the filename or file extension to a particular value:
If the name is "*", the database will be an in-memory hash database.
If it is "+", the database will be an in-memory tree database.
If its suffix is ".tch", the database will be a hash database.
If its suffix is ".tcb", the database will be a B+ tree database.
If its suffix is ".tcf", the database will be a fixed-length database.
If its suffix is ".tct", the database will be a table database.
Each has its own set of options and while different flavors of storage may accept the same option name (like bnum), the optimal value likely should be different across storage types.
Tuning parameters can trail the filename, separated by "#". Each parameter is composed of the name and the value, separated by "=". For example, "casket.tch#bnum=1000000#opts=ld" means that the name of the database file is "casket.tch", and the bucket array size is 1000000, and the options are large and deflate.

For disk-based storage, several tuning parameters specify the on-disk layout while others specify memory and caching settings. Changing the on-disk layout requires scanning and re-writing the database data file which requires exclusive access to the file – which means taking the database offline. This scanning and re-writing process is done via tools provided with the distribution (ex: tchmgr and tcbmgr). Changing the memory and caching settings only requires a restart of Tokyo Tyrant.

We've been working only with on-disk storage via the hash and B+ Tree database engines. For a hash database the tuning parameters for the on-disk layout is limited to the size of the bucket array and the size of an element in the bucket array (choosing 'large' gets you 64-bit addressing and addressable data greater than 2GB). When a hash database file is first created, space is allocated on disk for the full bucket array. For example a database with 100M bucket size and 'large' option would start out at around 800MB. This region of the data file is accessed via memory mapped IO. There is an additional 'extra mapped memory' setting which default to 64MB – I'm not sure what this is used for, but for performance more memory is always better.

For a B+ Tree database, there are additional tuning parameters for the structure of the B+ Tree – how many members (links to child nodes) in an interior non-leaf node and how many members in a leaf node. Records are not stored in the B-Tree leaf nodes, but within 'pages'. The leaf nodes point to these pages and each page holds multiple records and is accessed via an internal hash database (and since this is a B+ Tree the records within a page are of course stored in sorted order). There is also a parameter for the bucket size of this internal hash database. One subtle detail is that the bucket size for a B+Tree database is the number of pages, not the number of elements (records) being stored – so this would likely be a smaller number than a hash database for the same number of records.

I've not yet figured out how the dfunit tuning parameter works or what impact that has on a running server, but it looks interesting.


In memory hash 
bnum
the number of buckets
capnum
the capacity number of records
capsiz
the capacity size of using memory. Note - records spilled the capacity are removed by the storing order.



In memory tree
capnum
the capacity number of records
capsiz
the capacity size of using memory. Note - records spilled the capacity are removed by the storing order.


Hash
opts
"l" of large option (the size of the database can be larger than 2GB by using 64-bit bucket array.), "d" of Deflate option (each record is compressed with Deflate encoding), "b" of BZIP2 option, "t" of TCBS option
bnum
number of elements of the bucket array. If it is not more than 0, the default value is specified. The default value is 131071 (128K). Suggested size of the bucket array is about from 0.5 to 4 times of the number of all records to be stored.
rcnum
maximum number of records to be cached. If it is not more than 0, the record cache is disabled. It is disabled by default.
xmsiz
size of the extra mapped memory. If it is not more than 0, the extra mapped memory is disabled. The default size is 67108864 (64MB).
apow
size of record alignment by power of 2. If it is negative, the default value is specified. The default value is 4 standing for 2^4=16.
fpow
maximum number of elements of the free block pool by power of 2. If it is negative, the default value is specified. The default value is 10 standing for 2^10=1024.
dfunit
unit step number of auto defragmentation. If it is not more than 0, the auto defragmentation is disabled. It is disabled by default.
mode
"w" of writer, "r" of reader,"c" of creating,"t" of truncating ,"e" of no locking,"f" of non-blocking lock


B-tree
opts
"l" of large option,"d" of Deflate option,"b" of BZIP2 option,"t" of TCBS option
bnum
number of elements of the bucket array. If it is not more than 0, the default value is specified. The default value is 32749 (32K). Suggested size of the bucket array is about from 1 to 4 times of the number of all pages to be stored.
nmemb
number of members in each non-leaf page. If it is not more than 0, the default value is specified. The default value is 256.
ncnum
maximum number of non-leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 512.
lmemb
number of members in each leaf page. If it is not more than 0, the default value is specified. The default value is 128.
lcnum
maximum number of leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 1024.
apow
size of record alignment by power of 2. If it is negative, the default value is specified. The default value is 8 standing for 2^8=256.
fpow
maximum number of elements of the free block pool by power of 2. If it is negative, the default value is specified. The default value is 10 standing for 2^10=1024.
xmsiz
size of the extra mapped memory. If it is not more than 0, the extra mapped memory is disabled. It is disabled by default.
dfunit
unit step number of auto defragmentation. If it is not more than 0, the auto defragmentation is disabled. It is disabled by default.
mode
"w" of writer, "r" of reader,"c" of creating,"t" of truncating ,"e" of no locking,"f" of non-blocking lock


Fixed-length
width
width of the value of each record. If it is not more than 0, the default value is specified. The default value is 255.
limsiz
limit size of the database file. If it is not more than 0, the default value is specified. The default value is 268435456 (256MB).
mode
"w" of writer, "r" of reader,"c" of creating,"t" of truncating ,"e" of no locking,"f" of non-blocking lock



Table
opts
"l" of large option,"d" of Deflate option,"b" of BZIP2 option,"t" of TCBS option
idx
specifies the column name of an index and its type separated by ":"
bnum
number of elements of the bucket array. If it is not more than 0, the default value is specified. The default value is 131071. Suggested size of the bucket array is about from 0.5 to 4 times of the number of all records to be stored.
rcnum
maximum number of records to be cached. If it is not more than 0, the record cache is disabled. It is disabled by default.
lcnum
maximum number of leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 4096.
ncnum
maximum number of non-leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 512.
xmsiz
size of the extra mapped memory. If it is not more than 0, the extra mapped memory is disabled. The default size is 67108864.
apow
size of record alignment by power of 2. If it is negative, the default value is specified. The default value is 4 standing for 2^4=16.
fpow
maximum number of elements of the free block pool by power of 2. If it is negative, the default value is specified. The default value is 10 standing for 2^10=1024.
dfunit
unit step number of auto defragmentation. If it is not more than 0, the auto defragmentation is disabled. It is disabled by default.
mode
"w" of writer, "r" of reader,"c" of creating,"t" of truncating ,"e" of no locking,"f" of non-blocking lock
分享到:
评论

相关推荐

    tokyotyrant-1.1.40.tar.gz

    5. **性能优化**:TokyoTyrant的性能取决于硬件配置,如磁盘速度、内存大小等。可以通过调整服务器的配置参数,例如缓存大小、索引块大小等,来优化性能。此外,合理设计数据结构和访问模式也能显著提升效率。 6. *...

    tokyotyrant/tokyocabinet/gpac

    TokyoTyrant 的设计目标是高性能和低延迟,适用于缓存服务、日志记录以及任何需要快速读写操作的应用场景。它支持多种数据类型,如字符串、二进制数据和记录列表,并且可以通过多种编程语言的客户端进行操作,例如 ...

    tokyoCabint及tokyoTyrant简介

    标题 "tokyoCabinet及tokyoTyrant简介" 指向了两个与数据库管理相关的开源工具,Tokyo Cabinet和Tokyo Tyrant。这两个工具由日本开发者开发,主要用于小型到中型的数据存储,尤其适合那些对数据读写速度有较高要求的...

    tokyotyrant

    媲美memcached的缓存服务器软件包,tokyocabinet-1.4.45.tar.gz+tokyotyrant-1.1.40.tar.gz

    发布一个基于TokyoTyrant的C#客户端开源项目

    这个C#客户端的开源发布,为.NET开发者提供了与TokyoTyrant交互的工具,使得他们可以利用TokyoTyrant的强大功能,比如高速的键值存储、灵活的数据结构和优秀的性能,来构建高性能的分布式应用。同时,通过社区的参与...

    Tokyocabinet-Tokyotyrant文档大合集

    Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。 当做为Hash表数据库使用时,...

    tokyocabinet安装配置总结(Ubuntu)

    Tokyocabinet提供多种数据结构,包括哈希表、B+树和直方图,支持多种数据类型,并且具有高度的可移植性和良好的性能。在Ubuntu操作系统上安装和配置Tokyocabinet,可以分为以下几个步骤: 1. **系统准备**: 在...

    Java-concurrentMap-内存模型深入分析-HotCode

    `TokyoTyrant与Redis的一些简单比较.docx`文件可能比较了两种不同的NoSQL数据库,它们在存储和检索大量数据时的性能和特性。在分布式系统中,`concurrentMap`的实现可能会借鉴类似的思想,例如使用分布式缓存来提升...

    ttserver

    在 "tokyotyrant-1.1.24" 这个压缩包中,我们预期会找到 Tokyo Tyrant 的源代码、文档、示例程序和测试用例。Tokyo Tyrant 提供了丰富的API,使得开发人员可以轻松地在各种编程语言(如C、Python、Ruby等)中与之...

    TTserver1.1.4

    从给出的信息来看,它可能是Tokyo Tyrant的一个特定版本,因为压缩包中的文件名为"tokyotyrant-1.1.41"。Tokyo Tyrant是一个轻量级、高性能的键值存储系统,常用于数据缓存和快速查找应用。 Tokyo Tyrant主要知识点...

    memcached全面剖析.pdf

    - TokyoTyrant是一款由mixi工程师开发的兼容memcached协议的键值存储系统,具有更高的性能和稳定性。 - TokyoTyrant可以在某些场景下作为memcached的替代品。 综上所述,memcached作为一种强大的缓存解决方案,在...

    memcached的细节文档

    - **兼容应用程序**:如TokyoTyrant等软件与memcached的兼容使用。 ### 总结 memcached作为一个内存缓存系统,具有简单、高效的特点,特别适合Web应用中缓存数据,减少数据库的访问次数。其分布式特性使得系统更加...

    MemCached 全面剖析 memcached.pdf(中文)

    - **TokyoTyrant 案例**:TokyoTyrant 是一个兼容 MemCached 协议的高性能键值存储系统。 以上内容覆盖了 MemCached 的基本概念、安装使用、内存管理、删除机制、分布式算法以及实际应用场景等方面的知识点,为深入...

    tokyotytrant

    在深入研究Tokyo Tyrant的内部实现时,可以关注其数据结构、并发控制机制、持久化策略等方面,这些都对理解Tokyo Tyrant的高性能至关重要。 总而言之,Tokyo Tyrant是一款面向高速数据处理的NoSQL数据库,其简单的...

    Memcached分布式缓存

    - **TokyoTyrant案例**:TokyoTyrant是一个开源的高性能key-value存储系统,它可以与memcached兼容,提供更强大的功能。 #### 总结 Memcached作为一款高性能的分布式缓存系统,在现代互联网应用中扮演着至关重要的...

Global site tag (gtag.js) - Google Analytics