webman mysql數(shù)據(jù)庫(kù)連接自動(dòng)釋放資源問(wèn)題
項(xiàng)目描述
1。定時(shí)任務(wù)每秒提交訂單至redis隊(duì)列處理訂單是否過(guò)期
2。自定義進(jìn)程異步websocket客戶端獲得數(shù)據(jù)并寫入數(shù)據(jù)庫(kù)
3。其它就是一些常規(guī)crud操作的接口。
4。項(xiàng)目用think-orm操作mysql 8.0。
異常描述：
運(yùn)行一段時(shí)間后，內(nèi)存使用率會(huì)升高不少，穩(wěn)定要65%左右。然后接口提交的數(shù)據(jù)像寫入內(nèi)存沒實(shí)際寫入數(shù)據(jù)庫(kù)里一樣，比如：下單流程執(zhí)行成功，刷新訂單列表，新產(chǎn)生的訂單通過(guò)接口拉取是正常，刷新頁(yè)面再拉取的訂單列表就會(huì)沒有剛新下的訂單。再刷新又會(huì)有新訂單。 如此往復(fù)，重啟mysql數(shù)據(jù)庫(kù)服務(wù)后,之前新下的訂單就會(huì)消失，再下訂單一切正常。查看自增ID,會(huì)缺失。
下圖是查詢異常的截圖
之前全部php-fpm開發(fā)，邏輯上還是按php-fpm開發(fā)，項(xiàng)目重新基于webman開發(fā) 開發(fā)前已避免手冊(cè)上無(wú)限注入靜態(tài)變量的造成內(nèi)存泄露問(wèn)題。查閱資料 php start.php status查看是正常.
目前無(wú)法理解cli模式下，數(shù)據(jù)連接用完是否銷毀，如果是連接池是如何重復(fù)利用的,是否有手動(dòng)歸還連接的操作？
上面的問(wèn)題應(yīng)該如何解決？以后開發(fā)中的注意事項(xiàng)
還希望大神能幫助解決一下。
2個(gè)回答
打賞
linux系統(tǒng)與windows不同，linux會(huì)盡可能利用內(nèi)存提高性能，65%如果是指整個(gè)系統(tǒng)的內(nèi)存使用率，實(shí)際上是一個(gè)很低的值。一般linux系統(tǒng)內(nèi)存占用都在90%左右都是正常的。即時(shí)占用90%，也不意味著是webman程序自身占用。
新訂單時(shí)而顯示時(shí)而消失看起來(lái)和事務(wù)有關(guān)，有可能是有事務(wù)沒提交。請(qǐng)檢查所有事物相關(guān)的代碼(注意用try catch(\Throwable $e)，不要用try catch(\Exception $e ) 。
截圖中的報(bào)錯(cuò)是因?yàn)閿?shù)據(jù)庫(kù)沒啟動(dòng)或者重啟導(dǎo)致的，如果數(shù)據(jù)庫(kù)重啟過(guò)，報(bào)這個(gè)錯(cuò)很正常。
webman中一般不需要關(guān)注內(nèi)存泄漏問(wèn)題，因?yàn)閣ebman會(huì)自動(dòng)跟蹤各個(gè)進(jìn)程使用情況，如果真的有內(nèi)存泄漏達(dá)到一定值會(huì)安全重啟對(duì)應(yīng)進(jìn)程，對(duì)業(yè)務(wù)無(wú)影響。如果你關(guān)心內(nèi)存泄漏，根據(jù)手冊(cè)，只需要注意靜態(tài)數(shù)組不要無(wú)限膨脹即可，和靜態(tài)變量沒有直接關(guān)系。
webman里數(shù)據(jù)庫(kù)連接用完不會(huì)銷毀，也不需要程序手動(dòng)歸還連接，不需要做任何其它操作。只需要注意事物記得在業(yè)務(wù)里提交或者回滾。
-
anlla 2022-07-26我想的也是事務(wù)那塊的問(wèn)題，重啟后回滾才造成自增ID刪除的。
目前業(yè)務(wù)提交是按tp的事務(wù)提交方式提交
Db::startTrans();
try {
...
Db::commit();
return msg('提交成功')
} catch (\Exception $e) {
Db::rollback();
return msg($e->getMessage())
}
不知道這樣寫是否會(huì)有問(wèn)題？如果沒問(wèn)題為何會(huì)運(yùn)行一段時(shí)間事務(wù)就無(wú)法提交？ -
-
-
walkor 2022-08-11
你多慮了，webman里請(qǐng)求是排隊(duì)處理的，不會(huì)出現(xiàn)一個(gè)進(jìn)程同時(shí)處理多個(gè)請(qǐng)求的情況，不會(huì)出現(xiàn)你說(shuō)的事物不完整數(shù)據(jù)混亂的情況。當(dāng)然你業(yè)務(wù)有bug在一個(gè)請(qǐng)求里沒有提交或者回滾事物除外。
另外連接池也不會(huì)因?yàn)槟闶褂檬挛锶ヮl繁的斷開連接，連接池的一個(gè)主要目的就是避免頻繁創(chuàng)建銷毀數(shù)據(jù)庫(kù)連接。
一個(gè)進(jìn)程只有一個(gè)mysql鏈接，8個(gè)worker進(jìn)程，同時(shí)只能8個(gè)人同時(shí)訪問(wèn)數(shù)據(jù)庫(kù)。
-
walkor 2022-08-11
事物用 try {} catch (\Throwable $e) {Db::rollback();}就沒問(wèn)題哈，這個(gè)是基本的事物操作。如果你對(duì)自己代碼沒有信心，可以弄個(gè)中間件，在請(qǐng)求處理完畢的時(shí)候判斷下是否有未提交的事物，自己決定是否提交或者回滾。
-
evilk 2022-08-11之前回答過(guò)這個(gè)問(wèn)題,現(xiàn)在再多講兩句
之前我們也遇到跟樓主一模一樣的問(wèn)題
當(dāng)時(shí)覺得非常震驚和擔(dān)心
上一個(gè)請(qǐng)求的事務(wù)沒有提交或者回滾,的確是會(huì)影響下一個(gè)請(qǐng)求
這就需要保證每一個(gè)請(qǐng)求的事務(wù),都必須提交或者回滾,不能掛起(這個(gè)需要使用者自己來(lái)保證)
最后檢查了代碼,所有事務(wù),都catch (Throwable $throwable) 而非 catch (Exception $exception) -
-
nitron 2022-08-11業(yè)務(wù)層面的問(wèn)題,不應(yīng)由框架去保證,畢竟DB層的Adapter太多,有人用EloquentORM,有人用ThinkORM, 有人用Medoo,有人用Doctrine,還有人用簡(jiǎn)單PDO
而且也說(shuō)了, catch Throwable即可 -
咸魚.php 2022-08-12第一次見到說(shuō)walkor沒有“耐心”的，有空多看看問(wèn)答，walkor在線解決了多少問(wèn)題，還有哪個(gè)框架的作者會(huì)這樣回答問(wèn)題？
-
我們之前遇見過(guò)類似的問(wèn)題
頁(yè)面上顯示有數(shù)據(jù),再次刷新或者重啟后,數(shù)據(jù)消失
檢查了代碼,排查了各種可能性
可能是某個(gè)請(qǐng)求的事務(wù)被掛起了
既沒有提交,也沒有回滾
同一個(gè)進(jìn)程,處理下一個(gè)請(qǐng)求的時(shí)候,如果發(fā)生回滾,會(huì)把之前的事務(wù)一起回滾了
檢查了所有事務(wù)的地方
- 最終全部使用
catch (Throwable $throwable)而非catch (Exception $exception) - 注冊(cè)
register_shutdown_function函數(shù),在請(qǐng)求結(jié)束后,檢查事務(wù)狀態(tài)
后面再也沒有出現(xiàn)過(guò)類似情況
常駐內(nèi)存模式下,同一個(gè)進(jìn)程,只會(huì)維護(hù)一個(gè)MySQL鏈接,所有請(qǐng)求都復(fù)用這個(gè)MySQL鏈接
所以一定要確保每個(gè)請(qǐng)求處理完成后,該請(qǐng)求的事務(wù),要么提交,要么回滾
如果掛起了,就會(huì)和下個(gè)請(qǐng)求互相影響
-
-
-
anlla 2022-07-27
PHP7中使用Throwable來(lái)捕獲的話比使用register_shutdown_function這個(gè)函數(shù)來(lái)得更方便，也更推薦Throwable,Error類也是可以捕獲到致命錯(cuò)誤，不過(guò)Error只能捕獲致命錯(cuò)誤，不能捕獲異常Exception，而Throwable是可以捕獲到錯(cuò)誤和異常的，所以更推薦
-
-
