一、服務配置建議
二、MySQL性能分析及建議
三、系統性能分析
一、服務器配置
先閱讀apache配置優化建議如下，再對相關參數進行調整，觀察服務器狀況.
Apache配置優化建議:
進入/usr/local/apache2/conf/extra 目錄下
Apache優化,
經過上述操作後，Apache已經能夠正常運行。但是，對於訪問量稍大的站點，Apache的這些默認配置是無法滿足需求的，我們仍需調整Apache的一些參數，使Apache能夠在大訪問量環境下發揮出更好的性能。以下我們對Apache配置文件httpd.conf中對性能影響較大的參數進行一些說明。
(1) Timeout 該參數指定Apache在接收請求或發送所請求內容之前的最長等待時間（秒），若超過該時間Apache則放棄處理該請求，並釋放連接。該參數默認值為120，推薦設置為60，對於訪問量較大的網站可以設置為30或15。
(2) KeepAlive 該參數控制Apache是否允許在一個連接中有多個請求，默認打開。但對於大多數論壇類型站點來說，通常設置為off以關閉該支持。
(3) MPM – prefork.c 在默認情況下Apache使用Prefork（進程）工作模式，可以說這部分的參數設置是對Apache性能影響的核心和關鍵。用戶可以在配置文檔中找到以下配置段：
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 15
MaxRequestsPerChild 0
</IfModule>
這就是控制Apache進程工作的配置段，為了更好的理解上述配置中的各項參數，下面讓我們先了解一下Apache是如何控制進程工作的。我們知道，在Unix系統中，很多服務(Service)的守護進程(Daemon)在啟動時會創建一個進程以准備應答可能的連接請求，服務即進入了端口監聽狀態，當一個來自客戶端(Client)的請求被發送至服務所監聽的端口時，該服務進程即會處理該請求，在處理過程中，該進程處於獨占狀態，也就是說如果此時有其他請求到達，這些請求只能“排隊”等待當前請求處理完成且服務進程釋放。這樣就會導致越來越多的請求處於隊列等待狀態，實際表現就是該服務處理能力非常低下。Apache使用Prefork模式很好的解決了這一問題。下面我們來看看Apache實際上是如何高效率工作的。
當Apache啟動時，Apache會啟動StartSpareServers個空閒進程同時准備接收處理請求，當多個請求到來時，StarSpareServers進行會越來越少，當空閒進程減少到MinSpareServers個時，Apache為了能夠繼續有充裕的進程處理請求，它會再啟動StartsServers個進程備用，這樣就大大減少了請求隊列等待的可能，使得服務效率提高，這也是為什麼叫做Pre-fork的原因；讓我們繼續跟蹤Apache的工作，我們假設Apache已經啟動了200個進程來處理請求，理論上來說，此時Apache一共有205個進程，而過了一段時間，假設有100個請求都得到了Apache的響應和處理，那麼此時這100個進程就被釋放成為空閒進程，那麼此時Apache有105個空閒進程。而對於服務而言，啟動太多的空閒進程時沒有任何意義的，反而會降低服務器的整體性能，那麼Apache真的會有105個空閒進程麼？當然不會！實際上Apache隨時在檢查自己，當發現有超過MaxSpareServers個空閒進程時，則會自動停止關閉一些進程，以保證空閒進程不過過多。說到這裡，用戶應該對Apache的工作方式有了一定的了解，如果想獲得更多更詳細的說明請參閱Apache手冊文檔。
我們還有兩個參數沒有介紹：MaxClients和MaxRequestPerchild；MaxClients指定Apache在同一時間內最多允許有多少客戶端能夠與其連接，如果超過MaxClients個連接，客戶端將會得到一個“服務器繁忙”的錯誤頁面。我們看到默認情況下MaxClients設置為15，這對一些中型站點和大型站點顯然是遠遠不夠的！也許您需要同時允許512個客戶端連接才能滿足應用需求，好吧，那麼就讓我們把MaxClients修改為512，保存httpd.conf並退出，重啟Apache，很遺憾，在重啟過程當中您看到了一些錯誤提示，Apache重啟失敗。錯誤提示中告訴您MaxClients最大只能設定為256，相信您一定很失望。不過不要沮喪，Apache作為世界一流的Web Server一定不會如此單薄的！在默認情況下，MaxClients的確只能設定為不超過256的整數，但是，如果您有需要完全可以隨意定制，此時就需要使用ServerLimit參數來配合使用，簡單的說ServerLimit就像是水桶，而MaxClients就像是水，您可以通過更換更大的水桶（將ServerLimit設定為一個較大值）來容納更多的水(MaxClients)，但要注意，MaxClients的設定數值是不能大於ServerLimit的設定數值的！
注:MaxClents < ServerLimit
下面讓我們了解一下MaxRequestPerChild參數，該參數指定一個連接進程中可以有多少個線程同時工作。也許這樣解釋過於專業，那麼您只要想想“網絡螞蟻”、“網際快車FlashGet”中的“多點同時下載”即可，該參數實際上就是限制最多可以用幾個“點”。默認設置為0，即為：不限制。但需要注意，如果將該值設置的過小會引起訪問問題，如果沒有特殊需要或者訪問量壓力並非很大可以保持默認值，如果訪問量很大則推薦設置為2048。
好了，解釋了這麼多，讓我們看看經過修改後Perfork.c配置段的推薦配置：
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 1024
MaxClients 768
MaxRequestsPerChild 0
</IfModule>
完成了上述對Apache的調整，Apache已經獲得了較大的性能改善。
二、MySQL優化建議及分析
MySQL優化步驟:
1、看機器配置，指三大件：cpu、內存、磁盤（I/O）
2、看mysql配置參數
3、查系mysql行狀態，可以用mysqlreport工具來查看
4、查看mysql的慢查詢
依次解決了以上問題之後，再來查找程序方面的問題
MySQL優化具體方法及建議
1. 以root數據庫服務器，先查看相關日志，看看有什麼異常tail ?n100 xxx.erro
2. 以root身份登陸MySQL數據庫,
Mysql ?uroot ?p
? show processlist;
3. 使用show status命令
mysql會給出一個很長的列表
官方說明在http://www.mysql.com/doc/e…
含義如下:
aborted_clients 客戶端非法中斷連接次數
aborted_connects 連接mysql失敗次數
com_xxx xxx命令執行次數,有很多條
connections 連接mysql的數量
Created_tmp_disk_tables 在磁盤上創建的臨時表
Created_tmp_tables 在內存裡創建的臨時表
Created_tmp_files 臨時文件數
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同時使用的連接數
Open_tables 開放的表
Open_files 開放的文件
Opened_tables 打開的表
Questions 提交到server的查詢數
Sort_merge_passes 如果這個值很大,應該增加my.cnf中的sort_buffer值
Uptime 服務器已經工作的秒數
提升性能的建議:
1.如果opened_tables太大,應該把my.cnf中的table_cache變大
2.如果Key_reads太大,則應該把my.cnf中key_buffer_size變大.可以用Key_reads/Key_read_requests計算出cache失敗率
3.如果Handler_read_rnd太大,則你寫的SQL語句裡很多查詢都是要掃描整個表,而沒有發揮索引的鍵的作用
4.如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用Threads_created/Connections計算cache命中率
5.如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基於內存的臨時表代替基於磁盤的
注:所以配置參數可以修改/etc/my.cnf 此文件.
具體更深入的mysql優化請見本版相關貼
三、系統負載及性能分析方法及工具介紹
vmstat
Procs
-r:
運行的和等待(CPU時間片)運行的進程數，這個值也可以判斷是否需要增加CPU(長期大於1)
-b:
處於不可中斷狀態的進程數，常見的情況是由IO引起的
Memory
-swpd: 切換到交換內存上的內存(默認以KB為單位)
如果 swpd 的值不為0，或者還比較大，比如超過100M了，但是 si, so 的值長期為 0，這種情況我們可以不用擔心，不會影響系統性能。
-free: 空閒的物理內存
-buff: 作為buffer cache的內存，對塊設備的讀寫進行緩沖
-cache: 作為page cache的內存, 文件系統的cache
如果 cache 的值大的時候，說明cache住的文件數多，如果頻繁訪問到的文件都能被cache住，那麼磁盤的讀IO bi 會非常小。
Swap
-si: 交換內存使用，由磁盤調入內存
-so: 交換內存使用，由內存調入磁盤
內存夠用的時候，這2個值都是0，如果這2個值長期大於0時，系統性能會受到影響。磁盤IO和CPU資源都會被消耗。
我發現有些朋友看到空閒內存(free)很少或接近於0時，就認為內存不夠用了，實際上不能光看這一點的，還要結合si,so，如果free很少，但是si,so也很少(大多時候是0)，那麼不用擔心，系統性能這時不會受到影響的。
Io
-bi: 從塊設備讀入的數據總量(讀磁盤) (KB/s)，
-bo: 寫入到塊設備的數據總理(寫磁盤) (KB/s)
隨機磁盤讀寫的時候，這2個 值越大（如超出1M），能看到CPU在IO等待的值也會越大
System
-in: 每秒產生的中斷次數
-cs: 每秒產生的上下文切換次數
上面這2個值越大，會看到由內核消耗的CPU時間會越多
Cpu
-us: 用戶進程消耗的CPU時間百分比
us 的值比較高時，說明用戶進程消耗的CPU時間多，但是如果長期超過50% 的使用，那麼我們就該考慮優化程序算法或者進行加速了(比如 PHP/Perl)
-sy: 內核進程消耗的CPU時間百分比
sy 的值高時，說明系統內核消耗的CPU資源多，這並不是良性的表現，我們應該檢查原因。
-wa: IO等待消耗的CPU時間百分比
wa 的值高時，說明IO等待比較嚴重，這可能是由於磁盤大量作隨機訪問造成，也有可能是磁盤的帶寬出現瓶頸(塊操作)。
-id: CPU處在空閒狀態時間百分比
情景分析
這個vmstat的輸出那些信息值得關注？
-Procs r: 運行的進程比較多，系統很繁忙
-Io bo: 磁盤寫的數據量稍大，如果是大文件的寫，10M以內基本不用擔心，如果是小文件寫2M以內基本正常
Cpu us: 持續大於50，服務高峰期可以接受
Cpu wa: 稍微有些高
Cpu id:持續小於50，服務高峰期可以接受
Top 性能分析介紹
這個命令可以查看系統中運行的進程的狀況，CPU使用狀況，系統負載，內存使用等。它是檢查系統進程運行狀況最方便的工具了，它默認顯示部分活動的進程，並且按照進程使用CPU的多少排序。它可以顯示全部CPU的使用狀況，也可以顯示每個進程都運行在那個CPU上面。
我習慣使用這個命令查看那些進程或者那類進程占用CPU和內存資源最多，以此迅速定位存在性能問題的進程，以及運行異常的進程。
用 top 看到的內存的說明(Mem的第2行)
-actv
active 活躍的內存頁，正在映射給進程使用
-in_d
inactive_dirty 非活躍的內存頁，並且內存數據被修改，需要寫回磁盤
-in_c
inactive_clean 非活躍的內存頁，干淨的數據，可以被重新分配使用
問題？
in_d 和 in_c 以及 cache, buffer 的內存有何不同？
我的理解：
actv, in_d, in_c 是 VM 中對內存的管理組織形式，buffer是塊設備讀寫緩沖，cache是文件系統緩存
top工具介紹:
用 top 看到的進程所處的幾種狀態(STAT列)。
-D 不可中斷休眠，通常是 IO 操作所處的狀態
-R 正在執行的或者處在等待執行的進程隊列中
-S 休眠中
-T 暫停刮起的（比如Ctrl+Z），也可能是被 strace 命令調用中的狀態
-Z 僵屍進程，進程執行完成，但由於其父進程沒有銷毀該進程，而被init進程接管進行銷毀。
-W 沒有使用物理內存，所占用的物理內存被切換到交換內存
< 高優先級的進程
-N 低優先級
有時候一個進程會有多個狀態的標志，比如SWN，SW