一次線上問題排查所引發的思考
前言 之前或多或少分享過一些內存模型、對象創建之類的內容，其實大部分人看完都是懵懵懂懂，也不知道這些的實際意義。 直到有一天你會碰到線上奇奇怪怪的問題，如： 線程執行一個任務遲遲沒有返回，應用假死。 接口響應緩慢，甚至請求超時。 CPU 高負載運行。 這類問題並不 ...
原文：一次線上問題引發的對dubbo優雅下線的思考
一.背景 我們經常聊到dubbo的啟動，是如何暴露接口的，如何注冊到注冊中心的，但是就一個完整的生命周期而言，有上線就必然有下線，而下線這一部分往往被人忽略，這次就一次線上發布問題為入口，來分析dubbo下線的過程和其中遇到的問題，從另一個方面加深dubbo整個生命周期的理解。 二.案例 某次生產發布，雖是對外停機發布，一般內部來講，仍采用的是藍綠發布，即先新起服務，等新的服務健康檢查通過后，在殺 ...
2021-05-31 17:41 0 1115 推薦指數：
相關推薦
一次線上問題引發的對於C#中相等判斷的思考
線上報來一個問題，說用戶的數據丟失了。開發經過緊張的調查。終於找到了原因。 問題出在了 if 中的比較上。 values[rowIndex] 中保存的是一個整數，開發認為兩個整數比較實用 == 就可以了。 但是 values[rowIndex] 中的整數 ...
一次線上Redis類轉換異常排查引發的思考
之前同事反饋說線上遇到Redis反序列化異常問題，異常如下： 已知信息如下： 該異常不是必現的，偶爾才會出現； 出現該異常后重啟應用或者過一會就好了； 序列化協議使用了hessian。 因為偶爾出現，首先看了報異常那塊業務邏輯是不是有問題，看了一遍也發現 ...
從一次線上故障思考Java問題定位思路
問題出現：現網CPU飆高，Full GC告警 CGI 服務發布到現網后，現網機器出現了Full GC告警，同時CPU飆高99%。在優先恢復現網服務正常后，開始着手定位Full GC的問題。在現場只能夠抓到四個GC線程占用了很高的CPU，無法抓到引發Full GC的線程。查看了服務故障期間的錯誤 ...
由一次 symbol lookup error 引發的思考
開發一個跨平台的項目的時候，大部分時候都是在VS下進行編碼，所以也就使用了VS的解決方案來管理項目。 因為要跨平台，當時網上看scons這個工具不錯，所以在linux下就使用了scons來作為編譯腳本 ...
Dubbo的優雅下線原理分析
文/朱季謙 Dubbo如何實現優雅下線？ 這個問題困擾了我一陣，既然有優雅下線這種說法，那么，是否有非優雅下線的說法呢？ 這，還真有。 可以從linux進程關閉說起，其實，我們經常使用到殺進程的指令背后，就涉及到是否優雅下線的理念。 在日常開發當中，經常用到kill來關掉正在運行的進程 ...
記一次線上dubbo服務超時和線程池滿問題排查
線上某dubbo服務A調用dubbo服務B的接口X方法，調用端A日志中出現了很多超時的情況，提供端B該接口X超時時間設置為60s； 查看提供端B的日志，報了很多線程池滿的異常： 服務B部署了4個節點，僅1個節點有線程池滿情況； 服務B的dubbo配置如下，線程池固定700個線程 ...
記一次一個枚舉引發線上事故風暴
背景 2018年8月15號下午6點左右一個我們服務的調用方通知我們他們在調用服務接口時出現了大量的異常和通知,並且錯誤返回值都是“顯示未設置結束日期” 問題定位 收到調用方的消息后,我立即展開了問題的排查 1、通過服務管理平台查看服務是否出現超時及比對今天和昨天接口整體的響應 ...