軟體開發中常見的十大系統瓶頸------轉載

標籤：電子郵件   過程   ack   art   linu   中斷   資料   class   oom   

在Zen And The Art Of Scaling - A Koan And Epigram Approach中，Russell Sullivan提出了一個非常有趣的總結：軟體開發常見的20個傳統的系統瓶頸，這聽起來像是說有20個故事情節，並且依賴於你如何策劃這些故事，或許都是真的，但唯有實踐才知道它們帶給我們的酸甜苦辣。

有一天，Aurelien Broszniowski給我發了一份電子郵件，把這些瓶頸用列表的方式展示出來。在接下來的交談過程中，我又把該列表抄送給了Russell，Russell對此列表進行了整理。

<ignore_js_op> 


Russell說：“我真希望在年輕時看到這樣的一份列表”。伴隨著經驗的增長、項目的增多、解決各種不同類型的問題和不斷總結各種經驗教訓，你會在這份列表上添加更多的東西。所以，當你在閱讀該份列表時就像是在回顧一個個故事片段。

資料庫

工作任務記憶體超過可用的RAM記憶體
長/短查詢
寫入衝突
大串連（join）佔用記憶體
虛擬化

共用一個HDD、磁碟尋死（disk seek death）
在雲端網路I/O波動
編程

線程：死結、調試、非線性擴充等
事件驅動編程：callback()過於複雜、如何在函數調用中儲存有狀態等
缺乏調優、跟蹤、日誌等
單模組不可擴充、單點故障(SPOF:Single Point Of Failure)、非橫向擴充等
有狀態應用程式
設計問題：開發的應用程式只在自己的機器行運行正常，或者只是在幾個人測試的時候正常（沒有經曆壓力測試）。
演算法過於複雜
相關服務，例如DNS尋找以及其他可能屏蔽的服務
堆棧空間
磁碟

訪問本地磁碟
隨機訪問磁碟I/O
磁碟片段
當SSD寫入的資料大於SSD容量時，效能會下降
OS

Fsync飽和，Linux緩衝區填塞（Fsync flushing, linux buffer cache filling up）
TCP緩衝區太小
檔案描述符限制
功率分配（Power budget）
緩衝

沒使用memcached（資料庫崩潰）
HTTP中：headers、etags、沒有使用gzip壓縮等。
沒有充分利用瀏覽器緩衝
位元組程式碼快取（如PHP）
L1/L2緩衝：這是個令人頭疼的大瓶頸。把關鍵並且經常訪問的資料存放區在L1/L2中。這涉及到很多：snappy網路I/O,列資料庫直接在壓縮資料上運行演算法等。利用一些技術不銷毀你的TLB。最重要的思想是緊緊的抓住電腦的體繫結構，涉及多核CPU，L1/L2，共用的L3，NUMA RAM，從DRAM到晶片資料傳輸頻寬/延遲，DRAM緩衝的DiskPages，DirtyPages，流經CPU<->DRAM<->NIC的TCP包。
CPU

CPU過載
內容切換—>單核上開啟的線程過多、Linux調度器、系統調用太多等
IO等待—>所有的CPU在同速等待
CPU緩衝：快取資料是一個細粒度進程，為了在多個執行個體與不同的值資料之間找到正確的平衡，來保持快取資料的一致性和繁重同步。
底板輸送量（Backplane throughput）
網路

NIC刷爆、IRQ飽和、非強制中斷佔用掉了100%CPU
DNS查詢
資料包丟失
網路中存在預期外的路由
訪問網路磁碟
共用SAN
伺服器故障—>無法從服務處得到響應
進程

測試時間
開發時間
團隊規模
預算
代碼債務
記憶體

記憶體不足—>殺死進程，切換到swap，掛起
記憶體不足導致磁碟交換（與swap相關）
記憶庫開銷過大（Memory library overhead）
記憶體分區（在java中需要會因為記憶體回收而停頓；在C中，malloc總是開始分配記憶體）

軟體開發中常見的十大系統瓶頸------轉載