確定 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_length
Thread_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
- 延遲差(查詢“太長”)——參見其他兩項。