开源夏令营Memcached哈希性能优化（二）

1. 工作简介

这周周一和导师通了个电话，和导师互相间认识了一下，然后和导师沟通交流讨论了一下我的项目情况，导师给我提出了2个建议

1. memcached启动的时候一定得多开几个worker thread，默认是4，但是最好还是多开点，另外，测试程序也得是多线程连接的，要不单线程连接memcached的话其实都是顺序串行执行的，发现不了关于并行执行时的瓶颈的。
2. 关于YCSB的测试端的问题，以前我的是一行数据是10列，这样存取的压力会比较大，导师告诉我这样会造成传输的压力过大，找不到系统真正的瓶颈所作，所以建议将列弄小，尽量测试小数据的读写和测试，这样并行的瓶颈比较容易发现。

带着这2个建议，我开始着手这一周的工作

2. 本周工作

2.1 性能分析

首先按照老师说的修改测试的workload，这个是我目前的一个测试的workload的配置文件

recordcount=1000000operationcount=20000000workload=com.yahoo.ycsb.workloads.CoreWorkloadreadallfields=falsereadproportion=0.3updateproportion=0.3scanproportion=0insertproportion=0.4requestdistribution=zipfianfieldcount=1fieldlength=50

其中的recordcount是load workload需要的，而operationcount则是实际运行的时候的操作数，readproportion，updateproportion，insertproportion分别是读，更新和插入的比例，fieldcount则是说有多少列，而fieldlength则是说每列的长度是多少，

然后这个workload跑了1000秒有下面的一个结果。

然后具体的看一下

我们发现pthrea_mutex_trylock这个的CPU的时间比较长啊，这个具体打开看看

然后看看从上到下的caller tree的情况，这个要和上面那个有用的一起看

然后我们再次修改一下workload，这次主要修改一下读写的比例我们再来看看结果，首先是修改的workload

recordcount=1000000operationcount=10000000workload=com.yahoo.ycsb.workloads.CoreWorkloadreadallfields=falsereadproportion=0.7updateproportion=0.2scanproportion=0insertproportion=0.1requestdistribution=zipfianfieldcount=1fieldlength=50

然后是总体的结果

具体的函数排名

最后看看调用关系，是什么操作占的比重比较大

最后看看调用的图

这两个可看出pthread_mutex_trylock这里明显是系统的一个瓶颈，明显是有优化的余地的

2.2 解决办法

pthread_mutex_trylock这个在没然后发现我们的主要是在do_item_alloc的时候调用了mutex_lock这个函数，我们继续找找，发现了这个mutex_lock的实现

static inline int mutex_lock(pthread_mutex_t *mutex){    while (pthread_mutex_trylock(mutex));    return 0;}

函数是pthread_mutex_lock函数的非阻塞版本。如果mutex参数所指定的互斥锁已经被锁定的话，调用pthread_mutex_trylock函数不会阻塞当前线程，而是立即返回一个值来描述互斥锁的状况。

这里这个锁的实现有点类似自旋锁的实现，如果要优化的话，可以采用的办法就是把这里锁的结构去掉，尽量变成无锁的结构，这一周主要在google找了找解决的办法，有这么几个办法

1. 无锁的原子操作
2. 有个叫software transcation memory的实现

3. 接下来的工作计划

接下来的工作有了目的就比较清楚了，下面就是一个初步的计划

1. 研究memcached的代码，重点实在锁的结构上，主要还是cache_lock的研究
2. 修改原有的代码，支持无锁的操作，这个可能有点不是一两周能简单搞定，先看看文献和一些说明的文档
3. 找到了2，3篇关于无锁的memcached的实现的论文，不过没有具体的实现，研究研究思路，看看能有什么借鉴的

终于有点眉目了，下面继续好好搞搞，继续加油吧~