服務(wù)器能優(yōu)化配置建議.docx

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