您现在的位置：首页
--> 源码分析
kmemcache是memcache的linux内核移植版, 这两天断断续续的看了其网络方面的实现.
简单来说, kmemcache不落窠臼, 摈弃了epoll通知机制. 它借助skb的回调函数, 实现packet级别的调度. 在网路模型上, kmemcache分为一个dispatcher和多个workers(均为workqueue线程). dispatcher服务于TCP和unix domain sockets, 它将新建的连接丢给某个worker. 除此之外, workers还处理UDP请求.
最近（2013年6月） Linux 内核爆出了一个严重的安全漏洞，非root用户可以通过该漏洞的 exploit 获取root权限。这并不罕见，值得一提的是这个补丁看起来如此平常以至于我们绝大多数人都不会以为这是安全问题。
考虑这样一种常见的情况：用户进程调用malloc()动态分配了一块内存空间，再对这块内存进行访问。这些用户空间发生的事会引发内核空间的那些反映？本文将简单为您解答。
fatcache是twitter开源的缓存服务, 可以认为是SSD版的memcache(索引还是在内存). 本文简单分析下, 做个备忘。代码虽然很短, 还是能学到一点知识, 尤其是随机写转为顺序写的思路. 最牛逼的是对删除请求, 只删索引不改数据的机制真是简单高效.
有了高速的内存分配器，gen_tcp的接收缓冲区的管理的代价就不算太大。如文中所诉gen_tcp设计接收缓冲区的目的是为了能够在大量网络链接的情况下，尽可能的节约内存，典型的用时间换空间的设计。小结： 源码是最好的答案，文档不是。
这个函数是wordpress里的一个函数，作用是获取相邻的POST文章。 函数并不大，有效代码大概只有70行左右，但是里面包含的知识不少，所以专门用一篇文章来解释一下。
irqbalance用于优化中断分配，它会自动收集系统数据以分析使用模式，并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。处于Performance mode 时，irqbalance 会将中断尽可能均匀地分发给各个 CPU core，以充分利用 CPU 多核，提升性能。 处于Power-save mode 时，irqbalance 会将中断集中分配给第一个 CPU，以保证其它空闲 CPU 的睡眠时间，降低能耗。 在RHEL发行版里这个守护程序默认是开机启用的，那如何确认它的状态呢？
为了规避内存碎片问题，Memcached采用了名为SlabAllocator的内存分配机制。内存以Page为单位来分配，每个Page分给一个特定长度的Slab来使用，每个Slab包含若干个特定长度的Chunk。实际保存数据时，会根据数据的大小选择一个最贴切的Slab，并把数据保存在对应的Chunk中。如果某个Slab没有剩余的Chunk了，系统便会给这个Slab分配一个新的Page以供使用，如果没有Page可用，系统就会触发LRU机制，通过删除冷数据来为新数据腾出空间，这里有一点需要注意的是：LRU不是全局的，而是针对Slab而言的。
最近给服务增加了一个cache_put_latency指标，加了之后，吓了一跳。发现往memcached put一个10KB左右的数据，latency居然有7ms左右，难于理解，于是花了一些精力找原因。我分别写了一个shell和C++的测试程序。
简单介绍下 在较早版本的 Lucene 中对一定范围内的查询RanageQuery 。该Query 继承于 MulitTermQuery，在重写（rewrite ）Query 树的时候将会遵从一个原则： 根据起始区间值获取term, 然后遍历，根据满足条件的term 的数目来决定重写Query 的类型。
BLCR(Berkeley Lab Checkpoint/Restart)简单地讲是一个对进程做Checkpoint/Restart的套件，实现了用户态的libcr库和kernel module来完成相关的Checkpoint/Restart工作，最近在阅读BLCR的代码，也简单地hack过代码，写这篇文章来记录下我对于BLCR的理解，先暂时只写Checkpoint相关的BLCR架构流程。
OpenerDirector是怎么把这些handler分类的？
上篇文章说到，在build_opener中只是调用了OpenerDirector的add_handler方法，并不是直接操作的属性来完成handler的添加的。那么来看看OpenerDirector.add_handler具体做了些什么工作。
这个函数的作用其实很简单，就是传进来的Handler进行分类。既然是分类那就要有分类的依据了，那么分类的依据是什么呢？
在程序第一次执行urlopen操作的时候，其实就是构建了一个全局的_opener对象，然后用这个_opener对象来处理url以及data。这样做的好处就是如果你在程序中要多次调用urlopen，就不会频繁构建opener对象了。当然这个opener也不是一次加载就再也不可变了，urllib2提供了install_opener这个方法，你可以在客户端调用build_opener然后用前面的那个install_opener来加载。
开始有读urllib2源码的这个想法是在某个午饭后的时光，刷了会微博发现：与其无聊的刷微博，不如找点源码读，想了想，就找到urllib2。
原因是urllib2这个模块是从一开始写python到很久以后都会用到的东西，我想大多数人都会有这样的感觉，因为它很好用，而且python也会经常用来写爬虫。使用频率这么高的东西，自然要把它彻底掌握才好。
这段时间有空就会看看urllib2的源码，里面可以学习的东西还真不少，也有些值的借鉴的思想，比如关于一系列handler处理的操作。另外里面还用了个设计模式，应该是command模式。这些东西以后慢慢分析。
昨天阅读了Yii框架中log部分的源代码，框架提供了灵活、强大的log功能，如果不是非常特殊的需求，框架中自带的类就已经能够满足一般的应用的需求了。实现log功能的源代码被存放在 framework/logging 目录下，这个目录下的代码都包含在包system.logging中。本文简要介绍一下我昨天阅读代码的所得。
本文结合HBase 0.94.1版本源码，对HBase的Block Cache实现机制进行分析，总结学习其Cache设计的核心思想。 1. 概述 HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。 写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。
如果你好几个月不关注某个开源项目的源代码了，当再次需要研究代码时，
分析文档是非常有用的，对照代码和分析文档可以让你快速恢复到当初对代码的理解水平，
如果没有分析文档，通常又会浪费大量时间再重做一次。
以下两个例子就是我在分析HBase的HMaster和HRegionServer的启动流程时写的原始分析文档片断，
会有一些TODO或错误或过时的地方，因为这是个在研究过程中不断完善的文档，
并不是最终的，也没有终极文档，因为开源项目的代码一直在变动。
近3天十大热文
-
[111] 招聘技巧一二 -
[15] Linux常用系统信息查看命令
-
[13] 最近总结的一些技巧(vim,python,s
-
[12] 在FreeNAS/BSD搭建基于Nginx+
-
[12] Redis和Memcached的区别
-
[11] 个人开公司的流程，以后用得着
-
[11] 关于Linux的文件系统cache
-
[10] 每个程序员都应该知道的8个Linux命令
-
[10] 我对技术方向的一些反思
-
[10] ps - 按进程消耗内存多少排序
赞助商广告
