記錄一次jvm內存泄露的問題
前些天，運維告訴我剛上線的java服務占用CPU過高。 以下是發現解決問題的具體流程。 1：通過#top命令查看，我的java服務確實把CPU幾乎占滿了，如圖 可看到18400這個進程CPU占用達到了1200%，這確實不太正常，那么我們接下來分析 ...
原文：記錄一次用戶態踩內存問題
這幾天在做總結，把三年前寫的一個定位案例，翻了出來。回想起定位這個問題時的場景，領導催得緊，自己對很多東西又不熟悉，所以當時面臨的壓力還是很大的。現在回想起來感慨還是很多的，我們在遇到任何一個問題，一定不要放棄。還記得在產品線做開發時，學到的一些項目知識，任何一個bug，他總有一天會爆發出來。任何一個問題，總有一天找到好的解決方案。當我們嘗盡了所有可以嘗試的方案，定位辦法，解決思路后，往往這個問題 ...
2019-08-02 12:41 0 1648 推薦指數：
相關推薦
記錄一次ClickHouse的踩坑經歷
最近在做Metabase和ClickHouse集成，使用社區開發的數據驅動把ClickHouse集成到了Metabase。 大部分查詢是沒有問題，只時間維度的聚合查詢會報以下異常： 詳細使用場景如下： 一、ClickHouse的版本 二、查詢表結構 2.1 本地 ...
記錄一次TraceId的問題
多服務部署的時候，各個服務通過httpClient進行調用時候，有時候出現問題，需要進行追查。但是如果沒有一個標記，就會很迷茫，特別是多個服務來回調用，就無法快速定位問題。這個時候一般是使用MDC的 traceId來追蹤。但是由於每個服務的traceId ...
記錄一次問題排查
1. 問題描述：早上剛來上班，業務部門同事反應管理后台無法登錄 2. 問題排查定位 2.1 服務器排查 a. 接口是否可以調通：首先自己登陸后台，發現時好時壞，偶爾接口返回【系統忙】。我們系統接口異常調不通會返回系統忙 b. 服務是否死掉或者假死：連接服務器->查看Java ...
記錄一次現網MySQL內存增長超限問題定位過程
問題現象現網物理機內存近幾日內爆漲使用率超過了90%，可用內存從250G，降低到20G以下，報告警。服務器使用情況來看，並沒有什么異常。除了QPS緩慢增長外。 MySQL內存分配結構 定位這個問題，先了解一下MySQL的內存分配知識。 MySQL的內存分配分為兩部分，一部分是啟動之初 ...
記一次jenkins構建失敗的踩坑記錄
核心要旨:排錯要一步一步排查,一步一步確認,確認問題失敗在哪一步,而不是憑空猜測錯誤. 異常信息: 本質原因是因為jdk版本升級了,之前的javahome路徑失效了導致的. 但是在java升級的那天,我修改了gitee的密碼,然后我從一開始就以為是因為憑證出了問題 ...
關於idea的一次踩坑記錄-Auto build completed with errors
maven項目添加pom依賴后，一直不能正常導入所依賴的jar包，並且報錯“ Auto build completed with errors” ...
一次從Github向Gitee遷庫踩坑記錄
先上結論：gitee的lfs功能收費，直接從github遷移包含lfs管理的文件會出錯，配置lfs.url即可解決問題 Q: 為什么要遷庫呢？ A: github訪問太慢了，不然我也不想費這個功夫！ gitee自帶的有從github同步倉庫的功能，一般來說該功能非常方便 ...