一封模块短板分析的邮件

今天整理资料的时候，发现了刚毕业的时候发的一封短板分析的邮件

那个时候虽然很菜，但做事非常有激情！怀念跟着老大和兄弟们出差到北京那段日子！

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From:zhouxiaomin
Sent: 2010年9月15日 9:52
To: shiguojun; yanfei; xieyongkang; huangzhou; wuhao; wangjimei;luyiming; zhaobomin
Cc: holmes-qa; holmes-rd
Subject: 答复: 【9-9】 holmes-stat/rcv性能测试进度

 

Hi，all

 

针对国君提出的“map1-stat在极限情况下cpu idle在33%，无法再压下去，而目前处理的瓶颈在与统计线程的计算。统计线程处理逻辑存在短板，没有最有效的利用CPU，”（简称短板问题），进行了如下场景分析：

 

1）初步分析

开8个统计线程，使用文件极限压，无dump和clicklog，使用iostat和vmstat观察系统性能，极限情况下cpu idle在33%左右，io util 1%以下，wa为0

 

根据io util 和wa值，以及国君先前给出的“dump数据时间间隔对CPU和MEM没有明显影响”的结论，初步判断短板不在文件io。

从单线程短板以及多线程同步造成的短板来考虑。

 

 

2）考虑多线程同步

a. 开1个统计线程，使用文件极限压，无dump和clicklog。有2个核出于繁忙状态，cpu idle分别为0.7%（数据解析）和1.0%（统计）

b.开2个统计线程，使用文件极限压，无dump和clicklog。有3个核出于繁忙状态，cpu idle分别为2.3%（数据解析）、6.3%（统计）、6.3%（统计）

c.开4个统计线程，使用文件极限压，无dump和clicklog。有5个核出于繁忙状态，cpu idle分别为9.6%（数据解析）、15.4%（统计）、17.3%（统计）、18.1%（统计）、17.7%（统计）

工作的两类线程（主要，还有一些周期性运行的线程）：

数据解析线程（只有一个），将log从文件中取出，push进队列，需要加锁-解锁

统计线程（可配），将数据从队列中取出，两个阶段front和pop，都需要对队列进行加锁-解锁。

 

针对上面几个场景进行分析，随着统计线程的增多，由于线程同步的需要，数据解析线程的idle越来越大，同时统计线程的idle也越来越大。

初步判断，短板问题是由多线程同步带来的。

 

 

3）考虑统计线程统计逻辑本身的短板

a．开1个统计线程，使用文件极限压，无dump和clicklog，先使用数据解析线程将统计队列压满，在统计队列满后，停数据解析线程，开统计线程进行统计。

开数据解析进程（统计线程不运行），有一个核cpu idle为0%（数据解析）

停数据解析线程，开统计线程进行统计，有一个核cpu idle为18%（统计线程）

 

由该场景推断，统计线程本身也存在短板。

                                                                                                                                                              

b．开1个统计线程，使用文件极限压，无dump和clicklog，先使用数据解析线程将统计队列压满，在统计队列满后，停数据解析线程，开统计线程进行统计，统计线程不发送key-value数据给armor。

统计线程idle可以到达0%

 

由以上两个场景分析可得出结论，统计线程本身也存在短板，短板在于将数据发送给armor。主要是由于网络交互带来的等待。

 

4）综合考虑

结合2）和3)，制造如下场景：

开8个统计线程，统计线程不发送数据给armor，使用文件极限压，无dump和clicklog。

Cpu idle平均为26%，在解决掉统计线程本身的短板后，开多个统计线程进行统计，cpu idle依然无法压到0%

可以得出结论，多线程同步造成的等待使cpu  idle无法压到0%

 

结论：

综上分析，map1  短板主要在以下两个方面：

1）  统计线程本身的短板：数据发送给armor带来的网络交互

2）  多线程的同步：map1中存在很多线程需要同步的点

 

针对于统计线程本身的短板，可以考虑增大发送给armor的数据包的大小或者使用多线程来减缓

针对于多线程同步带来的开销，可以考虑对锁的粒度进行细化来减缓