**:
推薦：《debug hacks》
實時計算引擎在處理實時資料時，要保證新到來的資料被及時得到處理。例如，對於**的訪問日誌資料，假設每一分鐘有乙個日誌檔案，那麼實時計算引擎必須滿足能夠在一分鐘之內處理完這一分鐘的日誌資料檔案，否則會導致日誌檔案堆積而不能被及時處理。前幾天，量子後端團隊排查了一次實時計算引擎出現的處理延遲故障，其中使用到了ltrace和strace工具，在這裡和大家分享一下。
當天由於大量突發異常資料的到來，導致實時計算引擎在處理每分鐘日誌檔案時的速度大幅下降，出現明顯的延遲現象，表現為平均每處理1分鐘檔案需要2分鐘甚至更長的時間，最長可以到5分鐘，進而導致了日誌檔案堆積而不能被處理。
實時計算引擎在處理日誌檔案時，採用順次讀取各分鐘檔案中的日誌記錄到記憶體中進行計算的方式（compute過程），因此引擎在每處理完1分鐘檔案時，需要進行日誌的輪轉切換（rotate過程）。
實時計算引擎採用全記憶體計算的方式，在處理每分鐘日誌檔案和輪轉時，都會進行頻繁的記憶體操作：記憶體的申請和釋放（記憶體管理使用的是glibc庫）。在整點輪轉（rotate過程）時，會釋放掉相當一部分計算過程不再需要的記憶體。
經過統計後發現，實時計算引擎在處理故障當天各分鐘日誌檔案時的compute時間和rotate時間有如下的規律：
(1) 每分鐘日誌檔案的處理時間（compute時間），整點輪轉之後的前半個小時日誌（如10:00~10:30的日誌），每處理一分鐘日誌一般都需要超過1分鐘的時間才能處理完；半點之後的日誌（如10:31~11:00的日誌），每處理一分鐘日誌一般只需要十幾秒到一分鐘以內。
(2) 每分鐘日誌檔案處理後的輪轉時間（rotate時間），整點輪轉時間耗時會比其他時間長很多，整天結束時的輪轉時間最長。
以上統計資訊提示我們，實時計算引擎的處理延遲就是發生在了整點rotate輪轉之後的前半個小時內，後半個小時基本可以恢復到正常水平：處理1分鐘日誌檔案只需要不到1分鐘時間。可見，引擎的處理延遲和整點rotate有一定的聯絡，是被整點rotate所觸發產生的。具體是什麼原因導致的，還需要進一步對實時計算引擎發生處理延遲時的狀態進行跟蹤才能確定。
考慮要具體跟蹤到實時計算引擎程式在發生故障時的執**況，實時得到引擎在做什麼操作（如庫函式呼叫、系統呼叫）時最耗時，才能定位到導致引擎處理延遲的根本原因，這裡討論後選擇strace和ltrace工具進行排查過程。其中，strace可以跟蹤系統呼叫情況及耗時情況，ltrace可以跟蹤庫函式呼叫情況及耗時情況。
在測試機上，使用線上版本的實時計算引擎程式，重跑觸發故障的日誌資料，當整點rotate觸發引擎發生處理延遲時，開始使用ltrace和strace工具跟蹤引擎當前的執行狀態，統計引擎在系統呼叫和庫函式上的呼叫時間開銷。
跟蹤庫函式的耗時情況：ltrace -fp pid -t –c
跟蹤系統呼叫的耗時情況：strace -fp pid –t –c
以下是對排查過程的結果分析：
測試發現在整點rotate時，cpu 100%用在了使用者空間，日誌處理到整點時，系統的空閒記憶體已經被用盡，所有的記憶體被page cache或者程序使用。
使用ltrace跟蹤發現，malloc較大記憶體塊時（如大於1000位元組），其執行時間較長，大約2~4秒鐘，這個是ltrace統計到的耗時最多的庫呼叫，引擎的大部分時間都花費在了malloc上。
使用strace跟蹤系統呼叫，發現在malloc記憶體的時候，沒有任何系統呼叫傳送到核心空間。再加上cpu 100%消耗在使用者空間，基本上可以判斷，malloc的時間都耗費在glibc的記憶體管理模組中，推測可能是由記憶體碎片引起的，當程式申請分配較大記憶體塊時，它會整理記憶體碎片從而形成較大的記憶體塊分配給計算引擎。
為 了進一步驗證第3步的結論，我們使用google的tcmalloc進行測試（export ld_preload="./libtcmalloc.so"）。測試結果發現使用tcmalloc後，實時計算引擎恢復正常，每個日誌檔案的處理時間從幾分鐘降到幾秒鐘，整點rotate時間也從十幾分鐘降到30~40秒。
由於本次實時計算引擎的處理延遲問題最終定位到是出在glibc的記憶體管理上，乙個簡單的解決方案是用tcmalloc替換glibc。但是從長遠來看，是否需要我們自己實現記憶體管理模組，取決於人力資源情況和tcmalloc的發展情況。
避免只依賴於經驗進行故障排查，要結合**實現邏輯和故障現場環境進行分析。
資料才是最真實可靠的，包括現場收集到的資料，歷史的資料，這些都是分析定位故障的重要依據。
沒有哪種工具是通用的，必須結合實際情況，選擇使用合適的除錯跟蹤工具，積累相關使用經驗。
最後，感謝這次一起排查問題的同事們：太奇、澄蒼、民瞻、淵虹。你們都很牛！
離線計算與實時計算的對比
就是在計算開始前已知所有輸入資料，輸入資料不會產生變化，一般計算量級較大，計算時間也較長。例如今天早上一點，把昨天累積的日誌，計算出所需結果。最經典的就是hadoop的mapreduce方式 一般是根據前一日的資料生成報表，雖然統計指標 報表繁多，但是對時效性不敏感。從技術操作的角度，這部分屬於批處...
收視率的實時計算
尼爾森和索福瑞 收視率的起源是應廣告主們為知曉花錢值不值而誕生。這活就交予市場調查公司完成。走的仍是市場調查的路子。收視率調查和所有市場調查如人口普查沒什麼兩樣。了解了人口普查的操作方式，您就知道樣本汙染是怎麼回事了，雖然索福瑞也想極力杜絕，換調查人員 頻繁換樣本戶都是一些補救措施。曾經，全球有無數...
JStorm 是乙個分布式實時計算引擎
jstorm 是乙個類似hadoop mapreduce的系統，使用者按照指定的介面實現乙個任務，然後將這個任務遞交給jstorm系統，jstorm將這個任務跑起來，並且按7 24小時執行起來，一旦中間乙個worker 發生意外故障，排程器立即分配乙個新的worker替換這個失效的worker。因此...