Mysql連接數設置和獲取的方法
獲取連接數
--- 獲取最大連接數 SHOW VARIABLES LIKE '%max_connections%'; --- 獲取連接列表 SHOW PROCESSLIST; --- 獲取連接列表 SHOW FULL PROCESSLIST; --- 獲取當前的鏈接信息 Threads_connected是當前的連接數 SHOW STATUS LIKE 'Threads%'; --- 獲取連接統計 比如歷史最大連接數以及最大連接時長等 SHOW STATUS LIKE '%Connection%';
mysql> SHOW STATUS LIKE 'Threads%'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_cached | 58 | | Threads_connected | 57 | ---這個數值指的是打開的連接數 | Threads_created | 3676 | | Threads_running | 4 | ---這個數值指的是激活的連接數,這個數值一般遠低於connected數值 +-------------------+-------+
Threads_connected 跟show processlist結果相同,表示當前連接數。準確的來說,Threads_running是代表當前並發數
設置連接數
臨時設置
mysql>show variables like 'max_connections'; --- 查可以看當前的最大連接數 msyql>set global max_connections=1000; --- 設置最大連接數為1000,可以再次查看是否設置成功 mysql>exit --- 退出
永久設置
可以在/etc/my.cnf裡面設置數據庫的最大連接數
[mysqld] max_connections = 1000
項目中連接池設置
下面公式由 PostgreSQL 提供,不過底層原理是不變的,它適用於市面上絕大部分數據庫產品。還有,你應該模擬預期的訪問量,並通過下面的公式先設置一個偏合理的值,然後在實際的測試中,通過微調,來尋找最合適的連接數大小。
連接數 = ((核心數 * 2) + 有效磁盤數)
核心數不應包含超線程(hyper thread),即使打開瞭超線程也是如此,如果熱點數據全被緩存瞭,那麼有效磁盤數實際是0,隨著緩存命中率的下降,有效磁盤數也逐漸趨近於實際的磁盤數。另外需要註意,這一公式作用於SSD 的效果如何,尚未明瞭。
好瞭,按照這個公式,如果說你的服務器 CPU 是 4核 i7 的,連接池大小應該為 ((4*2)+1)=9。
取個整, 我們就設置為 10 吧。你這個行不行啊?10 也太小瞭吧!
你要是覺得不太行的話,可以跑個性能測試看看,我們可以保證,它能輕松支撐 3000 用戶以 6000 TPS 的速率並發執行簡單查詢的場景。你還可以將連接池大小超過 10,那時,你會看到響應時長開始增加,TPS 開始下降。
你需要的是一個小連接池,和一個等待連接的線程隊列
假設說你有 10000 個並發訪問,而你設置瞭連接池大小為 10000,你怕是石樂志哦。
改成 1000,太高?改成 100?還是太多瞭。
你僅僅需要一個大小為 10 數據庫連接池,然後讓剩下的業務線程都在隊列裡等待就可以瞭。
連接池中的連接數量大小應該設置成:數據庫能夠有效同時進行的查詢任務數(通常情況下來說不會高於 2*CPU核心數)。
你應該經常會看到一些用戶量不是很大的 web 應用中,為應付大約十來個的並發,卻將數據庫連接池設置成 100, 200 的情況。請不要過度配置您的數據庫連接池的大小。
是不是越大約好
模擬 9600 個並發線程來操作數據庫,每兩次數據庫操作之間 sleep 550ms,註意,視頻中剛開始設置的線程池大小為 2048。
讓我們來看看數據庫連接池的大小為 2048 性能測試結果的鬼樣子:
每個請求要在連接池隊列裡等待 33ms,獲得連接之後,執行SQL需要耗時77ms, CPU 消耗維持在 95% 左右;
接下來,我們將連接池的大小改小點,設置成 1024,其他測試參數不變,結果咋樣?
“這裡,獲取連接等待時長基本不變,但是 SQL 的執行耗時降低瞭!”
哎呦,有長進哦!
接下來,我們再設置小些,連接池的大小降低到 96,並發數等其他參數不變,看看結果如何:
每個請求在連接池隊列中的平均等待時間為 1ms, SQL 執行耗時為 2ms.
我去!什麼鬼?
我們沒調整任何東西,僅僅隻是將數據庫連接池的大小降低瞭,這樣,就能把之前平均 100ms 響應時間縮短到瞭 3ms。吞吐量指數級上升啊!
你這也太溜瞭!
為啥有這種效果?
我們不妨想一下,為啥 Nginx 內部僅僅使用瞭 4 個線程,其性能就大大超越瞭 100 個進程的 Apache HTTPD 呢?追究其原因的話,回想一下計算機科學的基礎知識,答案其實非常明顯。
要知道,即使是單核 CPU 的計算機也能“同時”運行著數百個線程。但我們其實都知道,這隻不過是操作系統快速切換時間片,跟我們玩的一個小把戲罷瞭。
一核 CPU同一時刻隻能執行一個線程,然後操作系統切換上下文,CPU 核心快速調度,執行另一個線程的代碼,不停反復,給我們造成瞭所有進程同時運行假象。
其實,在一核 CPU 的機器上,順序執行A和B永遠比通過時間分片切換“同時”執行A和B要快,其中原因,學過操作系統這門課程的童鞋應該很清楚。一旦線程的數量超過瞭 CPU 核心的數量,再增加線程數系統就隻會更慢,而不是更快,因為這裡涉及到上下文切換耗費的額外的性能。
說到這裡,應該恍然大悟瞭 ……
以上就是Mysql連接數設置和獲取的方法的詳細內容,更多關於Mysql連接數設置和獲取的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- MySQL 8.0新特性 — 管理端口的使用簡介
- MySQL正確修改最大連接數的3種方案
- MySQL查看數據庫狀態命令詳細講解
- mysql如何實現最大連接數
- 快速通過zabbix獲取數據庫連接的信息及部分擴展