列舉一些常見的系統系能瓶頸

Common Bottlenecks
服務器君一共花費了63.581 ms進行了4次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

在 Zen And The Art Of Scaling - A Koan And Epigram Approach 一文中, Russell Sullivan 提出一個很有趣的設想:一共有20種經典的瓶頸。這聽起來就像只有20種基本的故事情節(20 basic story plots)那樣讓人懷疑。不過基于每個人不同的分類方式,這個說法或許是對的,但是在現實中,眾所周知,瓶頸是無窮無盡的而且涉及方方面面。

一天, 來自 Terracotta 的 Aurelien Broszniowski 給我電郵了一份他心中的瓶頸列表,我們同時把我們的郵件抄送給了Russell, 他也給出了他的列表。而我也有我自己的想法。 所以,下面就是這幾碗水煮成的一鍋石頭湯( http://en.wikipedia.org/wiki/Stone_soup, stone soup典故)

Russell 說要是年輕的時候就知道這些該多好啊,而對我來說則可以提供更多的思路。你的經驗越多,處理過不同類型的項目,你就可以給這個列表增加更多的內容。因此當你在閱讀這個列表時,或者是在整理自己的列表時,多年的豐富經驗的積累以及遇到的一些小挫折,每一個故事都值得進行總結。

數據庫

  • 工作中數據大小超過可用內存 RAM
  • 長短查詢混合
  • 寫-寫 沖突
  • 大的聯合查詢占光內存

虛擬化

  • 共享 HDD 存儲,磁盤尋道掛起
  • 云平臺中的網絡 I/O 波動

編程

  • 線程:死鎖、相對于事件驅動來說過于重量級、調試、線程數與性能比非線性
  • 事件驅動編程:回調的復雜性、函數調用中如何保存狀態(how-to-store-state-in-function-calls)
  • 缺少profile工具、缺少trace工具、缺少日志工具
  • 單點故障、橫向不可擴展
  • 有狀態的應用
  • 搓設計:一臺機器上能跑,幾個用戶也能跑,幾個月后,幾年后,尼瑪,發現扛不住了,整個架構需要重寫。
  • 算法復雜度
  • 依賴于諸如DNS查找等比較搞人的外部組件
  • 棧空間

磁盤

  • 本地磁盤存取
  • 隨機磁盤讀寫 -> 磁盤尋道
  • 磁盤碎片化
  • 寫入超過SSD容量的數據導致SSD硬盤性能降低

操作系統

  • 內核緩沖刷入磁盤,填充linux緩沖區緩存
  • TCP緩沖區過小
  • 文件描述符限制
  • 功率分配

緩存

  • 不使用memcached
  • HTTP中,header,etags,不壓縮(headers, etags, not gzipping)
  • 沒有充分使用瀏覽器緩存功能
  • 字節碼緩存(如PHP)
  • L1/L2緩存,這是個很大的瓶頸。把頻繁使用的數據保持在L1/L2中。設計到的方面很多:網絡數據壓縮后再發送,基于列壓縮的DB中不解壓直接計算等等。有TLB友好的算法。最重要的是牢固掌握以下基礎知識:多核CPU、L1/L2,共享L3,NUMA內存,CPU、內存之間的數據傳輸帶寬延遲,磁盤頁緩存,臟頁,TCP從CPU到DRAM到網卡的流程。

CPU

  • CPU 過載
  • 上下文切換 -> 一個內核上跑了太多的線程,linux調度對于應用來說很不友好, 太多的系統調用, 等等...
  • IO 等待 -> 所有的CPU都掛起等待比較慢的IO
  • CPU 緩存: 緩存數據是一個為了平衡不同實例有不同的值和繁重的同步緩存數據保持一致,而精心設計的一個進程。
  • 背板吞吐量

網絡

  • 網卡的最大輸出帶寬,IRQ達到飽和狀態,軟件中斷占用了100%的CPU
  • DNS查找
  • 丟包
  • 網絡路由瞎指揮
  • 網絡磁盤訪問
  • 共享SAN(Storage Area Network)
  • 服務器失敗 -> 服務器無響應

過程

  • 測試時間 Testing time
  • 開發時間 Development time
  • 團隊人數 Team size
  • 預算 Budget
  • 代碼缺陷 Code debt

內存

  • 內存溢出 -> 殺進程,進入 swap ,越來越慢
  • 內存溢出導致磁盤頻繁讀寫(swap相關)
  • 內存庫開銷
  • 內存碎片
  • Java 需要垃圾收集導致程序暫停
  • C 語言的 malloc 無法分配

如果你有更多的瓶頸見解與心得,歡迎補充。

本文地址:http://www.snpmgr.live/librarys/veda/detail/2408,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.snpmgr.live/librarys/veda/detail/2408

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《重構:改善既有代碼的設計》 福勒(Martin Fowler) (作者), 熊節 (譯者)

《重構:改善既有代碼的設計》清晰地揭示了重構的過程,解釋了重構的原理和最佳實踐方式,并給出了何時以及何地應該開始挖掘代碼以求改善。書中給出了70多個可行的重構,每個重構都介紹了一種經過驗證的代碼變換手法的動機和技術。《重構:改善既有代碼的設計》提出的重構準則將幫助你一次一小步地修改你的代碼,從而減少了開發過程中的風險。

更多計算機寶庫...

燃烧吧足球登陆