输入法之核心词典构建

下面是《memcached全面剖析》的第二部分。

发表日:2008/7/9

作者:前坂徹(Toru Maesaka)

原文链接:http://gihyo.jp/dev/feature/01/memcached/0002

我是mixi株式会社研究开发组的前坂徹。 上次的文章介绍了memcached是分布式的高速缓存服务器。
本次将介绍memcached的内部构造的实现方式,以及内存的管理方式。 另外,memcached的内部构造导致的弱点也将加以说明。

Slab Allocation机制:整理内存以便重复使用

最近的memcached默认情况下采用了名为Slab Allocator的机制分配、管理内存。 在该机制出现以前,内存的分配是通过对所有记录简单地进行malloc和free来进行的。 但是,这种方式会导致内存碎片,加重操作系统内存管理器的负担,最坏的情况下, 会导致操作系统比memcached进程本身还慢。Slab Allocator就是为解决该问题而诞生的。

下面来看看Slab Allocator的原理。下面是memcached文档中的slab allocator的目标:

the primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixed-size memory chunks coming from a few predetermined size classes.

也就是说,Slab Allocator的基本原理是按照预先规定的大小,将分配的内存分割成特定长度的块, 以完全解决内存碎片问题。

Slab Allocation的原理相当简单。 将分配的内存分割成各种尺寸的块(chunk), 并把尺寸相同的块分成组(chunk的集合)(图1)。

图1 Slab Allocation的构造图

而且,slab allocator还有重复使用已分配的内存的目的。 也就是说,分配到的内存不会释放,而是重复利用。

Slab Allocation的主要术语

Page

分配给Slab的内存空间,默认是1MB。分配给Slab之后根据slab的大小切分成chunk。

Chunk

用于缓存记录的内存空间。

Slab Class

特定大小的chunk的组。

在Slab中缓存记录的原理

下面说明memcached如何针对客户端发送的数据选择slab并缓存到chunk中。

memcached根据收到的数据的大小,选择最适合数据大小的slab(图2)。 memcached中保存着slab内空闲chunk的列表,根据该列表选择chunk, 然后将数据缓存于其中。

图2 选择存储记录的组的方法

实际上,Slab Allocator也是有利也有弊。下面介绍一下它的缺点。

Slab Allocator的缺点

Slab Allocator解决了当初的内存碎片问题,但新的机制也给memcached带来了新的问题。

这个问题就是,由于分配的是特定长度的内存,因此无法有效利用分配的内存。 例如,将100字节的数据缓存到128字节的chunk中,剩余的28字节就浪费了(图3)。

图3 chunk空间的使用

对于该问题目前还没有完美的解决方案,但在文档中记载了比较有效的解决方案。

The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that‘s at all possible) common sizes of objects that the clients of this particular installation of memcached are likely to store.

就是说,如果预先知道客户端发送的数据的公用大小,或者仅缓存大小相同的数据的情况下, 只要使用适合数据大小的组的列表,就可以减少浪费。

但是很遗憾,现在还不能进行任何调优,只能期待以后的版本了。 但是,我们可以调节slab class的大小的差别。 接下来说明growth factor选项。

使用Growth Factor进行调优

memcached在启动时指定 Growth Factor因子(通过-f选项), 就可以在某种程度上控制slab之间的差异。默认值为1.25。 但是,在该选项出现之前,这个因子曾经固定为2,称为“powers of 2”策略。

让我们用以前的设置,以verbose模式启动memcached试试看:

$ memcached -f 2 -vv

下面是启动后的verbose输出:

slab class   1: chunk size    128 perslab  8192slab class   2: chunk size    256 perslab  4096slab class   3: chunk size    512 perslab  2048slab class   4: chunk size   1024 perslab  1024slab class   5: chunk size   2048 perslab   512slab class   6: chunk size   4096 perslab   256slab class   7: chunk size   8192 perslab   128slab class   8: chunk size  16384 perslab    64slab class   9: chunk size  32768 perslab    32slab class  10: chunk size  65536 perslab    16slab class  11: chunk size 131072 perslab     8slab class  12: chunk size 262144 perslab     4slab class  13: chunk size 524288 perslab     2

可见,从128字节的组开始,组的大小依次增大为原来的2倍。 这样设置的问题是,slab之间的差别比较大,有些情况下就相当浪费内存。 因此,为尽量减少内存浪费,两年前追加了growth factor这个选项。

来看看现在的默认设置(f=1.25)时的输出(篇幅所限,这里只写到第10组):

slab class   1: chunk size     88 perslab 11915slab class   2: chunk size    112 perslab  9362slab class   3: chunk size    144 perslab  7281slab class   4: chunk size    184 perslab  5698slab class   5: chunk size    232 perslab  4519slab class   6: chunk size    296 perslab  3542slab class   7: chunk size    376 perslab  2788slab class   8: chunk size    472 perslab  2221slab class   9: chunk size    592 perslab  1771slab class  10: chunk size    744 perslab  1409

可见,组间差距比因子为2时小得多,更适合缓存几百字节的记录。 从上面的输出结果来看,可能会觉得有些计算误差, 这些误差是为了保持字节数的对齐而故意设置的。

将memcached引入产品,或是直接使用默认值进行部署时, 最好是重新计算一下数据的预期平均长度,调整growth factor, 以获得最恰当的设置。内存是珍贵的资源,浪费就太可惜了。

接下来介绍一下如何使用memcached的stats命令查看slabs的利用率等各种各样的信息。

查看memcached的内部状态

memcached有个名为stats的命令,使用它可以获得各种各样的信息。 执行命令的方法很多,用telnet最为简单:

$ telnet 主机名 端口号

连接到memcached之后,输入stats再按回车,即可获得包括资源利用率在内的各种信息。 此外,输入"stats slabs"或"stats items"还可以获得关于缓存记录的信息。 结束程序请输入quit。

这些命令的详细信息可以参考memcached软件包内的protocol.txt文档。

$ telnet localhost 11211Trying ::1...Connected to localhost.Escape character is ‘^]‘.statsSTAT pid 481STAT uptime 16574STAT time 1213687612STAT version 1.2.5STAT pointer_size 32STAT rusage_user 0.102297STAT rusage_system 0.214317STAT curr_items 0STAT total_items 0STAT bytes 0STAT curr_connections 6STAT total_connections 8STAT connection_structures 7STAT cmd_get 0STAT cmd_set 0STAT get_hits 0STAT get_misses 0STAT evictions 0STAT bytes_read 20STAT bytes_written 465STAT limit_maxbytes 67108864STAT threads 4ENDquit

另外,如果安装了libmemcached这个面向C/C++语言的客户端库,就会安装 memstat 这个命令。 使用方法很简单,可以用更少的步骤获得与telnet相同的信息,还能一次性从多台服务器获得信息。

$ memstat --servers=server1,server2,server3,...

libmemcached可以从下面的地址获得:

查看slabs的使用状况

使用memcached的创造着Brad写的名为memcached-tool的Perl脚本,可以方便地获得slab的使用情况 (它将memcached的返回值整理成容易阅读的格式)。可以从下面的地址获得脚本:

使用方法也极其简单:

$ memcached-tool 主机名:端口 选项

查看slabs使用状况时无需指定选项,因此用下面的命令即可:

$ memcached-tool 主机名:端口

获得的信息如下所示:

 #  Item_Size   Max_age  1MB_pages Count   Full? 1     104 B  1394292 s    1215 12249628    yes 2     136 B  1456795 s      52  400919     yes 3     176 B  1339587 s      33  196567     yes 4     224 B  1360926 s     109  510221     yes 5     280 B  1570071 s      49  183452     yes 6     352 B  1592051 s      77  229197     yes 7     440 B  1517732 s      66  157183     yes 8     552 B  1460821 s      62  117697     yes 9     696 B  1521917 s     143  215308     yes10     872 B  1695035 s     205  246162     yes11     1.1 kB 1681650 s     233  221968     yes12     1.3 kB 1603363 s     241  183621     yes13     1.7 kB 1634218 s      94   57197     yes14     2.1 kB 1695038 s      75   36488     yes15     2.6 kB 1747075 s      65   25203     yes16     3.3 kB 1760661 s      78   24167     yes

各列的含义为:

含义
# slab class编号
Item_Size Chunk大小
Max_age LRU内最旧的记录的生存时间
1MB_pages 分配给Slab的页数
Count Slab内的记录数
Full? Slab内是否含有空闲chunk

从这个脚本获得的信息对于调优非常方便,强烈推荐使用。

内存存储的总结

本次简单说明了memcached的缓存机制和调优方法。 希望读者能理解memcached的内存管理原理及其优缺点。

下次将继续说明LRU和Expire等原理,以及memcached的最新发展方向—— 可扩充体系(pluggable architecher))。

原文:http://kb.cnblogs.com/page/42732/;

输入法之核心词典构建,布布扣,bubuko.com

时间: 2024-10-29 19:05:41

输入法之核心词典构建的相关文章

《面向微博的社会情绪词典构建及情绪分析方法研究》学习笔记

1. 目的: 探索一种面向微博的社会情绪词典构建方法: 2. 步骤: 1)通过手工方法建立小规模的基准情绪词典: 2)利用深度学习工具 Word2vec对社会热点事件的微博语料通过增量式学习方法来扩展基准词典,并结合 HowNet词典匹配和人工筛选生成最终的情绪词典: 3. 试验阶段: 分别利用基于情绪词典和基于SVM的情绪方法对实验标注语料进行情绪分析: 4. 结果分析: 结果对比分析表明基于词典的情绪分析方法优于基于SVM的情绪分析方法,前者的平均准确率和召回率比后者分别高13.9%和1.5

基于讯飞语音API应用开发之——离线词典构建

最近实习在做一个跟语音相关的项目,就在度娘上搜索了很多关于语音的API,顺藤摸瓜找到了科大讯飞,虽然度娘自家也有语音识别.语义理解这块,但感觉应该不是很好用,毕竟之前用过百度地图的API,有问题也找不到人帮忙解决(地图开发者群里都是潜水的)...不得不说,科大讯飞在语音这块尤其是中文识别方面做的真心不错,而且Android还支持离线识别. 讯飞官方给的文档内容很详细,在这我就不赘述了.在开发中,由于一些原因需要用到离线识别这块,就学习了一下.讯飞离线识别只支持Android系统,使用时需要安装讯

桌面输入法评测报告 之 搜狗拼音输入法vs必应拼音输入法(2)

点击跳转到相关部分: 二.差异化功能 三.辅助功能 四.细节.体验与性能 二.差异性功能 1.必应:英文小助手 英文小助手可以自动识别单词,完成单词的快速输入,对于经常输入英文的用户有很大的帮助: 2.必应:多媒体模式 我们对多媒体模式进行了测试: vg: (网址直达)和vw(网页):   功能稍显重复: 而且如果不用vg需要先用快捷键Ctrl+R显示网址直达功能,然后才能点击网址. 搜狗也有类似功能,但可以直接点击,方便快捷: vs:热词搜索 搜狗:数量更多,操作便捷,输入完了按向下箭头就会显

输入法畅想

前段时间结识了两位创业做输入法的朋友,花了一个下午和他们畅聊了下输入法,也开拓了下自己的思路,于是写此博文以记之. 目前中国PC市场的输入法基本上已经被搜狗垄断了,剩下的就是QQ,谷歌,百度等几家大公司的输入法,当然也有拼音加加这种老牌输入法的死忠粉丝,所以可以说PC市场的输入法大局已定,没有什么机会了.而眼下手机输入法还是一片蓝海,虽然搜狗.百度.QQ等手机输入法都在攻城略地,但是仍然是大有可为的一片市场. 在国内输入法之外,国外输入法是一个更大的市场,在PC时代,国外拉丁文用户可以不需要输入

构建之法 现代软件工程

这篇是计算机类的优质预售推荐>>>><构建之法 现代软件工程(第二版)> "做中学 Learning By Doing"的现代方式教授软件工程,李未院士鼎力推荐,众多软工教师一致好评,微软研发总监邹欣力作 编辑推荐 1.作者的讲授方法非常新颖,符合现代软件工程的学习和训练规律,在各大高校计算机教学中取得很好的效果和反馈. 2.作者知名度很高,具有深厚的微软工作背景,是软件工程产学结合的典范. 3.作者在博客园开设了专题博客,提供教学指导.教学素材以及

论Node在构建超媒体API中的作用

论Node在构建超媒体API中的作用 作者:chszs,转载需注明. 博客主页:http://blog.csdn.net/chszs 超媒体即Hypermedia,是一种採用非线性网状结构对块状多媒体信息(包含文本.图像.视频等)进行组织和管理的技术.超媒体的概念类似于早期的超文本.超文本的本质是在文本内容加上链接.这样就构成了超文本.超媒体也类似. 不管是超媒体还是超文本.使用的传输协议都是HTTP,这意味着超媒体能够被全部的浏览器所接受. 而描写叙述超媒体的类型我们使用MIME. MIME即

码途有道----基于系统观的核心能力构建-by-韩宏老师

原文链接:http://blog.sina.com.cn/s/blog_7d5a09f90102v341.html 有感于同学们在大学中如何学习计算机技术有些感概,将我书(老码识途)中的序言整理了一下,并补充了一些后来的想法,比如什么是系统观的新认知. 如果你想成为高级程序员或架构师,什么才是技术上的核心竞争力?仅仅是知识吗?在这个随时可求助于Google的年代,它似乎已变得非常廉价.而青春的流失并不能给我们留下技术财富,似乎只是将我们变成自嘲的"码奴".核心竞争力究竟在哪里?笔者认为

必应输入法(桌面版)软件分析和用户需求调查

目标用户:大学生 对比软件:搜狗输入法(桌面版) 一.功能篇: 1.人名输入: 尝试了很多人名,发现必应和搜狗两种输入法对于人名的词库是差不多的都很完整,但是输 入“wskt”的时候可见必应给出了正确的人名,而搜狗出现的第一个候选词不是我们需要的人 名并且没有正确人名的候选词出现.必应略胜. 2.地名输入: 地名的识别度和准确性两款输入法软件做的都是很不错的,但是搜狗输入法对于地名 的相关信息会有显示,例如,输入克利夫兰,搜狗输入法的第二个候选词是克利夫兰 最著名的球队克利夫兰骑士队,会给用户带

Gradle与Makefile构建工具的对比

随着Android Studio的普及,越来越多的Android开发者也要开始了解和学习Gradle这款强大的代码构建工具了.我们在学习和了解一项新事物的时候,最快速的方法往往是与已知的事物进行比较,对于熟悉Makefile编译机制的Linux程序员而言,认识和掌握Gradle最好的方法莫过于比较它们之间的区别了,本文不准备详细介绍Gradle的方方面面,而是希望通过与Makefile的对比帮助Gradle初学者更快速地理解Gradle的基础和原理. Makefile是一种管理和编译 Linux