mysql怎么修改并發(fā)數(shù) mysql并發(fā)更新數(shù)據(jù)

如何處理mysql數(shù)據(jù)庫(kù)并發(fā)更新問題

現(xiàn)象

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括郴州網(wǎng)站建設(shè)、郴州網(wǎng)站制作、郴州網(wǎng)頁(yè)制作以及郴州網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，郴州網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到郴州省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

Sysbench對(duì)MySQL進(jìn)行壓測(cè), 并發(fā)數(shù)過(guò)大(5k)時(shí), Sysbench建立連接的步驟會(huì)超時(shí).

猜想

猜想: 直覺上這很簡(jiǎn)單, Sysbench每建立一個(gè)連接, 都要消耗一個(gè)線程, 資源消耗過(guò)大導(dǎo)致超時(shí).

驗(yàn)證: 修改Sysbench源碼, 調(diào)大超時(shí)時(shí)間, 仍然會(huì)發(fā)生超時(shí).

檢查環(huán)境

猜想失敗, 回到常規(guī)的環(huán)境檢查:

MySQL error log 未見異常.

syslog 未見異常.

tcpdump 觀察網(wǎng)絡(luò)包未見異常, 連接能完成正常的三次握手; 只觀察到在出問題的連接中, 有一部分的TCP握手的第一個(gè)SYN包發(fā)生了重傳, 另一部分沒有發(fā)生重傳.

自己寫一個(gè)簡(jiǎn)單的并發(fā)發(fā)生器, 替換sysbench, 可重現(xiàn)場(chǎng)景. 排除sysbench的影響

猜想2

懷疑 MySQL 在應(yīng)用層因?yàn)槟撤N原因, 沒有發(fā)送握手包, 比如卡在某一個(gè)流程上:

檢查MySQL堆棧未見異常, 仿佛MySQL在應(yīng)用層沒有看到新連接進(jìn)入.

通過(guò)strace檢查MySQL, 發(fā)現(xiàn)?accept()?調(diào)用確實(shí)沒有感知到新連接.

懷疑是OS的原因, Google之, 得到參考文檔:?A TCP “stuck” connection mystery【】

分析

參考文檔中的現(xiàn)象跟目前的狀況很類似, 簡(jiǎn)述如下:

正常的TCP連接流程:

Client 向 Server 發(fā)起連接請(qǐng)求, 發(fā)送SYN.

Server 預(yù)留連接資源, 向 Client 回復(fù)SYN-ACK.

Client 向 Server 回復(fù)ACK.

Server 收到 ACK, 連接建立.

在業(yè)務(wù)層上, Client和Server間進(jìn)行通訊.

當(dāng)發(fā)生類似SYN-flood的現(xiàn)象時(shí), TCP連接的流程會(huì)使用SYN-cookie, 變?yōu)?

Client 向 Server 發(fā)起連接請(qǐng)求, 發(fā)送SYN.

Server 不預(yù)留連接資源, 向 Client 回復(fù)SYN-ACK, 包中附帶有簽名A.

Client 向 Server 回復(fù)ACK, 附帶 f(簽名A) (對(duì)簽名進(jìn)行運(yùn)算的結(jié)果).

Server 驗(yàn)證簽名, 分配連接資源, 連接建立.

在業(yè)務(wù)層上, Client和Server間進(jìn)行通訊.

當(dāng)啟用SYN-cookie時(shí), 第3步的ACK包因?yàn)?某種原因?丟失, 那么:

從Client的視角, 連接已經(jīng)建立.

從Server的視角, 連接并不存在, 既沒有建立, 也沒有”即將建立” (若不啟用SYN-cookie, Server會(huì)知道某個(gè)連接”即將建立”)

發(fā)生這種情況時(shí):

若業(yè)務(wù)層的第一個(gè)包應(yīng)是從 Client 發(fā)往 Server, 則會(huì)進(jìn)行重發(fā)或拋出連接錯(cuò)誤

若業(yè)務(wù)層的第一個(gè)包應(yīng)是從 Server 發(fā)往 Client的, Server不會(huì)發(fā)出第一個(gè)包. MySQL的故障就屬于這種情況.

TCP握手的第三步ACK包為什么丟失

參考文檔中, 對(duì)于TCP握手的第三步ACK包的丟失原因, 描述為:

Some of these packets get lost because some buffer somewhere overflows.

我們可以通過(guò)Systemtap進(jìn)一步探究原因.?通過(guò)一個(gè)簡(jiǎn)單的腳本:

probe kernel.function("cookie_v4_check").return

{

source_port = @cast($skb-head + $skb-transport_header, "struct tcphdr")-source

printf("source=%d, return=%d\n",readable_port(source_port), $return)

}

function readable_port(port) {

return (port ((19)-1)) 8 | (port 8)

}

觀察結(jié)果, 可以確認(rèn)cookie_v4_check?(syn cookie機(jī)制進(jìn)行包簽名檢查的函數(shù))會(huì)返回 NULL(0). 即驗(yàn)證是由于syn cookie驗(yàn)證不通過(guò), 導(dǎo)致TCP握手的第三步ACK包不被接受.

之后就是對(duì)其中不同條件進(jìn)行觀察, 看看是哪個(gè)條件不通過(guò). 最終原因是accept隊(duì)列滿(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock ?*sk){ ? return sk-sk_ack_backlog sk- ? sk_max_ack_backlog;}

恢復(fù)故障與日志的正關(guān)聯(lián)

在故障處理的一開始, 我們就檢查了syslog, 結(jié)論是未見異常.

當(dāng)整個(gè)故障分析完成, 得知了故障與syn cookie有關(guān), 回頭看syslog, 里面是有相關(guān)的信息, 只是和故障發(fā)生的時(shí)間不匹配, 沒有正關(guān)聯(lián), 因此被忽略.

檢查L(zhǎng)inux源碼:

if (!queue-synflood_warned

sysctl_tcp_syncookies != 2

xchg(queue-synflood_warned, 1) == 0)

pr_info("%s: Possible SYN flooding on port %d. %s.

Check SNMP counters.\n",

proto, ntohs(tcp_hdr(skb)-dest), msg);

可以看到日志受到了抑制, 因此日志與故障的正關(guān)聯(lián)被破壞.

粗看源碼, 每個(gè)listen socket只會(huì)發(fā)送一次告警日志, 要獲得日志與故障的正關(guān)聯(lián), 必須每次測(cè)試重啟MySQL.

解決方案

這種故障一旦形成, 難以檢測(cè); 系統(tǒng)日志中只會(huì)出現(xiàn)一次, 在下次重啟MySQL之前就不會(huì)再出現(xiàn)了; Client如果沒有合適的超時(shí)機(jī)制, 萬(wàn)劫不復(fù).

解決方案:

1. 修改MySQL的協(xié)議, 讓Client先發(fā)握手包. 顯然不現(xiàn)實(shí).

2. 關(guān)閉syn_cookie. 有安全的人又要跳出來(lái)了.

3. 或者調(diào)高syn_cookie的觸發(fā)條件 (syn backlog長(zhǎng)度). 降低系統(tǒng)對(duì)syn flood的敏感度, 使之可以容忍業(yè)務(wù)的syn波動(dòng).

有多個(gè)系統(tǒng)參數(shù)混合影響syn backlog長(zhǎng)度, 參看【】

下圖為精華總結(jié)

請(qǐng)點(diǎn)擊輸入圖片描述

mysql怎么模擬高并發(fā)連接不夠用

可以通過(guò)以下幾種方式來(lái)模擬高并發(fā)連接不夠用：

1. 使用壓力測(cè)試工具來(lái)模擬高并發(fā)：比如JMeter、ApacheBench等工具，通過(guò)模擬多個(gè)用戶同時(shí)訪問數(shù)據(jù)庫(kù)來(lái)測(cè)試數(shù)據(jù)庫(kù)的并發(fā)處理能力。

2. 減少連接池大?。嚎梢栽贛ySQL的配置文件中設(shè)置連接池大小，將其設(shè)置得非常小，例如只有10個(gè)連接，然后通過(guò)多個(gè)客戶端同時(shí)連接數(shù)據(jù)庫(kù)，可以模擬連接不夠用的情況。

3. 使用外部工具模擬高并發(fā)：可以使用類似ab或者wrk這樣的工具來(lái)模擬高并發(fā)，這些工具會(huì)向服務(wù)器發(fā)送大量的請(qǐng)求，讓服務(wù)器來(lái)處理請(qǐng)求，從而模擬高并發(fā)的情況。

4. 增加并發(fā)請(qǐng)求數(shù)：可以通過(guò)編寫程序來(lái)同時(shí)向數(shù)據(jù)庫(kù)發(fā)起大量的并發(fā)請(qǐng)求，從而模擬高并發(fā)的情況。可以使用Python的multiprocessing庫(kù)或者Java的多線程技術(shù)來(lái)編寫程序。

如何增加mysql數(shù)據(jù)庫(kù)并發(fā)數(shù)

方法一：進(jìn)入MYSQL安裝目錄 打開MYSQL配置文件 my.ini 或 my點(diǎn)吸煙 f查找 max_connections=100 修改為 max_connections=1000 服務(wù)里重起MYSQL即可

方法二：MySQL的最大連接數(shù)默認(rèn)是100客戶端登錄：mysql -uusername -ppassword

設(shè)置新的最大連接數(shù)為200：mysql set GLOBAL max_connections=200

顯示當(dāng)前運(yùn)行的Query：mysql show processlist

顯示當(dāng)前狀態(tài)：mysql show status

退出客戶端：mysql exit

查看當(dāng)前最大連接數(shù)：mysqladmin -uusername -ppassword variables

如何修改mysql并發(fā)數(shù)

修改mysql配置文件 max_connections = 1000 重啟mysql。

可通過(guò)show variables like 'max_connections'; 查看當(dāng)前設(shè)置的連接數(shù)。

當(dāng)前文章：mysql怎么修改并發(fā)數(shù) mysql并發(fā)更新數(shù)據(jù)
文章來(lái)源：http://muchs.cn/article26/ddihecg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、微信公眾號(hào)、標(biāo)簽優(yōu)化、網(wǎng)站維護(hù)、搜索引擎優(yōu)化、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)