現(xiàn)象
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括郴州網(wǎng)站建設(shè)、郴州網(wǎng)站制作、郴州網(wǎng)頁制作以及郴州網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,郴州網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到郴州省份的部分城市,未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
Sysbench對MySQL進(jìn)行壓測, 并發(fā)數(shù)過大(5k)時(shí), Sysbench建立連接的步驟會超時(shí).
猜想
猜想: 直覺上這很簡單, Sysbench每建立一個(gè)連接, 都要消耗一個(gè)線程, 資源消耗過大導(dǎo)致超時(shí).
驗(yàn)證: 修改Sysbench源碼, 調(diào)大超時(shí)時(shí)間, 仍然會發(fā)生超時(shí).
檢查環(huán)境
猜想失敗, 回到常規(guī)的環(huán)境檢查:
MySQL error log 未見異常.
syslog 未見異常.
tcpdump 觀察網(wǎng)絡(luò)包未見異常, 連接能完成正常的三次握手; 只觀察到在出問題的連接中, 有一部分的TCP握手的第一個(gè)SYN包發(fā)生了重傳, 另一部分沒有發(fā)生重傳.
自己寫一個(gè)簡單的并發(fā)發(fā)生器, 替換sysbench, 可重現(xiàn)場景. 排除sysbench的影響
猜想2
懷疑 MySQL 在應(yīng)用層因?yàn)槟撤N原因, 沒有發(fā)送握手包, 比如卡在某一個(gè)流程上:
檢查MySQL堆棧未見異常, 仿佛MySQL在應(yīng)用層沒有看到新連接進(jìn)入.
通過strace檢查MySQL, 發(fā)現(xiàn)?accept()?調(diào)用確實(shí)沒有感知到新連接.
懷疑是OS的原因, Google之, 得到參考文檔:?A TCP “stuck” connection mystery【】
分析
參考文檔中的現(xiàn)象跟目前的狀況很類似, 簡述如下:
正常的TCP連接流程:
Client 向 Server 發(fā)起連接請求, 發(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連接的流程會使用SYN-cookie, 變?yōu)?
Client 向 Server 發(fā)起連接請求, 發(fā)送SYN.
Server 不預(yù)留連接資源, 向 Client 回復(fù)SYN-ACK, 包中附帶有簽名A.
Client 向 Server 回復(fù)ACK, 附帶 f(簽名A) (對簽名進(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會知道某個(gè)連接”即將建立”)
發(fā)生這種情況時(shí):
若業(yè)務(wù)層的第一個(gè)包應(yīng)是從 Client 發(fā)往 Server, 則會進(jìn)行重發(fā)或拋出連接錯(cuò)誤
若業(yè)務(wù)層的第一個(gè)包應(yīng)是從 Server 發(fā)往 Client的, Server不會發(fā)出第一個(gè)包. MySQL的故障就屬于這種情況.
TCP握手的第三步ACK包為什么丟失
參考文檔中, 對于TCP握手的第三步ACK包的丟失原因, 描述為:
Some of these packets get lost because some buffer somewhere overflows.
我們可以通過Systemtap進(jìn)一步探究原因.?通過一個(gè)簡單的腳本:
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ù))會返回 NULL(0). 即驗(yàn)證是由于syn cookie驗(yàn)證不通過, 導(dǎo)致TCP握手的第三步ACK包不被接受.
之后就是對其中不同條件進(jìn)行觀察, 看看是哪個(gè)條件不通過. 最終原因是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), 因此被忽略.
檢查Linux源碼:
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只會發(fā)送一次告警日志, 要獲得日志與故障的正關(guān)聯(lián), 必須每次測試重啟MySQL.
解決方案
這種故障一旦形成, 難以檢測; 系統(tǒng)日志中只會出現(xiàn)一次, 在下次重啟MySQL之前就不會再出現(xiàn)了; Client如果沒有合適的超時(shí)機(jī)制, 萬劫不復(fù).
解決方案:
1. 修改MySQL的協(xié)議, 讓Client先發(fā)握手包. 顯然不現(xiàn)實(shí).
2. 關(guān)閉syn_cookie. 有安全的人又要跳出來了.
3. 或者調(diào)高syn_cookie的觸發(fā)條件 (syn backlog長度). 降低系統(tǒng)對syn flood的敏感度, 使之可以容忍業(yè)務(wù)的syn波動.
有多個(gè)系統(tǒng)參數(shù)混合影響syn backlog長度, 參看【】
下圖為精華總結(jié)
請點(diǎn)擊輸入圖片描述
可以通過以下幾種方式來模擬高并發(fā)連接不夠用:
1. 使用壓力測試工具來模擬高并發(fā):比如JMeter、ApacheBench等工具,通過模擬多個(gè)用戶同時(shí)訪問數(shù)據(jù)庫來測試數(shù)據(jù)庫的并發(fā)處理能力。
2. 減少連接池大小:可以在MySQL的配置文件中設(shè)置連接池大小,將其設(shè)置得非常小,例如只有10個(gè)連接,然后通過多個(gè)客戶端同時(shí)連接數(shù)據(jù)庫,可以模擬連接不夠用的情況。
3. 使用外部工具模擬高并發(fā):可以使用類似ab或者wrk這樣的工具來模擬高并發(fā),這些工具會向服務(wù)器發(fā)送大量的請求,讓服務(wù)器來處理請求,從而模擬高并發(fā)的情況。
4. 增加并發(fā)請求數(shù):可以通過編寫程序來同時(shí)向數(shù)據(jù)庫發(fā)起大量的并發(fā)請求,從而模擬高并發(fā)的情況。可以使用Python的multiprocessing庫或者Java的多線程技術(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配置文件 max_connections = 1000 重啟mysql。
可通過show variables like 'max_connections'; 查看當(dāng)前設(shè)置的連接數(shù)。
當(dāng)前文章:mysql怎么修改并發(fā)數(shù) mysql并發(fā)更新數(shù)據(jù)
文章來源:http://vcdvsql.cn/article26/ddihecg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)網(wǎng)站建設(shè)、微信公眾號、標(biāo)簽優(yōu)化、網(wǎng)站維護(hù)、搜索引擎優(yōu)化、品牌網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)