https://plantegg.github.io/2024/04/26/%E6%B5%81%E9%87%8F%E4%B8%80%E6%A0%B7%E4%BD%86%E4%B8%BA%E4%BB%80%E4%B9%88CPU%E4%BD%BF%E7%94%A8%E7%8E%87%E5%B7%AE%E5%88%AB%E5%BE%88%E5%A4%A7/
這是我翻到2013年的一篇文章,當時驚動所有公司高人,最後分析得知原因後所有人都跪拜,你要知道那是2013年,正好10年過去了,如果是現在用我們星球的理論去套的話,簡直不要太容易
問題描述
同樣大小記憶體、同樣的CPU、同樣數量的請求、幾乎可以忽略的io,兩個機器的load卻差異挺大。一個機器的load是12左右,另外一個機器卻是30左右
你可以理解這是兩臺一摸一樣的物理機掛在一個LVS 下,LVS 分發流量絕對均衡
所以要找出為什麼?
分析
兩臺機器的資源使用率:
1
|
//load低、CPU使用率低 的物理機,省略一部分核
|
可以分析產出為什麼低,檢查CPU是否降頻、記憶體頻率是否有差異——檢查結果一致
10年前經過一陣 perf top 看熱點後終於醒悟過來知道得去看 IPC,也就是相同CPU使用率下,其中慢的機器產出低了一半,那麼繼續透過perf看IPC:
可以看到兩臺機器的IPC是 0.3 VS 0.55,和CPU使用率差異基本一致,instructions幾乎一樣(意味著流量一樣,LVS 不背鍋),但是處理同樣的instructions 用掉的cpu-clock 幾乎差了一倍,這應該是典型的記憶體時延大了一倍導致的。IPC 大致等於 instrunctions/cpu-clock (IPC:instrunctions per cycles)
經檢查這兩臺物理機都是兩路,雖然CPU型號/記憶體頻率一致,但是主機板間跨Socket的 QPI頻寬差了一倍(主機板是兩個不同的服務商提供)。可以透過綁核測試不同Socket/Node 下記憶體時延來確認這個問題
這是同一臺機器下兩個Socket 的記憶體頻寬,所以如果跨Socket 記憶體訪問多了就會導致時延更高、CPU使用率更高
總結
在今天我們看到這種問題就很容易了,但我還是要感嘆一下在入門前簡直太神奇,入門後也不過爾爾,希望你也早點入門。
第一:向CPU要產出,同樣的使用率產出得一樣,不一樣的話肯定是偷懶了,偷懶的直接證據就是 IPC 低了,導致IPC 低最常見的是記憶體時延高(記憶體頻率、跨Node/Socket 等,或者記憶體碎片);延伸閱讀:效能的本質 IPC ,也是本星球唯二的必讀實驗
第二:測試工具很完善了,lmbench , 怎麼用lmbench 可以看這篇 ; 怎麼使用perf Perf IPC以及CPU效能
,學成後裝逼可以看 聽風扇聲音來定位效能瓶頸
我以前說過每個領域都有一些核心知識點,IPC 就是CPU領域的核心知識點,和tcp的rmem/wmem 一樣很容易引導你入門
計算機專業裡非要挑幾個必學的知識點肯定得有計算機組成原理,但計算機組成原理內容太多,都去看也不現實,況且很多過時的東西,那麼我只希望你能記住計算機組成原理裡有個最核心的麻煩:記憶體牆——CPU 訪問記憶體太慢導致了記憶體牆是我們碰到眾多效能問題的最主要、最核心的一個,結合今天這個案例掌握IPC後再來學記憶體牆,再到理解計算機組成原理就對了,從一個實用的小點入手。
計算機專業裡除掉組成原理(有點高大上,沒那麼接地氣),另外一個我覺得最有用的是網路——看著low但是接地氣,問題多,很實用
2011年的文章:
詳解伺服器記憶體頻寬計算和使用情況測量
更好的工具來發現類似問題:https://github.com/intel/numatop
如果你覺得看完對你很有幫助可以透過如下方式找到我
find me on twitter: @plantegg
知識星球:https://t.zsxq.com/0cSFEUh2J
開了一個星球,在裡面講解一些案例、知識、學習方法,肯定沒法讓大家稱為頂尖程式設計師(我自己都不是),只是希望用我的方法、知識、經驗、案例作為你的墊腳石,幫助你快速、早日成為一個基本合格的程式設計師。
爭取在星球內:
- 養成基本動手能力
- 擁有起碼的分析推理能力–按我接觸的程式設計師,大多都是沒有邏輯的
- 知識上教會你幾個關鍵的知識點