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

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

在 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查找等比較搞人的外部組件
  • ??臻g

磁盤

  • 本地磁盤存取
  • 隨機磁盤讀寫 -> 磁盤尋道
  • 磁盤碎片化
  • 寫入超過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.824886.live/librarys/veda/detail/2408,歡迎訪問原出處。

不打個分嗎?

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

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

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

大家都在看

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

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

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

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

《致加西亞的信》 阿爾伯特·哈伯德(Hubbard.E.) (作者), 趙立光 (譯者), 艾柯 (譯者)

《致加西亞的信(經典盒裝版)》內容簡介:美西戰爭爆發以后,美國必須立即與古巴起義軍首領加西亞取得聯系,并獲得他的合作。但當時,加西亞身在古巴的深山里——沒有人知道他的確切地點,所以沒法與他取得聯系。這時,有人向總統推薦一個名叫羅文的人,說他有辦法找到加西亞,而且也只有他才能找得到。他們找來羅文,交給他一封寫給加西亞的信。三周后,羅文徒步走過一個危機四伏的國家,最終把那封信交給了加西亞。 此后,羅文的事跡被傳為佳話,“送信”成為了敬業、忠誠、勤奮的象征,羅文便成了每個領導都想找到的人和每個員工都應該學習和效仿的榜樣。

更多計算機寶庫...

云南快乐十分走势一定牛 凤凰配资 炒股杠杆配资 股票涨跌怎么计算 大乐透胆拖中奖规则 九鼎期货配资 重庆时时开彩结果记录 武汉炒股配资 福建十一选五中奖奖金 重庆快乐十分属于福利彩票吗 一分快3彩票平台