Tuning Linode VPS：小規模低性能低流量網站優化實踐

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

偶然看到以前寫過的這篇帖子 『小規模低性能低流量網站設計原則』，重新發到微博上引起了一點反響，覺得有必要以 Linode VPS 為例再做個簡單的優化實踐說明，免得總有人問我，也順便賺點點擊量 :)

假定現在你已經有了一個基本的 VPS 可用，基本記憶體 512MB 。 參考官方提供的各種安裝指導將 LAMP 這個組合運行了起來，作業系統一般 Ubuntu ，Web 服務器 Apache ，資料庫 MySQL ，然後是 PHP ，以及需要安裝的應用軟體，WordPress 、Drupal 或是 OpenCart 什麼的，一步一步配置好，能夠正常的流覽頁面。 按照官方指導文檔操作的一個好處是會包括一些基本的優化一點的配置。 不至於出現太大的錯誤。

一旦應用就緒後，登錄到作業系統中，通過 top / iostat / free 等基本作業系統命令收集基準資料，做記錄。 收集資訊越全面，對於後面的優化就越便利。 優化沒有魔法，只有合理的方法。

1.記憶體相關的調整

內部測試或是較小範圍使用，可能這樣也不會遇到太大問題。 一旦訪問人數多了一點，機器回應可能就有點慢了。 對於 VPS ，第一步著手調整的就是各個元件對記憶體的使用。 因為記憶體受限，對記憶體的使用一定要精打細算一點。 記住一旦記憶體耗盡，一部分記憶體調用壓到磁片上，系統負載會飆升，一般就會掛掉。

一般來說，對於 LAMP 環境，以下幾個地方要注意：

PHP 程式的記憶體相關的調整

PHP5 設定檔 php.ini 中 memory_limit 定義的值預設情況是16MB，該參數定義單個 PHP 腳本消耗最大的記憶體大小(大意)。 如果程式某個頁面需要的記憶體超過這個限制，訪問者最可能遇到一個 HTTP 500 錯誤，查看 Web 服務器錯誤日誌也可以看到。 多數情況下，這個值需要做相應調整。 比如設置為32MB，是否合適，需要做觀察。 有一個經驗方法是觀察 top 命令的輸出，看相應進程的 SHR 欄位的值，實際上總是儘量大一點點。 但不能過大，一旦有個別程式寫的不好調用的時候佔用過多資源，會導致 VPS 掛掉。

經常有人問，這個伺服器跑某某 Web 應用，能支援多少併發? 一個大致的思路是估算單個進程佔用的記憶體，看系統能分配多少記憶體給應用程式，併發的量大致可以估算得到。 但實際上，這個提問基本沒多大價值。

另外，還有一個比較重要的參數需要修改 output_buffering 需要修改為 On 或是具體數值(eg, 4096)。 修改配置後，檢查是否生效(如何檢查?)。 另外，記住error_log的位置，隨時查看。

MySQL 資料庫記憶體佔用

如果不確定 MySQL 記憶體使用方式，可以利用 MySQLReport 這個工具收集一下 MySQL 實例的資訊報告，不同時間段多收集幾次作為對比。 然後相應的調整 key_buffer/query_cache_size 等參數的大小, 一次調整一個參數，重啟動 MySQL ，繼續抽取報告，分析資料，然後調整下一個參數。 既然需要編輯設定檔 my.cnf , 建議順手加大一點 max_connections 這個參數(為什麼?)。

多數記憶體問題都是由資料庫 I/O 引起，導致 I/O 問題多由不合理資料庫調用有關(這麼說嚴謹麼?)，解決不合理調用要麼修改應用，要麼通過查詢緩存或是 Key-Value Cache 等辦法緩解。 這地方說來話長，假定 VPS 上基本不會有這麼複雜的環境。

2. 影響 CPU 利用率的調整

這個主要針對 PHP 的 Opcode(Accelerator) 而言，解析、編譯PHP代碼是相當消耗CPU的操作。 常見的要麼是 APC, 要麼是 eAccelerator 或是 XCache，在 Ubuntu 下安裝配置都相對簡單，參數調整簡單搜索一下就知曉了。 如果是 PHP 環境，那麼一定要用 Opcode 減少 CPU 的負荷(為什麼?)。 至於用哪一個關係倒是不大，但前提是必須要有一個。

另外，張磊同學這篇 讓進程運行在指定的CPU 對於特定需求的應用，很有借鑒意義。

3. 網路參數控制

修改 /etc/sysctl.conf 檔，增加如下幾行：

net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1

然後 sudo sysctl -p 使修改生效。 使用如下一行命令觀察半連接數量：

$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

其實一般來說，網路連接數不會成為最明顯的瓶頸。 但順手調整一下也好，「不費電」。 有人問，如果遇到 DDoS 怎麼辦?忍著。

4. 應用程式相關的調整

比較流行的開來源程式，不安裝協力廠商外掛程式的情況下，性能多少過得去。 建議如果沒有必要，不要啟用過多的協力廠商外掛程式，尤其是一些帶有統計或是「智慧」顯示內容之類的外掛程式能不用就不用。

這些開來源程式也基本上都有面向前端優化的靜態化解決方案，比如 WordPress 的 Cache 相關的外掛程式，強烈推薦啟用。 有時間看看前端優化的實踐建議。 #p#副標題#e#

優化最重要的是找到瓶頸，對症下藥。 前面已經說到了記憶體、CPU、網路，大致提了一點 I/O 問題，基本也就夠了。 PHP 的 Log , MySQL 的慢查詢 Log ，Apache 的 Error Log ，常過濾看一下有沒有新情況。

補充一點，別忘了修改 OS 的 ulimit 限制：

編輯 /etc/security/limits.conf 增加如下兩行(具體數值大點小點問題不大)：

* soft nofile 40960

* hard nofile 40960

編輯 /etc/pam.d/common-session ，增加如下一行：

session required pam_limits.so

編輯 /etc/profile ，增加如下一行：

ulimit -SHn 40960

重新開機 OS 即可生效。

Linode 後臺提供了幾個基本的統計圖，基本夠用。 可以設置磁片 I/O 過高的時候報警，系統會發郵件給你。 注意看一下網路流量的使用。 不要因為個別檔被盜鏈而將頻寬消耗殆盡。

上面提到的不少修改建議不要照葫蘆畫瓢，知其然，還要知其所以然。 每一步的調整多閱讀系統手冊，尤其是涉及到具體的參數數值，一定要針對實際情況修改。 對基本的配置足夠掌握之後，可以根據具體情況嘗試性能效率的元件，比如用 Nginx/LigHTTPd 替換 Apache ，但是要記住，如果 Apache 不是瓶頸的話，用傳說中性能更好的 Web 服務器來替換無疑是折騰。

再次提醒不要過度優化，足夠滿足需求就行了。 有更多的精力完全可以放在其他環節上。 另外，如果基本的調整做過之後，想用最省事的辦法改善性能，那麼，直接向服務商購買額外的記憶體吧。

好吧，最後我想說的是其實這個優化思路並不局限于 VPS ，這個最小實踐套路對於複雜的伺服器環境也是基本適用的。