今天從應用層面解決了乙個詭異的問題。
某程式，在伺服器a上跑速度很快，幾乎能將cpu乙個核的資源佔滿。而在伺服器b上跑很慢，（慢了將近10倍），而且cpu使用率很低。
伺服器a和b都是同樣的系統，幾乎相同型號的伺服器。
通過各種排查原因，未果。最後還是認為是程式的問題。
最終問題發生原因鎖定在乙個sqlite庫的讀寫上，有頻繁的寫庫操作，而每次寫庫耗時是整個計算的瓶頸所在。
於是處理在記憶體上加一層快取，並且使用事務插入，問題解決。
所以猜測是伺服器b上檔案的隨機訪問和控制代碼開啟速度都差很多，每次操作都累計耗時，最終導致效率低下。
loadrunner 乙個詭異問題
最近使用loadrunner壓測乙個專案的時候,發現tps波動巨大 且平均值較低。使用jmeter壓測則沒有這個問題。經過多方排查發現乙個讓人極度費解的原因 原指令碼 指令碼其他 web submit data aaa action 此處為密文鏈結 事務判斷邏輯等 tps圖如下 修改後的 指令碼其他...
python 乙個詭異問題的解決
檔案上傳中，需要驗證銀行卡號，於是寫正則如下 regex r d 然後上傳到伺服器，結果re.match regex,file field 為none。在notpad 中驗證正則能夠match,又在python命令列中試了一下 import re re.match r d 6228410770613...
乙個詭異的C 記憶體洩露問題。
delet被編譯成了兩個步驟 調相應析構函式，p指向的記憶體塊 即使父類沒宣告虛析構函式，第二步還是生效的，所以你derived的記憶體區是被正確 的，但derived的記憶體區域 std string 並不是連續區間，可能是這樣的東東 64byte ptr delet的第二步 的就只是這 64by...