1
- “橫向擴展” （scale out）：通過增加服務器數量來提高系統整體的處理能力並分擔負載
- “縱向擴展” （scale up） ：通過提高硬件性能來提高處理能力
2
- 硬盤和內存的讀取速度差異能達到100000----1000000倍（10的5次方--10的6次方）
- 硬盤總線與內存總線的傳輸速度爲：內存：7.5G/秒，磁盤：58M/秒
3
- load average: 0.7,0.6,0.5 平均負載從左到右爲1分鐘，5分鐘，15分鐘內，單位時間中處於等待狀態的任務數。也就是說
- 該數字報告了平均有多少任務在等待。平均負載高，說明有相應數量的任務在等待，可以認爲運行有延遲，也就是負載過高
- 硬件每隔一定週期給CPU發送中斷信號，因爲是週期發送的，所以稱爲“定時器中斷”（timeer interrupt）。例如Centos5的中斷
- 時間設置爲4毫秒。每次發生中斷時，CPU就會進行與時間有關的處理，如推動時鐘前進、計算運行中的進程使用了多少CPU等。平均負載值
- 就是在每次定時器中斷髮生時計算的。 內核在發生定時器中斷時，計算就緒任務數（可以運行的任務）和等待I/O的任務數。將該數字除以單位時間，就是報告中的平均負載。 就緒任務就是由於其他任務佔有CPU而無法開始計算任務。也就是說平均負載中的負載的意思就是：
想要執行處理，卻無法執行而不得不等待的進程有多少
更具體的一點就是
1.等待賦予CPU的執行權限的進程
2.等待磁盤I/O完成的進程
4
- CPU 負載過高時，尋找問題流程的思路：
- 1.確認是用戶程序處理的瓶頸，還是系統程序的原因。用top 或者 sar確認
- 2.再通過ps 查看可見進程的狀態和CPU使用時間等，確定導致問題的進程
- 3.確定進程後，想要進一步尋找原因，可以銅鼓strace跟蹤，或oprofile進行剖析，以確定瓶頸所在
5
- sar -f 指定日誌文件
- sar -u 查看CPU使用率
- sar -q 查看平均負載
- sar -r 查看內存使用
- sar -W 查看頁面交換髮生情況
6
- 分佈式MYSQL應用的要點：
- 1.靈活應用操作系統緩存
- 2.正確設置索引
- 3.以橫向擴展爲前提的設計
- 整數int類型32比特，是四個字節，字符8比特，是一個字節
- 索引分爲二叉樹 與 B樹 與B+樹
- 善用explain分析索引，儘量少用Join，換成where in
7
- 月PV = 100萬-200萬左右 單臺服務器可以支撐 （4核8G內存）
- 爬蟲服務器無法使用緩存，會爬很久以前的記錄，分流到單獨的服務器
8
- 系統穩定性措施
- 維持適當的餘量-內存容量，cpu負載-> 使用到極限的7成
- 去除不穩定因素
- 1.規定SQL負載上限-必要時將負載過高的SQL移到其他主機
- 2.減少內存泄露
- 3.異常行爲的自律控制
- 自動DOS判斷 （mod_dossdetector）
- 自動重啓
- 自動終止耗時查詢（kill 過長的SQL）
9
- 虛擬化管理
- 1.虛擬機的hostname不要重複，在線遷移的時候會出問題
- 2.虛擬機配合DNS能更有效的管理
- 如vm1.主機.com ,當出現故障的時候可以通過名字來知道虛擬機遷移到哪個主機上，更快的定位問題
- 虛擬機消耗：
- CPU: 2%-3%左右
- 內存：10%左右
- 網絡性能：50%左右
- IO：5%左右
- SSD的訪問性能
- 內存 > SSD > HDD RAID10 > HDD RAID-1
10
- Tokyo Tyrant 是本地運行的key-value 存數系統TokyoCabinet的網絡版。它將數據寫在磁盤上實現永久保存，但由於有磁盤訪問，性能不足memcached，但仍比RDBMS快很多。
- Varnish 重啓後數據會丟失
- 特點：
- 對象（默認）通過mmap保存在磁盤上的文件中，而且進程重啓後緩存全部丟失
- 基本配置通過命令行參數指定，代理規則通過配置文件（VCL）指定
- 自身不能將日誌寫入文件，而是放在共享內存中 （varnishnaca命令將日誌寫到實際文件中）
- squid會把緩存寫入文件，但squid IO負載會高。