起因:周末測試發現線上mq消息積壓了十幾萬的消息,如下圖所示 每個隊列幾萬的消息,立即采取緊急措施,將隊列下線重新上線。 處理積壓消息的量,調用量起來了,很快消息積壓解決了。開始事件復盤。 首先分析是否是消息消費能力跟不上消息產生原因,看入口消息,QPS是29.6 消息消費 ...
一次老生代內存使用占比飆升問題解決 老生代內存使用占比圖示 如圖所示老生代內存占比不斷增加,超過 系統自動報警,之前的解決方案是手動重啟 。 保存現場 為了解決上面老生代問題,首先需要dump下堆文件 命令: DialingRobot是服務名稱,找到對應的pid pid: dump堆內存 jmap dump:format b,file .dump 將堆內存dump下來 為了分析內存的變化,可以在不 ...
2020-05-21 15:20 2 1167 推薦指數:
起因:周末測試發現線上mq消息積壓了十幾萬的消息,如下圖所示 每個隊列幾萬的消息,立即采取緊急措施,將隊列下線重新上線。 處理積壓消息的量,調用量起來了,很快消息積壓解決了。開始事件復盤。 首先分析是否是消息消費能力跟不上消息產生原因,看入口消息,QPS是29.6 消息消費 ...
1.異常的原因: (1).DocumentDB重啟導致一段時間服務不可以使用,並且DocumentDB無法實現主備的切換; (2).statistic_record_service, thirdparty_control,queue_message這三個gen_server ...
一次MySQL死鎖問題解決 一、環境 CentOS, MySQL 5.6.21-70, JPA 問題場景:系統有定時批量更新數據狀態操作,每次更新上千條記錄,表中總記錄數約為500W左右。 二、錯誤日志 三、排查 排查后發現都是執行類似這樣的語句出現問題 ...
1、問題描述: 應用服務器通過post方式向nginx服務器發送http請求,返回 302 2、問題解決過程 2.1、查詢nginx日志,開始以為302錯誤會在nginx的錯誤日志error.log,最后發現該日志位於access.log; 通過分析日志可以拿到請求的url ...
使用場景 定義在parent項目中,管理children中引入的依賴版本信息 定義來說比叫簡單,既然在父項目中定義了 創建maven項目,項目結構 wangshuyu-center pom.xml中引入了 dependencyManagement ...
最近在寫日志管理,想着使用攔截器加注解的方式,但是遇到了一個問題,就是如果使用@RequestBody注解接收的參數只能讀取一次,造成了我在攔截器中如果接收了參數,在Controller層就接收不到了,為了解決這個問題,在網上查了方法。自定義一個MyRequestWrapper 繼承 ...
背景 突然間接到運維的報警,我們一個服務,內存找過了6GB的占用。才6GB 也不是很大,因為在處理別的事情,服務dump一下暫時一放,然后半小時之后,接到了運維的Kafka堆積報警。然后切換着重啟了一下兩個節點,Kafka消費速率回復正常,內存也從500M攀升到2GB后逐漸穩定。當天半夜,運維 ...
1.最初的時候是這種方式寫的按鈕點擊事件,在貨主部分正常顯示在貨運站部分點擊無效 2.換了一種方式去寫點擊事件在貨運站中才可以點擊,但是會出現點擊一次執行兩次的情況,表現就是列表展開后立馬收起 3.后面查了一下按這種方式來寫,阻止第二次點擊,顯示正常,查了下 ...