專用伺服器上大型 Magento 站點的最佳 MySQL my.cnf 設置
我們的專用伺服器正在執行一個大型 Magento 儲存，其中包含一個大小約為 250MB 的 MySQL 數據庫。
伺服器規格被列為具有 5 個 Xeon 2Ghz 處理器（4MB 記憶體）和 12GB 記憶體。
我原以為上述規範足以非常快速地執行 Magento，但是儘管該站點並不慢，但它確實沒有應有的速度。
目前 MySQL my.cnf 文件如下：
skip-innodb ft_min_word_len=3 query_cache_limit = 4M query_cache_size = 16M ## 32MB for every 1GB of RAM query_cache_type = 1 max_user_connections = 50 max_connections = 50 interactive_timeout = 300 wait_timeout = 200 connect_timeout = 200 thread_cache_size = 32 key_buffer_size = 64M ## 128MB for every 1GB of RAM join_buffer_size = 1M max_connect_errors = 20 max_allowed_packet = 12M table_cache = 1024 record_buffer = 1M sort_buffer_size = 1M ## 1MB for every 1GB of RAM read_buffer_size = 1M ## 1MB for every 1GB of RAM read_rnd_buffer_size = 1M ## 1MB for every 1GB of RAM thread_concurrency = 4 ## Number of CPUs x 2 myisam_sort_buffer_size = 32M tmp_table_size = 16M max_heap_table_size = 12M [safe_mysqld] open_files_limit = 2048 [mysqldump] quick max_allowed_packet = 12M我已經看到了一個建議的 my.cnf 用於 magento 專用數據庫伺服器（2GB ram）：
query_cache_size = 512M
query_cache_limit = 256M
tmp_table_size = 256M
key_buffer_size = 64M
讀取緩衝區大小 = 128M
read_rnd_buffer_size = 128M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 128M
myisam_max_extra_sort_file_size = 128M
myisam_repair_threads = 2
myisam_recover
innodb_additional_mem_pool_size = 256M
innodb_log_buffer_size = 128M
innodb_log_file_size = 128M
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 512M
innodb_data_home_dir = /var/lib/mysql/
innodb_data_file_path = ibdata1:256M:autoextend
innodb_autoextend_increment=32
我想知道是否有人可以根據我們的規范建議 my.cnf 參數的最佳值？
此外，如果在修補它們時有什麼我應該注意的，例如：將其設置得太高並預計會發生災難性的失敗。
任何想法將不勝感激。乾杯。
當您為單個使用者進行性能測試時，MySQL 通常是 Magento 儲存的**最後一個瓶頸。**儘管如此，
my.cnf對於 Magento 商店和伺服器規範而言，您看起來都不是最佳選擇。我在這里為 Magento 寫了一個關於 MySQL 負載的詳細答案，https://serverfault.com/a/367856/113375
目前，您最好的努力是通過其他方式（更改主機/優化模板等）專注於改善頁面載入時間並最後解決數據庫；這實際上只對並發測試和事務負載起作用。
來自 http://docs.sonassihosting.com/go_dedicated.pdf
根據您的 CPU 架構和匯流排速度 - 使用下圖，您可以實現的最佳 PHP 頁面渲染時間是 0.8 秒（不包括圖像/js/css）。
讓您大致了解要選擇的硬體
選擇伺服器時需要牢記兩個數字，並發性和頁面載入時間。並發是您的伺服器可以隨時支持的客戶數量。單個頁面載入時間是單個客戶的頁面實際載入速度。
有可能有：
- 緩慢的頁面載入時間和低並發支持（低時鐘速度 CPU (GHz)，少數核心）
- 頁面載入時間快，但並發支持低（高時鐘速度 CPU (GHz)，核心少）
- 頁面載入時間慢，但支持高並發（低時鐘速度 CPU (GHz)，大量核心）
- 快速的頁面載入時間和高並發支持（高時鐘速度 CPU (GHz)，大量核心）
您可以根據此選擇硬體。
並發
a) 一個標準的 Magento 展示商店能夠在每個 GHz 每小時提供大約 230 個唯一身份。
b) 具有管理員使用者活動、開發活動、產品添加/刪除的典型網路商店可以看到這會降低約 100%，至每小時每 GHz 115 個唯一使用者。
c) 具有不良建構/繁重模板的商店可以將數字進一步減少 100-200%，至每小時每 GHz 50 個唯一身份。
當我們引用數字時，我們使用選項 b)。
單個頁面載入時間
一個標準的 Magento 展示商店（CE 或 EE——當 FPC 被禁用時）能夠將首頁載入到：
0.7 seconds 2.4GHz CPU 0.6 seconds 2.8GHz CPU 0.51 seconds 3.3GHz CPU 0.48 seconds 3.46GHz CPU但同樣，一個糟糕的建構/沉重的模板將導致這個數字成倍增加。當我們引用數字時，我們使用帶有範例數據的展示商店模板作為範例。
以上來源摘自http://docs.sonassihosting.com/go_dedicated.pdf
我假設你有 5 個 CPU——你正在使用 VPS（雲或其他），如果是這樣，I/O 可能是你的瓶頸，無論是磁碟還是網路。不幸的是，由於 VPS 的競爭性質 - 它們從來都不是 Magento 託管的理想選擇 - 除非管理它的個人/公司對 Magento 優化有非常深入的了解並且硬體沒有競爭。
Magento VPS 的缺點
**每個使用者都有 root 訪問權限。**這意味著您系統上的其他 VPS 節點可能會啟動 bonnie/iperf/hping 並隨後破壞無法分區/拆分的資源 - HDD I/O、網路或中斷。因此，即使您保證了 CPU/RAM - 您也受制於共享子系統。
您的 CPU 和 RAM 有限。是的，您可以擴大/縮小規模 - 但歸根結底，小型 Magento 儲存受益於僅分配給 MySQL 實例的至少 2GB RAM，以及 1GB RAM/邏輯 CPU 核心的經驗法則。所以至少，一個 VPS 應該有 3GB RAM 和 1 個 CPU 核心*——*假設沒有 HDD I/O 或網路 I/O 瓶頸。
**你必須自己管理它。**奇怪的是，如今電子商務網站的所有者和運營商也應該負責設置、監控和管理他們的託管基礎設施。店主應該專注於他們擅長的事情——經營他們的業務，而不是試圖解決錯誤、調整性能或管理命令行 Linux 伺服器。最壞的情況是，當他們根本沒有經驗處理的問題出現問題時，會導致盲目恐慌。
為了獲得更好/更準確的答案，請發布有關您商店的更多詳細資訊-
- 每日獨立訪客的水平是多少？
- 每個訪問者的頁面瀏覽量？
- 遊客主要來自哪個國家？
- 您是否預計未來 12 個月的網站流量會增長，如果是，增長多少？
- 您的網站是否提供數字下載？
- 商店瀏覽次數？
- 目錄中的產品數量？
- 目錄中的類別數？
- 目錄中的屬性數量？
- 目錄中的屬性集數量？
- 目前磁碟空間使用情況？
- 目前頻寬使用情況？
- 每天的交易量？