Mysql連接數(shù)設(shè)置和獲取的方法
獲取連接數(shù)
--- 獲取最大連接數(shù) SHOW VARIABLES LIKE '%max_connections%'; --- 獲取連接列表 SHOW PROCESSLIST; --- 獲取連接列表 SHOW FULL PROCESSLIST; --- 獲取當(dāng)前的鏈接信息 Threads_connected是當(dāng)前的連接數(shù) SHOW STATUS LIKE 'Threads%'; --- 獲取連接統(tǒng)計(jì) 比如歷史最大連接數(shù)以及最大連接時(shí)長(zhǎng)等 SHOW STATUS LIKE '%Connection%';
mysql> SHOW STATUS LIKE 'Threads%'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_cached | 58 | | Threads_connected | 57 | ---這個(gè)數(shù)值指的是打開(kāi)的連接數(shù) | Threads_created | 3676 | | Threads_running | 4 | ---這個(gè)數(shù)值指的是激活的連接數(shù),這個(gè)數(shù)值一般遠(yuǎn)低于connected數(shù)值 +-------------------+-------+
Threads_connected 跟show processlist結(jié)果相同,表示當(dāng)前連接數(shù)。準(zhǔn)確的來(lái)說(shuō),Threads_running是代表當(dāng)前并發(fā)數(shù)
設(shè)置連接數(shù)
臨時(shí)設(shè)置
mysql>show variables like 'max_connections'; --- 查可以看當(dāng)前的最大連接數(shù) msyql>set global max_connections=1000; --- 設(shè)置最大連接數(shù)為1000,可以再次查看是否設(shè)置成功 mysql>exit --- 退出
永久設(shè)置
可以在/etc/my.cnf里面設(shè)置數(shù)據(jù)庫(kù)的最大連接數(shù)
[mysqld] max_connections = 1000
項(xiàng)目中連接池設(shè)置
下面公式由 PostgreSQL 提供,不過(guò)底層原理是不變的,它適用于市面上絕大部分?jǐn)?shù)據(jù)庫(kù)產(chǎn)品。還有,你應(yīng)該模擬預(yù)期的訪問(wèn)量,并通過(guò)下面的公式先設(shè)置一個(gè)偏合理的值,然后在實(shí)際的測(cè)試中,通過(guò)微調(diào),來(lái)尋找最合適的連接數(shù)大小。
連接數(shù) = ((核心數(shù) * 2) + 有效磁盤(pán)數(shù))
核心數(shù)不應(yīng)包含超線程(hyper thread),即使打開(kāi)了超線程也是如此,如果熱點(diǎn)數(shù)據(jù)全被緩存了,那么有效磁盤(pán)數(shù)實(shí)際是0,隨著緩存命中率的下降,有效磁盤(pán)數(shù)也逐漸趨近于實(shí)際的磁盤(pán)數(shù)。另外需要注意,這一公式作用于SSD 的效果如何,尚未明了。
好了,按照這個(gè)公式,如果說(shuō)你的服務(wù)器 CPU 是 4核 i7 的,連接池大小應(yīng)該為 ((4*2)+1)=9。
取個(gè)整, 我們就設(shè)置為 10 吧。你這個(gè)行不行???10 也太小了吧!
你要是覺(jué)得不太行的話,可以跑個(gè)性能測(cè)試看看,我們可以保證,它能輕松支撐 3000 用戶以 6000 TPS 的速率并發(fā)執(zhí)行簡(jiǎn)單查詢的場(chǎng)景。你還可以將連接池大小超過(guò) 10,那時(shí),你會(huì)看到響應(yīng)時(shí)長(zhǎng)開(kāi)始增加,TPS 開(kāi)始下降。
你需要的是一個(gè)小連接池,和一個(gè)等待連接的線程隊(duì)列
假設(shè)說(shuō)你有 10000 個(gè)并發(fā)訪問(wèn),而你設(shè)置了連接池大小為 10000,你怕是石樂(lè)志哦。
改成 1000,太高?改成 100?還是太多了。
你僅僅需要一個(gè)大小為 10 數(shù)據(jù)庫(kù)連接池,然后讓剩下的業(yè)務(wù)線程都在隊(duì)列里等待就可以了。
連接池中的連接數(shù)量大小應(yīng)該設(shè)置成:數(shù)據(jù)庫(kù)能夠有效同時(shí)進(jìn)行的查詢?nèi)蝿?wù)數(shù)(通常情況下來(lái)說(shuō)不會(huì)高于 2*CPU核心數(shù))。
你應(yīng)該經(jīng)常會(huì)看到一些用戶量不是很大的 web 應(yīng)用中,為應(yīng)付大約十來(lái)個(gè)的并發(fā),卻將數(shù)據(jù)庫(kù)連接池設(shè)置成 100, 200 的情況。請(qǐng)不要過(guò)度配置您的數(shù)據(jù)庫(kù)連接池的大小。
是不是越大約好
模擬 9600 個(gè)并發(fā)線程來(lái)操作數(shù)據(jù)庫(kù),每?jī)纱螖?shù)據(jù)庫(kù)操作之間 sleep 550ms,注意,視頻中剛開(kāi)始設(shè)置的線程池大小為 2048。
讓我們來(lái)看看數(shù)據(jù)庫(kù)連接池的大小為 2048 性能測(cè)試結(jié)果的鬼樣子:
每個(gè)請(qǐng)求要在連接池隊(duì)列里等待 33ms,獲得連接之后,執(zhí)行SQL需要耗時(shí)77ms, CPU 消耗維持在 95% 左右;
接下來(lái),我們將連接池的大小改小點(diǎn),設(shè)置成 1024,其他測(cè)試參數(shù)不變,結(jié)果咋樣?
“這里,獲取連接等待時(shí)長(zhǎng)基本不變,但是 SQL 的執(zhí)行耗時(shí)降低了!”
哎呦,有長(zhǎng)進(jìn)哦!
接下來(lái),我們?cè)僭O(shè)置小些,連接池的大小降低到 96,并發(fā)數(shù)等其他參數(shù)不變,看看結(jié)果如何:
每個(gè)請(qǐng)求在連接池隊(duì)列中的平均等待時(shí)間為 1ms, SQL 執(zhí)行耗時(shí)為 2ms.
我去!什么鬼?
我們沒(méi)調(diào)整任何東西,僅僅只是將數(shù)據(jù)庫(kù)連接池的大小降低了,這樣,就能把之前平均 100ms 響應(yīng)時(shí)間縮短到了 3ms。吞吐量指數(shù)級(jí)上升??!
你這也太溜了!
為啥有這種效果?
我們不妨想一下,為啥 Nginx 內(nèi)部?jī)H僅使用了 4 個(gè)線程,其性能就大大超越了 100 個(gè)進(jìn)程的 Apache HTTPD 呢?追究其原因的話,回想一下計(jì)算機(jī)科學(xué)的基礎(chǔ)知識(shí),答案其實(shí)非常明顯。
要知道,即使是單核 CPU 的計(jì)算機(jī)也能“同時(shí)”運(yùn)行著數(shù)百個(gè)線程。但我們其實(shí)都知道,這只不過(guò)是操作系統(tǒng)快速切換時(shí)間片,跟我們玩的一個(gè)小把戲罷了。
一核 CPU同一時(shí)刻只能執(zhí)行一個(gè)線程,然后操作系統(tǒng)切換上下文,CPU 核心快速調(diào)度,執(zhí)行另一個(gè)線程的代碼,不停反復(fù),給我們?cè)斐闪怂羞M(jìn)程同時(shí)運(yùn)行假象。
其實(shí),在一核 CPU 的機(jī)器上,順序執(zhí)行A和B永遠(yuǎn)比通過(guò)時(shí)間分片切換“同時(shí)”執(zhí)行A和B要快,其中原因,學(xué)過(guò)操作系統(tǒng)這門(mén)課程的童鞋應(yīng)該很清楚。一旦線程的數(shù)量超過(guò)了 CPU 核心的數(shù)量,再增加線程數(shù)系統(tǒng)就只會(huì)更慢,而不是更快,因?yàn)檫@里涉及到上下文切換耗費(fèi)的額外的性能。
說(shuō)到這里,應(yīng)該恍然大悟了 ……
以上就是Mysql連接數(shù)設(shè)置和獲取的方法的詳細(xì)內(nèi)容,更多關(guān)于Mysql連接數(shù)設(shè)置和獲取的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
- 淺談Mysql連接數(shù)據(jù)庫(kù)時(shí)host和user的匹配規(guī)則
- PHP連接MySQL數(shù)據(jù)庫(kù)三種實(shí)現(xiàn)方法
- Navicat Premium遠(yuǎn)程連接MySQL數(shù)據(jù)庫(kù)的方法
- 使用IDEA配置Tomcat和連接MySQL數(shù)據(jù)庫(kù)(JDBC)詳細(xì)步驟
- 詳解DBeaver連接MySQL8以上版本以及解決可能遇到的問(wèn)題
- 連接docker里面的mysql失敗解決方法
- 解決navicat遠(yuǎn)程連接mysql報(bào)錯(cuò)10038的問(wèn)題
- Php連接及讀取和寫(xiě)入mysql數(shù)據(jù)庫(kù)的常用代碼
- 遠(yuǎn)程連接mysql 授權(quán)方法詳解
- C#連接MySql數(shù)據(jù)庫(kù)的方法
- MySQL的MaxIdleConns不合理,會(huì)變成短連接的原因
相關(guān)文章
mysql數(shù)據(jù)遷移到Oracle的正確方法
這篇文章主要為大家詳細(xì)介紹了mysql數(shù)據(jù)遷移到Oracle的正確方法,文中步驟介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-02-02Mysql數(shù)據(jù)庫(kù)性能優(yōu)化之子查詢
這篇文章主要介紹了Mysql數(shù)據(jù)庫(kù)性能優(yōu)化之子查詢的相關(guān)資料,非常不錯(cuò),具有參考借鑒價(jià)值,需要的朋友可以參考下2017-01-01MySQL數(shù)據(jù)庫(kù)導(dǎo)入導(dǎo)出數(shù)據(jù)之報(bào)錯(cuò)解答實(shí)例講解
這篇文章主要介紹了MySQL數(shù)據(jù)庫(kù)導(dǎo)入導(dǎo)出數(shù)據(jù)之報(bào)錯(cuò)解答實(shí)例講解,文中對(duì)報(bào)錯(cuò)和解決方法做了詳細(xì)的實(shí)例展示,有需要的同學(xué)可以借鑒參考下2021-02-02mysql數(shù)據(jù)庫(kù)創(chuàng)建賬號(hào)、授權(quán)、數(shù)據(jù)導(dǎo)出、導(dǎo)入操作示例
這篇文章主要介紹了mysql數(shù)據(jù)庫(kù)創(chuàng)建賬號(hào)、授權(quán)、數(shù)據(jù)導(dǎo)出、導(dǎo)入操作,結(jié)合實(shí)例形式分析了MySQL數(shù)據(jù)庫(kù)賬號(hào)創(chuàng)建、權(quán)限控制、數(shù)據(jù)導(dǎo)入導(dǎo)出等具體實(shí)現(xiàn)方法與操作注意事項(xiàng),需要的朋友可以參考下2020-01-01