在Zen And The Art Of Scaling - A Koan And Epigram Approach中,Russell Sullivan提出了一個非常有趣的總結:軟件開發常見的20個傳統的系統瓶頸,這聽起來像是說有20個故事情節,並且依賴於你如何策劃這些故事,或許都是真的,但唯有實踐才知道它們帶給我們的酸甜苦辣。
有一天,Aurelien Broszniowski給我發了一份電子郵件,把這些瓶頸用列表的方式展示出來。在接下來的交談過程中,我又把該列表抄送給了Russell,Russell對此列表進行了整理。
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總是開始分配內存)