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