多線程OR多進(jìn)程-訪存密集型應(yīng)用

hy036630

                   Linux下多線程和多進(jìn)程的優(yōu)劣我就不講了，那些都是老生常談的東西，最近項(xiàng)目做一個(gè)流數(shù)據(jù)統(tǒng)計(jì)引擎（有點(diǎn)類似數(shù)據(jù)庫的統(tǒng)計(jì)count(*)等）。項(xiàng)目是用多線程實(shí)現(xiàn)的。
具體的場(chǎng)景是這樣的， 一組線程從socket接受流數(shù)據(jù)，經(jīng)過簡(jiǎn)單處理把數(shù)據(jù)送到處理線程，讓處理線程對(duì)流數(shù)據(jù)進(jìn)行處理（我們項(xiàng)目把每一類流數(shù)據(jù)具體為一類event），然后等到一定的時(shí)間把統(tǒng)計(jì)結(jié)果寫文件。

                  處理的場(chǎng)景如下：所有的處理單元用無鎖的環(huán)形緩沖區(qū)串在一起，形成一條流水線，每一個(gè)處理單元是一個(gè)線程，這樣的好處是流數(shù)據(jù)是所有處理單元共享的，可以節(jié)約內(nèi)存，然后流數(shù)據(jù)的指針在不同的處理單元串行流動(dòng)（這樣可以避免用到鎖）。

                這是一個(gè)典型的場(chǎng)景，數(shù)據(jù)的指針在流動(dòng)，然后每個(gè)線程查看數(shù)據(jù)（不會(huì)修改），然后更新統(tǒng)計(jì)結(jié)果，所有的程序沒有用到鎖，按照道理來說，這樣的模型是比較好的。但是實(shí)際情況是一個(gè)處理單元的處理能力是3W個(gè)Event/s,10個(gè)處理單元形成流水線以后，處理能力只能達(dá)到3000個(gè)Event/s。這樣的結(jié)果讓我大跌眼鏡。
               
               嘗試過的解決方案：一開始以為操作系統(tǒng)的內(nèi)存數(shù)據(jù)結(jié)構(gòu)同步會(huì)影響流水線的并行性，后面嘗試在每個(gè)線程上面加一個(gè)線程池，這樣每個(gè)線程的內(nèi)存分配和釋放都是線程自己管理，甚至連STL也沒有使用，內(nèi)存完全是自己控制的，但是沒有絲毫效果。
                                        后面嘗試用多進(jìn)程，每個(gè)處理單元都是一個(gè)進(jìn)程，進(jìn)程間用管道串起來，數(shù)據(jù)在管道間傳輸，這樣的話，速度能夠基本上保持線性增加（2U 4C 超線程的服務(wù)器）1個(gè)處理單元式3W 10個(gè)處理單元大概有2.5W/處理單元 也就是總共25W的吞吐。
                                 
                  這里我看出多線程還有些什么地方有問題，訪存得問題還是緩存命中的問題，現(xiàn)在也不得而知，不知道這種模型能不能夠改進(jìn)，畢竟多線程能夠共享數(shù)據(jù)，所以可以共享原始的流數(shù)據(jù)，可以節(jié)約很多內(nèi)存，如果改進(jìn)線程模型可以增加線性不知道又沒有高手能夠解答一下。
                 
              我在網(wǎng)上找了很多資料，版主 johnbull 曾今說過這個(gè)問題，他說多線程共享數(shù)據(jù)，會(huì)造成太多的緩沖會(huì)寫（wirte-back),所以導(dǎo)致內(nèi)存子系統(tǒng)的串行化訪問，我感覺我的程序問題就在這里，不過我不懂的是，多線程共享數(shù)據(jù)，但是這個(gè)數(shù)據(jù)是只讀的（沒有線程回去修改），所以我的理解是數(shù)據(jù)如果不是dirty的 那么不用wirte-back吧。。。。。。。。
            
               不知道大家有沒有關(guān)注訪存密集型應(yīng)用，特別是SMP的架構(gòu)下，內(nèi)存的訪問是最大的瓶頸吧。期待大家的解答。。
                  

zylthinking

沒徹底搞清楚到底怎么個(gè)模型， 可否帖個(gè)大概代碼出來？

JohnBull

不能確定是我提到的原因。
我懷疑是你使用“無鎖”算法造成的，無鎖雖然避免了互斥開銷，但你可能因此而不得不采用忙等方式操作，搞不好得不償失。

drangon

oprofile ，先找問題原因吧，

hy036630

代碼太多，真帖不了

hy036630

確實(shí)是用了忙等，不過一個(gè)線程也是忙等。多個(gè)線程一起忙等，對(duì)程序有影響么，而且機(jī)器的線程數(shù)是32線程的，10個(gè)線程應(yīng)該可以同時(shí)運(yùn)行吧。

hy036630

確實(shí)正在用oprofile分析  不過那個(gè)工具網(wǎng)上介紹都比較淺,正在摸索

JohnBull

hy036630 發(fā)表于 2011-12-21 14:28
確實(shí)是用了忙等，不過一個(gè)線程也是忙等。多個(gè)線程一起忙等，對(duì)程序有影響么，而且機(jī)器的線程數(shù)是32線程的， ...

忙等就是空轉(zhuǎn)，空轉(zhuǎn)就是 “誓把時(shí)間片吃盡，我不干事別人也別想干”...
性能還能好？老老實(shí)實(shí)加上鎖再試試

google下“老板-雇員”算法。

hy036630

不好意思 可能我上面沒有說清楚
我用的是下面這個(gè)環(huán)形隊(duì)列  無鎖的實(shí)現(xiàn)一個(gè)進(jìn)程讀，一個(gè)進(jìn)程寫，沒有牽涉到其他線程。
這樣的方式把10個(gè)線程串成一條流水線，主線程把指針push到第一個(gè)線程的環(huán)形隊(duì)列，第一個(gè)線程從環(huán)形隊(duì)列里面pop出來一個(gè)數(shù)據(jù)(指針)，然后處理（不會(huì)修改這個(gè)指針指向的值），然后把這個(gè)指針插入到下一個(gè)線程的隊(duì)列，下一個(gè)線程也從自己的隊(duì)列里面pop一個(gè)數(shù)據(jù)，然后處理，再push到下下個(gè)線程的隊(duì)列。
所以只有一個(gè)線程的隊(duì)列滿了，push不進(jìn)去會(huì)循環(huán)的push，知道能夠push進(jìn)去，或者是隊(duì)列空了，pop出來的數(shù)據(jù)null，會(huì)繼續(xù)pop，這兩種情況下會(huì)忙等，不然是不會(huì)忙等的，而這兩種情況在測(cè)試的時(shí)候很少發(fā)生，對(duì)性能影響應(yīng)該很小。

1. template<class T>
   
2. class RingQueue {
   
3. public:
   
4. 
   
5.     RingQueue() {
   
6.         cout << "RingQueue::ctor" << endl;
   
7.     };
   
8. 
   
9.     virtual ~RingQueue() {
   
10.         cout << "RingQueue::destory" << endl;
    
11.     };
    
12. 
    
13.     void InitQueue() {
    
14.         Push_Count = 0;
    
15.         Push_Index = 0;
    
16.         Pop_Count = 0;
    
17.         Pop_Index = 0;
    
18.         memset(List, 0, sizeof (List));
    
19.     }
    
20. 
    
21.     bool Push(const T& AData) {
    
22.         if (Push_Count - Pop_Count < Max_Count) {
    
23.             List[Push_Index] = AData;
    
24.             Push_Count++;
    
25.             if (Push_Index == High_Index)
    
26.                 Push_Index = 0;
    
27.             else
    
28.                 Push_Index++;
    
29.             return true;
    
30.         } else
    
31.             return false;
    
32.     }
    
33.     T Pop() {
    
34.         T result = NULL;
    
35.         if (Push_Count != Pop_Count) {
    
36.             result = List[Pop_Index];
    
37.             Pop_Count++;
    
38.             if (Pop_Index == High_Index)
    
39.                 Pop_Index = 0;
    
40.             else
    
41.                 Pop_Index++;
    
42.         }
    
43.         return result;
    
44.     }
    
45. 
    
46.     long size() {
    
47.         return this->Push_Count - this->Pop_Count;
    
48.     }
    
49. 
    
50. private:
    
51.     RingQueue(const RingQueue& orig);
    
52.     T List[524288 * 2]; //2^19  4M�ռ�
    
53.     const static unsigned long Max_Count = 524288 * 2;
    
54.     const static unsigned long High_Index = 524288 * 2 - 1;
    
55.     unsigned long Push_Count;
    
56.     unsigned long Push_Index;
    
57.     unsigned long Pop_Count;
    
58.     unsigned long Pop_Index;
    
59. 
    
60. };

復(fù)制代碼

hy036630

還有 google 老板-雇員 找不到{:3_199:}