Mysqltuner 對 my.cnf 的建議和更改

Question

在 Serverfault 上有這個問題幾天沒有運氣。

我已經在 VPS 上運行了 mysqltuner.pl，並且對有關要更改的變量的建議有很多疑問。 我確信這些是具有復雜答案的一般性問題。

我的知識不夠豐富，無法編寫查詢並針對服務器對其進行測試，但我只是想從運行五個 WordPress 站點的服務器中獲得更高的性能，每個月的頁面瀏覽量超過 200,000。

我已經通過 phpmyadmin 優化了數據庫（並定期執行此操作），但是調諧器仍然說存在碎片化的表。 因為這是 WordPress，我無法更改核心代碼中的查詢。

但是我應該增加多少像 query_cache_size 和 innodb_buffer_pool_size 這樣的變量？ 其他 innodb 變量呢？

一些建議的變量在 my.cnf 中不存在，例如 table_cache，並且在調諧器報告等中被標記。我可以將它們添加到 my.cnf 中嗎？

（為什么這個塊在 my.cnf 中重復？我可以刪除重復的嗎？）

 set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2

下面是 my.cnf 和 mysqltuner 的輸出：

my.cnf 的內容：

query-cache-type = 1
query-cache-size = 8M

set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql

old_passwords=1

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

mysqltuner 的輸出：

------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.45
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 133M (Tables: 637)
[--] Data in InnoDB tables: 10M (Tables: 344)
[--] Data in MEMORY tables: 126K (Tables: 2)
[!!] Total fragmented tables: 69

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 6h 24m 13s (2M q [22.135 qps], 116K conn, TX: 4B, RX: 530M)
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 35.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 303.7M (8% of installed RAM)
[OK] Slow queries: 0% (4/2M)
[OK] Highest usage of available connections: 53% (53/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/46.1M
[OK] Key buffer hit rate: 99.6% (749M cached / 2M reads)
[OK] Query cache efficiency: 32.2% (685K cached / 2M selects)
[!!] Query cache prunes per day: 948863
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 660K sorts)
[!!] Temporary tables created on disk: 46% (400K on disk / 869K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 24K opened)
[OK] Open file limit used: 10% (109/1K)
[OK] Table locks acquired immediately: 99% (2M immediate / 2M locks)
[!!] InnoDB data size / buffer pool: 10.6M/2.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)
    innodb_buffer_pool_size (>= 10M)

Answer 1

我會盡力在這里提供幫助。 MysqlTuner 報告暗示您在此 VPS 中有 4GB 的 RAM，因此我的建議基於此。

query_cache_size - 這是 MySQL 可用於緩存數據庫查詢結果的 RAM 量。 存儲在查詢緩存中的結果的返回速度比正常選擇要快得多，因此該變量可以顯着加快速度（比任何其他建議的更改都要快）。

究竟什么是正確的值，您需要進行一些實驗。 您目前將此設置為 8M。 如果你在這個盒子里有 4GB 的 RAM，我會從 64M 開始，增加到 128M，如果需要，然后增加到 256M。 每次更改后，將事情擱置幾天，然后再次運行 MysqlTuner 並將“查詢緩存效率”的百分比與之前的百分比進行比較。 對於主要托管 5 個 Wordpress 博客的服務器，我懷疑您會看到超過 256M 的任何改進，我不建議超過總 RAM 的八分之一。

就我個人而言，我發現 Munin（一個免費的服務器監控工具）對於關注這類事情非常方便，因為它會繪制緩存命中與其他查詢的關系圖。

tmp_table_size - 對於一些復雜的查詢（特別是那些使用 GROUP BY 或復雜排序的查詢），MySQL 需要首先創建一個包含數據的臨時表，然后對其運行一些操作以創建結果集。 它將嘗試在內存中創建這些臨時表，因為這比在磁盤上創建它們快得多； 但對於大型結果集，這並不總是可能的。 tmp_table_size 控制此閾值。

我無法想象 Wordpress 正在執行任何非常復雜的查詢，所以我不會對這個查詢過分。 MysqlTuner 建議的值大於 32MB，所以從 64M 開始，看看這會如何影響幾天后“在磁盤上創建的臨時表”值。 按照它的建議設置 max_heap_table_size 。

thread_cache_size - Wordpress 默認不使用持久連接（這很好），因此每個請求都會與您的數據庫建立新連接，然后在生成頁面后關閉它。 這個開銷並不大，但使用 thread_cache_size 允許 MySQL 重用這些連接線程，這將有所幫助。

我會選擇 4 的建議值，除非您獲得大量並發用戶，否則我認為這會很好。

table_cache - 我對這個有點模糊，它似乎與 MySQL 的表結構緩存有關。 為此，我會選擇 128。

innodb_buffer_pool_size - 這是 MySQL 可用於緩存 InnoDB 表的索引和數據的內存量。 這個讓我有點困惑，因為我認為 Wordpress 根本不使用 InnoDB - 你在這台服務器上還有其他網站嗎？

為了回答您的其他問題， [mysqld_safe]之后的配置僅適用於安全模式下的 MySQL 守護進程，而不適用於整個 MySQL，因此這就是為什么某些變量會重復的原因。 如果您確實更改了 innodb_buffer_pool_size，您將需要更改第一個。 您可以添加不在文件中的變量，是的，但出於同樣的原因，將它們添加到 [mysqld_safe] 塊上方。

最后，由於您有優化的心情，如果您還沒有使用像APC這樣的 PHP 字節碼緩存，那么這值得探索。 APC 可以顯着提高 PHP 應用程序的速度，而不會產生任何負面影響。

Answer 2

有更多工具可以調整您的 mysql 數據庫： http : //www.day32.com/MySQL/和http://www.maatkit.org/doc/和http://hackmysql.com/mysqlsla

在大多數情況下，您不需要編寫查詢並針對服務器對其進行測試。 只需啟用慢查詢日志來識別你的慢查詢，用 mysqlsla 聚合它們並用 maatkit 解釋它們：

您可以將 mysqla 結果中最慢的查詢粘貼到文本文件中，然后使用 maatkit 執行它們。

mk-visual-explain –host hostname –user username –password passwort –database \
databasename -c query1.sql >> query1_data.txt

——

mk-query-profiler –host hostname –user username –password passwort –database \
databasename query1_data.txt >> query1_data.txt

通常，更新較新的 mysql 版本對性能至關重要。 當您比較例如 mysql 5.0.23 和 5.1.4 時，我發現復雜查詢的執行計划非常不同。 使用 5.1.4，它們在我們的環境中執行得更快。

在http://www.mysqlperformanceblog.com/和“高性能 MySQL”一書中可以找到許多關於 mysql 的有用信息。

Tabe Cache：根據書“表緩存存儲表示表的對象。緩存中的每個對象都包含關聯表的解析.frm文件以及其他數據，具體取決於表的存儲引擎。

表緩存的設計有點以 MyISAM 為中心 - 由於歷史原因，這是服務器和存儲引擎之間的分離不完全干凈的區域之一。 表緩存對於 InnoDB 不太重要，因為 InnoDB 不依賴它用於許多目的（例如保存文件描述符；為此目的它有自己的表緩存版本）。 然而，即使是 InnoDB 也能從緩存解析的 .frm 文件中受益。”。

如果您提高表緩存，則打開文件限制可能會出錯。 您還需要增加服務器上的 open_files_limit 變量以及操作系統打開文件限制： http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ 。

線程緩存：

線程緩存保存當前未與連接關聯但已准備好為新連接提供服務的線程。 只要 MySQL 在緩存中有空閑線程，它就可以非常快速地響應連接請求，因為它不必為每個連接創建一個新線程。

[!!] 在磁盤上創建的臨時表：46%（磁盤上 400K / 總共 869K）如果尚未設置 tmp_table_size 和max_heap_table_size ，請增加它們。 與 RAM 操作相比，磁盤操作非常慢。 wordpress 是否使用大量 blob/text 列？ 那么您將看不到太多好處，因為內存表中不允許使用 BLOB 和 Text 列。

[OK] 可用連接的最高使用率：53% (53/100)為了節省 RAM，您可以減少允許的最大連接數。 另一方面，您可能會在高峰時間用完連接。

為 PHP 使用操作碼緩存是一個非常好的主意！

Answer 3

我為 WP 調整 MySQL 的建議：

應定期優化數據庫表（並在必要時進行修復）以獲得最佳性能。

我建議使用WP-DBManager插件，它提供此功能以及數據庫備份，對於任何博客安裝都至關重要。

WP-DBManager 允許您安排和忘記，它會自動處理所有工作。

其他替代方法是通過phpmyadmin 之類的工具手動優化和修復您的表。

MySQL Query Cache 保存查詢的結果，以防再次出現查詢。 但是，它只知道如何保存查詢的字節文本，而不知道它們的編譯版本，因此對查詢的微小更改將創建不同的緩存條目。 如果您在每個查詢中都沒有唯一的 ID，請啟用此功能。 您可以通過將以下內容添加到 /etc/my.cnf 來啟用它：

query_cache_type = 1
query_cache_size = 26214400

Answer 4

這不是一個直接回答你的問題，但以我的經驗的WordPress可以通過前端服務器上高速緩存可以很好的優化。 此外，大多數 wordpress 似乎在前端機器上受 CPU 限制，而不是在數據庫上。 （您可能需要仔細檢查您是否確實在優化瓶頸）。

例如，看看“w3 total cache”。 將它與 APC 一起使用應該是最簡單的方法。 確保您查看了 apc.shm_size 的大小（在 php.ini 中）和緩存命中率（w3tc 應提供一些 apc 信息實用程序）。

我已經看到 wordpress 實例在具有這種設置的單個服務器上順利運行，並且每月的頁面瀏覽量超過 200.000。

Answer 5

這應該比試圖改變my.cnf更容易