因此，當我的網站看到大量傳入流量時，我經常會遇到托管 MySQL 資料庫的服務器的性能問題。
我剛剛在 mysqltuner 結果中看到了這一點：
Total buffers: 4.1G global 1.0G per thread (500 max threads)
[!!] Maximum reached memory usage: 188.4G (299.43% of installed RAM)
[!!] Maximum possible memory usage: 2002.3G (3182.59% of installed RAM)
我是如何設法為每個執行緒保留 1G 的？更重要的是：我如何降低它？1G似乎高得離譜。
mysqltuner 總結果：https ://pastebin.com/s0rc42VJ
uj5u.com熱心網友回復：
這不是真正的問題。索引不足和/或查詢撰寫不當會導致性能問題。
不過，這里有一些改變：
max_connections = 200
innodb_buffer_pool_size = 3G
全球狀況和變數分析：
觀察：
- 版本：5.7.34-0ubuntu0.18.04.1-log
- 62.9 GB 記憶體
- 正常運行時間 = 1 天 19:27:48
- 171 次查詢/秒：60.2 次查詢/秒
更重要的問題：
有比 MySQL 需要更多的 RAM。
innodb_log_file_size非常小（看起來像一個非常古老的默認值）。該值目前似乎不是問題。但是，如果您要向某個表添加 1MB BLOB 列，這是不夠的。
細節和其他觀察：
( innodb_buffer_pool_size ) = 4,096 / 67538360729.6 = 6.4%-- 用于 InnoDB buffer_pool 的 RAM 百分比 -- 設定為可用 RAM 的大約 70%。（低效率較低；過高風險交換。）
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- 頁面清理器每秒的作業量。-- "InnoDB: page_cleaner: 1000ms 預期回圈花費..." 可以通過降低 lru_scan_depth 來解決：考慮 1000 / innodb_page_cleaners（現在是 4）。還要檢查交換。
( innodb_lru_scan_depth ) = 1,024
-- "InnoDB: page_cleaner: 1000ms 預期回圈花費..." 可以通過降低 lru_scan_depth 來修復
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 147,347 / 262112 = 56.2% -- 當前未使用的 buffer_pool 的百分比 -- innodb_buffer_pool_size（現在為 4294967296）是否大于必要？
( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10-- 容量：max/plain -- 推薦 2。Max 應該大約等于您的 I/O 子系統可以處理的 IOP。（如果驅動器型別未知，2000/200 可能是合理的一對。）
( innodb_log_buffer_size / innodb_log_file_size ) = 16M / 16M = 100.0%-- 緩沖區在 RAM 中；檔案在磁盤上。-- buffer_size 應該更小和/或 file_size 應該更大。
( innodb_flush_method ) = innodb_flush_method = -- InnoDB 應該如何要求作業系統寫入塊。建議使用 O_DIRECT 或 O_ALL_DIRECT (Percona) 以避免雙緩沖。（至少對于 Unix。）請參閱 chrischandler 有關 O_ALL_DIRECT 的警告
( innodb_flush_neighbors ) = 1-- 將塊寫入磁盤時的小優化。-- SSD 驅動器使用 0；1 個用于硬碟。
( innodb_io_capacity ) = 200- 每秒能夠在磁盤上執行的 I/O 運算元。100 用于慢速驅動器；200 用于旋轉驅動器；SSD 1000-2000；乘以 RAID 系數。
( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = ON-- 通常應該打開。-- 在某些情況下，OFF 更好。另見 innodb_adaptive_hash_index_parts（現在是 8）（5.7.9 之后）和 innodb_adaptive_hash_index_partitions（MariaDB 和 Percona）。ON 與罕見的崩潰有關（錯誤 73890）。10.5.0 決定默認關閉。
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- Whether to log all Deadlocks.
-- If you are plagued with Deadlocks, turn this on. Caution: If you have lots of deadlocks, this may write a lot to disk.
( character_set_server ) = character_set_server = latin1
-- Charset problems may be helped by setting character_set_server (now latin1) to utf8mb4. That is the future default.
( local_infile ) = local_infile = ON
-- local_infile (now ON) = ON is a potential security issue
( bulk_insert_buffer_size ) = 8M / 67538360729.6 = 0.01% -- Buffer for multi-row INSERTs and LOAD DATA
-- Too big could threaten RAM size. Too small could hinder such operations.
( Handler_read_rnd_next / Com_select ) = 129,974,931,182 / 7494188 = 17,343 -- Avg rows scanned per SELECT. (approx)
-- Consider raising read_buffer_size (now 131072)
( Com__biggest ) = Com__biggest = Com_stmt_prepare -- Which of the "Com_" metrics is biggest.
-- Normally it is Com_select (now 7494188). If something else, then it may be a sloppy platform, or may be something else.
( log_slow_slave_statements ) = log_slow_slave_statements = OFF-- (5.6.11, 5.7.1) 默認情況下，slowlog 中不會出現復制陳述句；這導致他們顯示。-- 在慢日志中查看可能干擾副本讀取的寫入會很有幫助。
( Max_used_connections / max_connections ) = 34 / 500 = 6.8% -- 連接的峰值百分比 -- 由于幾個記憶體因素可以根據 max_connections（現在為 500）進行擴展，因此最好不要將該設定設定得太高。
您有一半的查詢快取。您應該同時設定 query_cache_type = OFF 和 query_cache_size = 0 。QC 代碼中存在（根據謠言）一個“錯誤”，除非您關閉這兩個設定，否則會留下一些代碼。
例外大：
Com_stmt_close = 55 /sec
Com_stmt_execute = 55 /sec
Com_stmt_prepare = 55 /sec
Handler_read_rnd = 10182 /sec
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests Innodb_buffer_pool_reads ) = 100.0%
Innodb_log_writes / Innodb_log_write_requests = 157.1%
Innodb_rows_deleted Innodb_rows_inserted = 703 /sec
Innodb_rows_inserted = 703 /sec
Innodb_rows_read = 1040676 /sec
Ssl_accepts = 379,681
Ssl_finished_accepts = 379,681
Ssl_session_cache_misses = 379,428
Ssl_used_session_cache_entries = 85
max_user_connections = 500
例外字串：
innodb_fast_shutdown = 1
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
require_secure_transport = ON
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
uj5u.com熱心網友回復：
每秒速率 = RPS
為您的 my.cnf [mysqld] 部分考慮的建議
read_rnd_buffer_size=64K # from 256K to reduce handler_read_rnd_next RPS of 830,686
innodb_lru_scan_depth=100 # from 1024 to reduce 90% of CPU cycles used for function, every second.
connect_timeout=20 # from 10 seconds to reduce aborted_connects of 49 RPhr
net_buffer_length=96K # from 16K to reduce packet sent count
innodb_write_io_threads=64 # from 4 because of your reads to writes ratio of about 30.
查看個人資料以獲取聯系資訊和可免費下載的實用程式腳本，以幫助進行性能調整。
發布慢查詢日志的最后 400 行將允許建議適當的索引創建以將 select_scan RPS 降低 6。
innodb_buffer_pool_size 需要考慮您今天報告的 1.9G 資料。70% 的 RAM 將被過度分配且不必要。你會發現4G服務很好。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/337379.html