線上環境,在高併發場景遇到日誌寫本地磁碟延遲的情況。例如當前時間17:00,日誌最近一條記錄是14:00,延遲多個小時,但是日誌數量不會發生丟失。且發現記憶體占用達到10幾g,比其他正常機器高出很多倍。
應用程式在記憶體中維護乙個佇列,當使用者請求到達,產生使用者日誌的時候,會將使用者日誌入佇列。同時應用會啟乙個非同步執行緒,不斷的輪詢佇列,將佇列的隊頭元素出佇列,呼叫io函式寫入磁碟。
改造前
public class asyncthread
}}
通過jmeter在本地環境模擬高併發情況,復現了該問題。仔細分析原因,發現問題出在非同步執行緒輪訓的過程中,會不斷呼叫io函式,而該io函式會呼叫flush重新整理緩衝區資料,且每次都只有隊頭元素這乙個日誌寫入磁碟,這就導致了頻繁的上下文切換,設定的緩衝區無效,每次只有一行日誌寫入緩衝區,並flush刷入磁碟。使得日誌入佇列的速度遠遠大於日誌寫入磁碟的速度。日誌不斷的在佇列中積壓,這就導致了機器記憶體的不斷上公升。
非同步執行緒在輪訓的過程中,每次都將佇列所有元素取出,然後再呼叫io函式進行日誌寫入。該線上問題,也說明cpu的上下文切換是非常耗時的,io緩衝區的存在也是非常有必要的。
改造後
public class asyncthread
ioutil.flush();
}}
ELK日誌系統的線上問題排查 Logstash問題
在公司搭建的分布式實時統一日誌平台,是通過felk的方式組建的,大致流程是 filebeat是和應用部署在乙個pod中的 k8s部署 目前的量為70 80個應用,資料一天50g.事故回放 有同學通知在kibana中查日誌,發現當天的某個時間段後都沒有日誌了,查之前的日誌都是ok的。找問題經過 1 k...
python多程序 寫日誌問題
在使用 timedrotatingfilehandler python日誌切分的時候,遇到錯誤 os.rename source,dest permissionerror winerror 32 另乙個程式正在使用此檔案,程序無法訪問 是單程序的,最初遇到這個錯誤比較疑惑,最後發現是在 中 impo...
PHP問題定位 線上機器打日誌混亂問題定位分析
被交叉的日誌很有規律,都是單條日誌過長被截斷的,建議優化下 ruleanalysis.php 68 此處寫入日誌的字串長度為 int 25909 指令碼服務寫入日誌 如下 if this iscli true 檢視file put contents 的原始碼實現,最終寫檔案會執行到 php stre...