內存的crash記錄分析
服務器上線之后，發生了3次crash，感覺是一次比較典型的內存bug的排錯經歷，所以特地記錄下來供以后借鑒。下面描述一下3次crash時候的coredump的當前堆棧信息。 第一次crash的coredump文件： 從堆棧信息可以看出來，是邏輯一個函數在構造 ...
原文：linux的crash之hardlock排查記錄
. . 的內核，crash記錄如下： KERNEL: vmlinux DUMPFILE: vmcore PARTIAL DUMP CPUS: DATE: Wed Oct : : UPTIME: days, : : LOAD AVERAGE: . , . , . TASKS: NODENAME: host RELEASE: . . . . .el .x VERSION: SMP Fri Sep : ...
2017-10-23 10:06 0 2298 推薦指數：
相關推薦
linux 磁盤空間滿了，排查記錄
先貼命令：du -m --max-depth=1或du -h --max-depth=1du：用於統計linux中文件或目錄所占磁盤空間的大小du參數######-m：以M為單位展示查詢結果-h：以K、M、G為單位展示查詢結果，提高信息可讀性--max-depth=1：其中，數字“1”是指查詢 ...
linux 內核crash 命令
https://www.dedoimedo.com/computers/crash-book.html#download ...
linux crash 棧分析
dump xxx.so中的符號表, dump命令根據自己的需求選擇合適的： 1. 導出符號表命令1：./arm-himix200-linux-objdump -d /home/username/work/sample.so > /home/username/libxx_sample.txt ...
Linux 遭入侵，挖礦進程被隱藏排查記錄
今天來給大家分享下這兩天遇到的一個問題，服務器被挖礦了，把我的排查記錄分享下，希望能幫到有需要的同學。 問題原因 多台服務器持續告警CPU過高，服務器為K8s的應用節點，正常情況下CPU使用率都挺低的，通過排查是原因是被挖礦了，下面為定位過程 定位過程 登陸問題主機 ...
iOS運用fabric記錄crash日志過程
先前運用友盟記錄app閃退，發現有些閃退的記錄無法明確定位到詳細的位置，決定運用fabric進行閃退的記錄；網上也有這方面的記錄，有些細節的內容不明確，把今天碰到的坑整理記發不一下； 訪問官網地址(進行注冊賬號)： https://fabric.io 下載客戶端地址： https ...
記錄一次問題排查
1. 問題描述：早上剛來上班，業務部門同事反應管理后台無法登錄 2. 問題排查定位 2.1 服務器排查 a. 接口是否可以調通：首先自己登陸后台，發現時好時壞，偶爾接口返回【系統忙】。我們系統接口異常調不通會返回系統忙 b. 服務是否死掉或者假死：連接服務器->查看Java ...
Linux(2)---記錄一次線上服務 CPU 100%的排查過程
Linux(2)---記錄一次線上服務 CPU 100%的排查過程 當時產生CPU飆升接近100%的原因是因為項目中的websocket時時斷開又重連導致CPU飆升接近100% 。如何排查的呢 是通過日志輸出錯誤信息: 得知websocket時時重新 連接的信息,然后找到原因 解決 ...