伺服器性能調整

我繼承了系統，我需要從硬體角度盡可能地調整性能。首先我是一個web開發者，不是系統管理員，我不想做任何過早的性能調整，所以這幾天我做了一點研究也設置了伺服器和應用程序監控並寫了一個小計劃如何改進事情，但我需要有系統管理員經驗的人來審查這個。

我們這樣做的原因是因為站點接縫很慢並且流量正在穩定增長。主要計劃是重寫系統，因為許多糟糕的架構決策是女傭，數據庫本身沒有正確規範化。因此，與此同時，在進行重寫的同時，我們想做一些“愚蠢的”/簡單的擴展（如果可能的話），只是為了讓客戶滿意。

我們目前的系統

• 作業系統：CentOS 5 64 位（Linux 2.6.18-238.12.1.el5）
• Web 伺服器：HP DL 320、Intel Xeon 4 核 L5520 @ 2.26GHz CPU、8GB RAM、2 x 500 GB SATA 驅動器、RAID 控制器、冗餘 PSU
• MySQL 5.0
• PHP 5.2.10
• 帶有 php_mod 的Apache 2.2.3

伺服器監控結果

我們正在執行單個伺服器，該伺服器託管 Web 應用程序和數據庫。

• 每秒平均請求數約為 1.4，峰值約為 3 RPS
• 磁碟 I/O 使用率，峰值為 25%（僅在我們執行一些後台任務時才會達到），除此之外約 2-5%
• 物理記憶體，在峰值時使用了大約 70%。

MySQL 配置

• 我們目前正在使用 InnoDB 和 MyISAM 表的混合
• 查詢記憶體已關閉
• innodb_buffer_pool_size = 8M
• innodb_flush_method = (空)
• innodb_log_file_size = 5M
• innodb_thread_concurrency = 8

我不關心 MyISAM 參數，因為我計劃將所有表都轉換為 InnoDB，這樣更容易為我調整。

我目前的計劃

1.系統監控

保持對系統弱點的監控，這樣如果性能調整成功，我們以後可以更好地了解情況。

2.分析應用監控

收集載入時間最長的頁面的資訊

3.使用清漆

據我了解，粗略地說，Varnish 會記憶體整個頁面，並充當代理，以後可以在沒有 Apache 參與的情況下為這些頁面提供服務。在我們的例子中，我們有很多不經常更改的內容，儘管要消耗大量資源來生成。

4. 使用自定義腳本進行基準測試

編寫模仿使用者行為的自定義腳本，並嘗試使用“貪婪”功能。在未訪問站點時同時執行這些腳本，並收集系統的性能資訊。在網站優化之前和之後執行此操作。雖然，這一點對我來說很有意義，但我之前還沒有真正聽說過這樣做，只是在 Rails 基準測試中看到了類似的想法，我想避免過早進行基準測試，所以我很樂意聽到一些關於這個的意見。

5. 將所有表轉換為 InnoDB

這將使所有調整過程變得更加簡單。

6. 數據庫層調整

• 打開查詢記憶體並將其設置為 256MB，然後使用以下公式不斷測量記憶體性能：Qcache_hits / Qcache_inserts x 100 = Your Query Cache's effectiveness.
• 設置query_cache_limit= 256K
• 創建一個每小時執行兩次並執行的 cron 作業：FLUSH QUERY CACHE;
• 我們正在使用 Sphinx，因此對於它的 SELECT 查詢，我還將添加SQL_NO_CACHE，儘管query_cache_limit無論如何應該防止 Sphinx 破壞記憶體。

7.物理記憶體調整

這有點棘手，因為我們只有大約 3GB 的額外記憶體可以分配給 MySQL。在我們的例子中，Innodb TableSpaces 的總大小約為 3GB。下一篇：選擇 innodb_buffer_pool_size建議innodb_buffer_pool_size應該設置為比 InnoDB TableSpaces 總大小大 10%，在我們的例子中是 3.1GB，所以我們沒有足夠的記憶體。但是，向我們的伺服器添加更多物理記憶體不是問題。

除了調整之外innodb_buffer_pool_size，還應進行以下 MySQL 參數更改：

• innodb_flush_method = O_DIRECT（避免雙重緩衝）
• innodb_log_file_size = 256M

8.頁面生成時間調整

我遇到的大多數部落格都建議使用 Nginx 和 APC（PHP 記憶體）。我已經看到了基準測試結果，與啟用了 mod_php 的 Apache 相比，它們似乎都令人印象深刻。但在我們的案例中值得注意的事實是，我們在高峰時間提供 3RPS。用 Nginx 改變 Apache 並不是一個簡單的過程，坦率地說，如果需要，我寧願找一個有經驗的系統管理員來做這件事。如果在我們的案例中值得遷移伺服器，也許有人可以提供任何建議？

考慮到我的情況，任何人都可以就這個計劃給我任何回饋嗎？

謝謝！

你的總體計劃是合理的。在接觸任何東西之前，繼續進行系統監控和頁面速度分析。在您知道問題所在之前，您無法解決問題。

一旦你知道你的瓶頸是什麼（磁碟、CPU、RAM、數據庫、WebApp），你就可以開始按照它們影響你的使用者的順序來定位它們。

---

在調整方面，您遺漏的一項具體項目是數據庫分析（EXPLAIN查詢和創建/修改索引以提高性能）。這是一個有經驗的 DBA 的工作——創建太多索引會阻塞插入，創建錯誤的索引不會提高性能。

您還應該認真考慮拆分數據庫伺服器和 Web/應用程序伺服器：兩者都有相當困難的工作，拆分它們可以避免一台主機過載。

如果我按照上面概述的方式執行您的計劃，我將按如下方式進行：

1. 監控和指標——辨識問題
2. 問題分析——數據庫分析等
3. 將表轉換為 InnoDB（並重複 1 和 2）
4. 頁面生成時間調整（並重複 1 和 2）
5. 物理記憶體調整和額外的數據庫層調整

（除非絕對必要，我不會調整這些設置，我會先諮詢有經驗的 DBA） 6. 記憶體（清漆或等效）。

我不會使用自定義腳本進行基準測試，除非您在生產中擁有開發環境或維護視窗（您不想因測試負載而削弱您的生產環境）。

引用自：https://serverfault.com/questions/364966