確定 MariaDB 的理論最大連接數
我想升級我們的 MariaDB 伺服器的記憶體
(10.1.25-MariaDB-1~xenial)來處理更多的連接。我一直在確定最大連接數，主要是根據這篇文章建議使用這個公式
(Available_RAM - Global_buffers) / Thread_buffers
Global_buffers 它是這些變數的總和。
key_buffer_size innodb_buffer_pool_size innodb_log_buffer_size innodb_additional_mem_pool net_buffer_lengthThread_buffers 是這些變數的總和。
sort_buffer_size myisam_sort_buffer_size read_buffer_size join_buffer_size read_rnd_buffer_size這似乎有效，對我來說它給出了大約。15 個連接作為我的理論最大值。
當我查詢
SHOW STATUS LIKE 'max_used_connections'時，據我所知，這給了我歷史maximum connections請求，我得到46 個連接。對於背景，當我執行時，
SHOW VARIABLES LIKE 'max_connections'我得到151，我相信這是預設設置值。15 個連接實際上是我的理論最大值嗎？額外的31 個連接是否失敗但 MySQL 註冊了它們？
我的數學是錯的還是我更可能遺漏了一些變數？
我發現的每個公式在某些方面都是錯誤的。我遇到的幾乎每台電腦都有“過度使用”的 RAM；也就是說，公式會說可能會使用過多的 RAM。
他們的列表缺少兩個重要設置：
max_heap_table_size和tmp_table_size. 這兩個中的最小值用於 complex 中的內部臨時表SELECTs。 單個查詢中可能有多種用途！ 我建議將每個限制為 1% 的 RAM。總體…
- 將大多數 VARIABLES 保留為預設值。
- 上面提到的1%
- 使用 InnoDB，而不是 MyISAM。
- 設置
key_buffer_size為僅 20M。innodb_buffer_pool_size如果您有超過 4GB 的 RAM，請設置為大約 70% 的可用 RAM。（小型機器的百分比較低。）如果發生交換，這是首先要解決的問題。- 當您發現問題（交換、高 cpu、高 I/O 等）時，尋求幫助。它通常會通過更好的索引和/或重新構造查詢來解決，而不是通過調整來解決。
忽略您的問題所提出的公式。
至於“連接太多”，主要有兩個原因*，調整 MySQL/MariaDB 不是萬能的*。
- 查詢執行如此緩慢，以至於需要幫助——調整查詢是這裡的一種解決方案。
- 客戶端正在淹沒數據庫。一些 Web 伺服器認為它們可以有效地執行數百或數千個執行緒。但是，實際上，他們絆倒了自己並導致數據庫也絆倒了自己。限制他們。
在最後一個項目中，想想一家雜貨店，那裡有很多購物者，他們甚至無法將購物車推到下一個過道，更不用說完成了。
換句話說，如果你讓太多的連接進入，吞吐量會停滯（達到某個限制）並且延遲會受到嚴重影響。
需要注意的事項：
- 交換意味著事情調得太高了——上面討論過
- 100% CPU 或 I/O —— 精細並修復查詢。尋求幫助：http: //mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
- 延遲差（查詢“太長”）——參見其他兩項。