1. 工作简介
这周周一和导师通了个电话,和导师互相间认识了一下,然后和导师沟通交流讨论了一下我的项目情况,导师给我提出了2个建议
- memcached启动的时候一定得多开几个worker thread,默认是4,但是最好还是多开点,另外,测试程序也得是多线程连接的,要不单线程连接memcached的话其实都是顺序串行执行的,发现不了关于并行执行时的瓶颈的。
- 关于YCSB的测试端的问题,以前我的是一行数据是10列,这样存取的压力会比较大,导师告诉我这样会造成传输的压力过大,找不到系统真正的瓶颈所作,所以建议将列弄小,尽量测试小数据的读写和测试,这样并行的瓶颈比较容易发现。
带着这2个建议,我开始着手这一周的工作
2. 本周工作
2.1 性能分析
首先按照老师说的修改测试的workload,这个是我目前的一个测试的workload的配置文件
recordcount=1000000
operationcount=20000000
workload=com.yahoo.ycsb.workloads.CoreWorkload
readallfields=false
readproportion=0.3
updateproportion=0.3
scanproportion=0
insertproportion=0.4
requestdistribution=zipfian
fieldcount=1
fieldlength=50
然后这个workload跑了1000秒有下面的一个结果。
然后具体的看一下
我们发现pthrea_mutex_trylock这个的CPU的时间比较长啊,这个具体打开看看
然后看看从上到下的caller tree的情况,这个要和上面那个有用的一起看
然后我们再次修改一下workload,这次主要修改一下读写的比例我们再来看看结果,首先是修改的workload
recordcount=1000000
operationcount=10000000
workload=com.yahoo.ycsb.workloads.CoreWorkload
readallfields=false
readproportion=0.7
updateproportion=0.2
scanproportion=0
insertproportion=0.1
requestdistribution=zipfian
fieldcount=1
fieldlength=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找了找解决的办法,有这么几个办法
- 无锁的原子操作
- 有个叫software transcation memory的实现
3. 接下来的工作计划
接下来的工作有了目的就比较清楚了,下面就是一个初步的计划
- 研究memcached的代码,重点实在锁的结构上,主要还是cache_lock的研究
- 修改原有的代码,支持无锁的操作,这个可能有点不是一两周能简单搞定,先看看文献和一些说明的文档
- 找到了2,3篇关于无锁的memcached的实现的论文,不过没有具体的实现,研究研究思路,看看能有什么借鉴的
终于有点眉目了,下面继续好好搞搞,继续加油吧~