故障排查實戰案例——某電器ERP系統日誌暴增

時間 2019-11-10

標籤故障排查實戰案例電器 erp 系統日誌暴增简体版

原文原文鏈接

前言

　　本篇文章寫在新春佳節前夕，也是給IT運維朋友一個警醒，在春節長假前請妥善體檢本身的系統安心過個年。數據庫

　　千里之堤毀於蟻穴，一條看似簡單的語句就能拖垮整個系統，您的SQL Server好久沒體檢了吧？就像一塊藏着刀片的蛋糕！怎能安度春節？運維

　　日誌暴增的問題處理過不少，這只是很常規的一次，可是對於不是很熟練的運維兄弟，可能日誌暴增這樣的問題會被一帶而過，或者解釋成突發狀況而不去處理，那麼隱患依然存在，在春節這樣的長假髮生可怎麼辦呢？工具

　　本文使用的工具：SQL專家雲平臺專業體檢工具：www.zhuancloud.com性能

場景描述

　　本案例是一個很成熟的ERP廠商的產品，接到用戶緊急電話，說他們日誌忽然暴增磁盤告警，50G的數據庫日誌已經達到200G。測試

　　看到這有的看官可能會說，確定是沒定時作日誌備份致使日誌不斷變大！或者說才200G 一點也不大呀！加密

　　沒錯，日誌不備份缺失會有這樣的問題，但這情景是小兒科，不會拿出來寫案例的，200G 確實也不大，但要分場景，在此客戶平均10個G 的場景下 200G已是爆炸式的問題了！3d

　　爲何會拿出來寫案例，就是由於想要告訴你們排查這樣問題的思路，不要讓這樣的暴增單純的說成突發狀況！日誌

問題分析

　　拿到收集文件我直入主題，查看日誌的增加狀況、寫入狀態、問題時間點等信息blog

　　在日誌的分配空間咱們瞭解到日誌是在11點43分左右忽然暴增一直增加到13點左右達到240G資源

　　分配空間也是一樣的狀況在11點43分左右暴增，後期在1點半的降低就是日誌備份讓使用空間被釋放。

　　日誌文件的寫入也符合這個時間點，在11點43分左右寫入達到40MB/秒，而且持續了1個多小時。

　　經過這幾張圖，咱們很清晰的就能定位到日誌暴增的時間點，下面只要找到對應時間點的語句便可！

　　個人排查思路有些不一樣，持續1個小時的寫入，必然伴隨着日誌文件的增加（文件增加設置固定值100MB），這裏須要提一下：這就是固定增加的好處，由於當達到240G 若是按照默認10%增加，那麼一次須要增24G 磁盤已經沒有那麼多空間，則會致使報錯，系統中斷！

　　回到排查思路，這裏我直接查看對應時間點系統的等待狀況：

　　直接找到日誌文件增加的等待類型，查看運行的語句確實運行時間是從11點15到13點15，和日誌增加的狀況吻合！！

　　就這樣，只花了10分鐘就定位到問題，找到語句，因爲存儲過程加密，我沒法看到裏面的代碼，可是暴增的語句已經找到，須要軟件廠商自行處理啦！！

　　就是這樣簡單，打完收工！因此不要放過這樣的問題排查！

後怕

　　爲何說不能放過這樣問題的排查！！！

　　首先，這個系統正準備上集羣，集羣你們都知道單機變多臺，必然涉及到數據的同步，同步是要有消耗的，對寫入的性能會有影響，細心的小夥伴可能已經看到這個語句消耗了多少資源，邏輯讀，寫，影響行數有多少了

　　沒錯，64億的邏輯讀！爲何會產生這麼大的日誌，致使暴增！由於寫入1億次，影響行數19億，而且執行的時間不是在夜間的維護期，而是在中午11點15開始，這麼大的處理在集羣方案部署的時候必定要高度警戒，這麼大的同步量徹底可能致使集羣嚴重延遲，甚至宕機！因此這不僅僅是一第二天志暴增問題的排查了，也是對系統功能更加細緻的瞭解，若是這樣的問題沒有及早發現，就算集羣后期測試也不必定會被測試到，進而致使集羣上線後的悲催。

PS:繼邏輯讀 23億，34億，45億後這個案例有刷新了我見過的最大邏輯讀 64億！

　　記念一下

--------------博客地址---------------------------------------------------------------------------------------

博客地址 http://www.cnblogs.com/double-K/

歡迎轉載，請註明出處，謝謝！

-----------------------------------------------------------------------------------------------------