db寫入造成阻塞的原因

592480409 更新于2018-06-28

在本地虛擬機(jī)中壓測時(shí)，單進(jìn)程同一個(gè)方法，如果沒有數(shù)據(jù)庫寫入通訊基本上不是什么問題，單進(jìn)程每秒4000多的回復(fù)速度。但哪怕只有數(shù)據(jù)庫操作時(shí)，哪怕2個(gè)客戶端每秒只請求100次，都會(huì)卡住，數(shù)據(jù)會(huì)丟失，并沒有全部寫入數(shù)據(jù)庫。
不知道產(chǎn)生這樣情況的原因？有沒有解決辦法？數(shù)據(jù)庫操作后來也試過原生的pdo，試過原生pdo的單例，都沒用，都會(huì)堵死。直接連數(shù)據(jù)庫寫入速度是完全沒有問題的，每秒鐘上千條的寫入速度。gateway寫入數(shù)據(jù)庫的速度也很快，0.01秒就寫入一條數(shù)據(jù)，但為啥承載力這么低下，百思不得其解
是二進(jìn)制雙向通信，business寫的業(yè)務(wù)邏輯

 4663  3 0

3個(gè)回答

walkor 2017-03-15

打賞

linux系統(tǒng)用命令
strace -ttp 進(jìn)程pid
能看到到底卡在哪里了

592480409 2017-03-19

運(yùn)行了這個(gè)命令，沒能看懂。。這幾天測試發(fā)現(xiàn)，不僅是操作數(shù)據(jù)庫，還有curl，寫文件，都會(huì)造成這種情況，不像是阻塞，因?yàn)楸O(jiān)看mysql的時(shí)候發(fā)現(xiàn)它很閑，非?？臻e，top看cup也只用了百分之50，更像是gateway占用著資源不釋放，導(dǎo)致后面的請求得不到處理。
還有就是，同事的電腦虛擬機(jī)分配的一核1g內(nèi)存，發(fā)生這種情況很顯著，我的虛擬機(jī)分配的2核4g內(nèi)存，情況好很多，但是請求量大一樣會(huì)發(fā)生這種情況，比如說線程達(dá)到1000時(shí)，這種情況產(chǎn)生后，數(shù)據(jù)庫只能每秒寫入一條數(shù)據(jù)的速度。。。
592480409 2017-03-19

我們做的是物聯(lián)網(wǎng)，設(shè)備每10秒都會(huì)上報(bào)坐標(biāo)的，所以處理速度直接影響服務(wù)器的承載量，這個(gè)問題很是詭異危險(xiǎn)
walkor 2017-03-19

你用的單進(jìn)程，你描述是0.01秒才寫入一條數(shù)據(jù)，那么一個(gè)進(jìn)程一秒鐘只能寫入100條數(shù)據(jù)。你測試時(shí)有兩個(gè)客戶端，每個(gè)客戶端每秒請求100次，假如每次寫一次數(shù)據(jù)庫，那個(gè)需要每秒寫入200條數(shù)據(jù)，已經(jīng)超過單進(jìn)程的承載能力，所以請求可能會(huì)擠壓，出問題也是正常的。
592480409 2017-03-19

不是，用jmeter測試的，是有回復(fù)之后才發(fā)起第二次請求的
592480409 2017-03-19

并不是1秒內(nèi)一定發(fā)起了200次請求
592480409 2017-03-19

問題是，當(dāng)發(fā)生狀況后，數(shù)據(jù)一秒鐘寫入一個(gè)，workerman忙的要死，數(shù)據(jù)庫閑的要死。是什么原因?qū)е碌?？解決辦法是？不然一臺(tái)服務(wù)器cpu百分之50的利用率都用不到就上線顯然是不行的
592480409 2017-03-19

同樣的業(yè)務(wù)把數(shù)據(jù)庫操作去掉后，連16000用戶都可以，只是每秒回復(fù)只有幾千條而已，并不會(huì)出現(xiàn)像這樣占著茅坑不拉屎現(xiàn)象。
592480409 2017-03-19

之前的描述有點(diǎn)不準(zhǔn)確，2個(gè)線程連接gateway，循環(huán)100次，當(dāng)收到回復(fù)發(fā)起第二次請求。有時(shí)候執(zhí)行到100多次就卡住了，有時(shí)候執(zhí)行到幾十次就卡住了。后面的寫入速度很慢，每秒只寫入個(gè)位數(shù)的記錄。當(dāng)循環(huán)完了發(fā)現(xiàn)數(shù)據(jù)庫里記錄只存了幾十條或者100多條，卡住后的很多數(shù)據(jù)都丟失了
592480409 2017-03-19

我的電腦情況好點(diǎn)，1000個(gè)線程循環(huán)10次，寫入了9000多條，丟失了700多條。
100個(gè)線程循環(huán)100次，完全寫入無丟失
592480409 2017-03-19

卡住后數(shù)據(jù)庫寫入速度非常慢，但是數(shù)據(jù)庫其實(shí)非?？臻e
592480409 2017-03-19

單獨(dú)測workerman吞吐的時(shí)候，定時(shí)發(fā)送請求測的，雖然說回復(fù)量沒有跟上請求量，但一直在回復(fù)，沒有這種卡死的情況，沒有這種秒回復(fù)量驟減到個(gè)位數(shù)的情況
walkor 2017-03-20

看起來是沒有優(yōu)化linux內(nèi)核導(dǎo)致的，根據(jù)手冊優(yōu)化下linux內(nèi)核 http://doc3.workerman.net/appendices/kernel-optimization.html 。另外需要安裝event擴(kuò)展或者libevent擴(kuò)展，參考手冊 http://doc3.workerman.net/install/install.html

并不是所有服務(wù)器的默認(rèn)配置都能支持壓測，默認(rèn)內(nèi)核配置都比較低，需要優(yōu)化才能壓測出好成績，才能在正式環(huán)境使用。要想高并發(fā)，正式環(huán)境PHP的event擴(kuò)展或者libevent擴(kuò)展也是必須要裝的。
592480409 2017-03-20

謝謝，是沒優(yōu)化，下午試試
592480409 2017-03-20

性能提高了不少，但后來報(bào)了這樣的錯(cuò)SendBufferToWorker fail. The connections between Gateway and BusinessWorker are not ready
還是卡住了
592480409 2017-03-20

上面還有。。PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes) in /mnt/hgfs/workspace/baiyi/GatewayWorker/Workerman/Connection/TcpConnection.php on line 360內(nèi)存用盡？
walkor 2017-03-20

php.ini 里調(diào)高 memory_limit