為 32GB 混合 nginx/php/mysql 伺服器優化 Percona 5.7 my.cnf
我有一個專門的伺服器來執行我的網站。它有 32GB 的記憶體，Xeon E5-1650 3.2Ghz（6 核，12 帶 HT）和 RAID 1 中的兩個 3TB 驅動器。
我正在執行 Percona 5.7.18
我 99% 的表都是 InnoDB
我的 ibdata1 文件是 500MB。
它主要是 SELECT 查詢，但也有一些非常複雜的連接/查詢。不過也有一定比例的 INSERT/UPDATE。
伺服器會花費一些時間來調整使用者上傳的 JPEG 文件的大小，因此在分配記憶體等時我需要注意這一點。
還有什麼我可以告訴你的對你有幫助的嗎？
我確實計劃在某個時候實現一些不錯的 webapp 級記憶體，但同時希望改進 mysql 配置。
該網站在正常流量的日子裡執行得很好，但在繁忙的日子裡可能會有點掙扎（比如今天……）
我是一個單獨的開發者，所以全棧並且分散得很薄，並且會很高興地承認我的 DBA 技能相當差。我可以寫一個像樣的查詢，但我對伺服器設置一無所知。多年來，我的 my.cnf 中的內容是從各種不同的來源拼湊而成的，我猜它遠非最佳！
[client] default-character-set = utf8mb4 [mysql] default-character-set = utf8mb4 [mysqld] user = mysql default-storage-engine = InnoDB socket = /var/lib/mysql/mysql.sock pid-file = /var/run/mysqld/mysqld.pid datadir = /var/lib/mysql skip-name-resolve max-allowed-packet = 16M max-connect-errors = 1000000 # is this a silly thing to do..? tmpdir = /dev/shm # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links = 0 character-set-client-handshake = FALSE character_set_server = utf8mb4 collation_server = utf8mb4_unicode_ci ft_min_word_len = 2 group_concat_max_len = 4096 max_connections = 500 tmp-table-size = 32M max-heap-table-size = 32M thread-cache-size = 50 open-files-limit = 65535 table-definition-cache = 1024 table-open-cache = 2048 join_buffer_size = 2M sort_buffer_size = 2M read_rnd_buffer_size = 2M slow-query-log = 1 long-query-time = 1 slow-query-log-file = /var/lib/mysql/slow_log log-error = /var/lib/mysql/mysite.err max_allowed_packet = 256M query_cache_size = 268435456 query_cache_limit = 1048576 query_cache_type = 1 innodb_buffer_pool_size = 12G innodb_buffer_pool_instances = 12 innodb_read_io_threads = 12 innodb_write_io_threads = 12 thread_pool_size = 24 sql_mode = "" [mysqld_safe] log-error=/var/lib/mysql/mysite.err pid-file=/var/run/mysqld/mysqld.pid任何幫助/指導將不勝感激，我喜歡學習，更重要的是我需要學習！
謝謝！
32GB RAM，12G buffer_pool –> 為調整圖像大小留下了很多空間。
12G buffer_pool、0.5GB ibdata1 和 5.7 –>
innodb_file_per_table可能是ON. 是嗎？如果是這樣，您還沒有向我們提供有關您擁有多少數據的線索。查看.ibd文件。
query_cache_size = 256M可能是壞的。 對錶的任何寫入都會導致清除該表的所有QC 條目。清除與 QC 的大小成正比。保持在50M以下。（或將其關閉。）經驗法則：“不要將記憶體放在記憶體前面。” MySQL 在內部做了很多記憶體；添加 webapp 級別的記憶體可能無濟於事，並且可能會從 buffer_pool 中搶走 RAM，這很重要。
你知道你是否受 I/O 限制嗎？受 CPU 限制？
我看到你有慢登錄。使用 pt-query-digest 進行總結。然後，讓我們討論最糟糕的幾個查詢。 修復慢查詢比任何調整更有可能提升您的性能。
但是，如果您想要更多的調整建議，讓我們看看
GLOBAL STATUS. 特別是，請按照此處的說明進行操作。