來自 pt-variable-advisor 的警告 max_connections - 為 DBaaS 配置什麼？
我們的虛擬機配置（託管在 Vmware 上）
# cat /proc/cpuinfo |grep "cpu cores" | awk -F: '{ num+=$2 } END{ print "cpu cores", num }' cpu cores 32 # free -h total used free shared buffers cached Mem: 62G 23G 39G 500K 349M 10G -/+ buffers/cache: 12G 50G Swap: 50G 0B 50G我從 pt-variable-advisor 收到關於以下內容的警告
max_connections：pt-variable-advisor h=localhost,u=root,p=Quule0juqu7aifohvo2Ahratit --socket /var/vcap/sys/run/mysql/mysqld.sock (...) # WARN max_connections: If the server ever really has more than a thousand threads running, then the system is likely to spend more time scheduling threads than really doing useful work. (...)為什麼？有什麼細節嗎？
my.cnf 中的配置
max_connections = 15360來自 prd db 集群的設置（MariaDB 10.1.x 和 Galera）
MariaDB [(none)]> SHOW STATUS WHERE `variable_name` = 'Threads_connected'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_connected | 718 | +-------------------+-------+ 1 row in set (0.01 sec) MariaDB [(none)]> SHOW STATUS WHERE `variable_name` = 'Max_used_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 924 | +----------------------+-------+ 1 row in set (0.02 sec)預設值為 151 以提高性能
允許的連接數由 max_connections 系統變數控制。當 MySQL 與 Apache Web 伺服器一起使用時，預設值為 151 以提高性能。（以前，預設值為 100。）如果您需要支持更多連接，則應為該變數設置更大的值。
和
MySQL 支持的最大連接數取決於給定平台上執行緒庫的質量、可用 RAM 的數量、每個連接使用多少 RAM、每個連接的工作負載以及所需的響應時間。Linux 或 Solaris 應該能夠正常支持至少 500 到 1000 個同時連接和多達 10,000 個連接
我們目前有 460 個使用者，每個使用者可以做 100 個
max_connections。這將是最大值。每個使用者和數據庫的 100個是否max_connections太高？使用現代連接池，我們可以將其設置為 20？我們應該如何配置它而不會使我們的伺服器因上下文切換而過載？一個網路應用程序是否有可能使用一個連接（每個語句都在同一個連接上）？
Threads_running和之間有區別Threads_connected。前者意味著許多查詢同時在做某事。另一個正在休眠，等待使用者（或應用程序）向伺服器提供另一個 SQL 語句。
max_connections是一個限制Threads_connected。（Max_used_connections是“高水位線”。）一個典型的繁忙系統將只有七分之一的“已連接”執行緒實際執行。並且
Threads_connected通常遠小於max_connections。（如 20 倍）但是，在糟糕的時期，太多的連接都在做一些緩慢的查詢，這會導致 MySQL 自己絆倒。吞吐量（查詢/秒）達到某個最大值，甚至可能下降；延遲飛速發展，驚慌失措的 DBA 將重新啟動機器，因為他認為機器已經崩潰，而不僅僅是被嚴重糾纏。
解決方案是找到慢查詢並找出如何加快它們的速度。或者重新設計應用程序以提高效率。或者更改架構和索引。很少獲得更大的硬體或更改可調參數。
在管理良好的 MySQL 伺服器中，我很少看到使用超過 2-3 個核心。然而，即使很少有核心處於活動狀態，也可以每秒執行數千次查詢。
在 DBaaS 中，您受制於客戶。他們中的任何一個人都可以編寫一個草率的應用程序來佔用連接、核心、I/O、網路頻寬等任何東西。
考慮將每個使用者限制為 10 個連接，除非他解釋了他需要做什麼和/或付給你更多的錢。有了額外的錢，您可以將他隔離在單獨的 VM 中。我曾經估計，在一家有 Apache 和 MySQL 的商店裡，10 個執行緒會淹沒 Apache，到 MaxChild 需要比預設值低得多。（我們的頁面很重。）如果您可以控制 Web 伺服器，請限制它們擁有的執行緒數。那就是在問題到達 MySQL 之前停止問題。
通過將每個使用者放在他自己的虛擬機中，您會消耗額外的資源，但您可以防止一個人的過度行為傷害其他人。
我敢打賭您的許多客戶都使用 WordPress？這是架構的一個性能更新檔：http: //mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta