dump 線程和內存同時重啟應用,還好重啟之后恢復正常。於是開始着手排查問題。 分析 首先了解下這個應 ...
前一段時間,業務部門同事反饋在一次生產服務器升級之后,POS消費上傳小票業務偶現異常,上傳小票業務有重試機制,有些重試三次也不會成功,他們排查了一下沒有找到原因,希望架構部幫忙解決。 公司使用的是FastDFS來做的圖片服務器,生產使用了六台服務器外加一個存儲,集群采用的是: 個tracker 個storage,storage分為兩個group,使用獨立的nginx做文件代理訪問。各軟件版本信息 ...
2017-12-27 07:45 8 13348 推薦指數:
dump 線程和內存同時重啟應用,還好重啟之后恢復正常。於是開始着手排查問題。 分析 首先了解下這個應 ...
日志集中式監控平台上線已經有一段時間,但是大部分情況下只是作為發布或者出問題時查看日志的便利工具使用。平時大家都不怎么主動上去看看。於是前幾天把應用的錯誤日志也加上郵件、Hi和短信報警,馬上就收到很多錯誤報警,引起了大家的重視。其中有一個Redis報錯: 看起來挺嚴重的,拿不到Redis連接 ...
日志集中式監控平台上線已經有一段時間,但是大部分情況下只是作為發布或者出問題時查看日志的便利工具使用。平時大家都不怎么主動上去看看。於是前幾天把應用的錯誤日志也加上郵件、Hi和短信報警,馬上就收到很多錯誤報警,引起了大家的重視。其中有一個Redis報錯: 看起來挺嚴重的,拿不到 ...
1. 問題描述:早上剛來上班,業務部門同事反應管理后台無法登錄 2. 問題排查定位 2.1 服務器排查 a. 接口是否可以調通:首先自己登陸后台,發現時好時壞,偶爾接口返回【系統忙】。我們系統接口異常調不通會返回系統忙 b. 服務是否死掉或者假死:連接服務器->查看Java ...
有一個新項目,在測試環境部署后,發現tomcat進程耗費的CPU非常高,排查過程如下: 日志搜集 先通過top,查找耗費CPU最高的線程 top -Hp pid 將線程ID轉為16進制 printf "%x\n" threadid 搜集JVM的棧日志 jstack pid > ...
1,http status 5xx 一般就是服務器端的問題,所以直接定位服務器存在什么問題 2,正常情況下,可以通過nginx日志,例如access_log,error_log,最后可以根據日志信息定位問題,例如:https://cloud.tencent.com/developer ...
背景 將log4j.xml的日志級別從error調整為info后,進行壓測發現CPU占用很高達到了90%多(之前也就是50%,60%的樣子). 問題排查 排查思路: 看進程中的線程到底執行的是什么,導致CPU占用較高. 1. 使用top命令查看到底是哪個應用 ...
收到某業務組的小伙伴發來的反饋,具體問題如下: 項目中某 kafka 消息組消費特別慢,有時候在 kafka-manager 控制台看到有些消費者已被踢出消費組。 從服務端日志看到如下信息: 該消費組在短時間內重平衡了 600 多次。 從 cat 查看得知,每條消息處理都會有 4 次數 ...