精华内容
下载资源
问答
  • 对问题进行了排查
    千次阅读
    2022-02-20 12:52:36

    简介

      线上故障排查,是每个程序员必备的技能,为什么这么讲呢,因为项目上线后,不是随时都有条件debug,也不是随时都能查到对应的日志文件,有时关键位置也不一定打日志,这可太令人心痛了。甚至有时个别问题转眼即逝,我们需要一个完整的线上的排查过程,才能应对这些情况。
      线上故障众多,但其实也并不是无迹可循,也有一定的章法可言,一般无外乎CPU内存磁盘网络IO这几个方面的问题。所以我们的解决方案也简单:直接top、free、df等大锤开路,然后依次,jstack,jstat,jmap等小锤扣缝,最后具体问题具体分析即可。只要学会了这套流程,你遇到问题就不会开摆了。

    常用命令

      下面先介绍点常用的命令,之后再讲解具体的流程,免得你出了问题,jps、ps命令用一下,然后来回切目录,就不知道该干嘛了。

    top命令

    可以显示当前系统正在执行的进程的相关信息,包括进程ID、内存占用率、CPU占用率等。

    -b   		 批处理
    -c    		 显示完整的命令
    -I    		 忽略失效过程
    -s    		 保密模式
    -S    		 累积模式
    -d<时间>      设置间隔时间
    -u<用户名>    指定用户名
    -p<进程号>    指定进程
    -n<次数>      循环显示的次数
    

    在这里插入图片描述
    前五行是系统整体的统计信息,后面是统计信息区域,主要显示了各个进程的详细信息。
    使用示例:

    [root@localhost ~]# top               #显示系统进程信息
    [root@localhost ~]# top -b            #以批处理模式显示程序信息
    [root@localhost ~]# top -S            #以累积模式显示程序信息
    [root@localhost ~]# top -n 2          #设置信息更新次数,表示更新2次后终止更新显示
    [root@localhost ~]# top -d -3         #设置信息更新时间,表示更新周期为3秒
    [root@localhost ~]# top -p 1138       #显示进程号为1138的进程信息,CPU、内存占用率等
    

    vmstat 命令

    vmstat 报告虚拟内存的统计信息。

    -a:    显示活跃和非活跃内存
    -f:    显示从系统启动至今的fork数量 
    -m:    显示slabinfo
    -n:    只在开始时显示一次各字段名称
    -s:    显示内存相关统计信息及多种系统活动数量
    -d:    显示磁盘相关统计信息
    -p:    显示指定磁盘分区统计信息
    -S:    使用指定单位显示。参数有 k 、K 、m 、M ,分别代表1000、1024、1000000、1048576字节(byte)。默认单位为K(1024 bytes)
    -V:    显示vmstat版本信息
    

    使用示例:

    [root@localhost ~]# vmstat 2       #每二秒显示一次系统内存的统计信息
    [root@localhost ~]# vmstat 2 5     #每二秒显示一次系统内存的统计信息,总共5次
    [root@localhost ~]# vmstat -d      #显示磁盘信息
    

    free命令

    free 命令显示系统使用和空闲的内存情况,包括物理内存、交互区内存(swap)和内核缓冲区内存。

    -b     显示内存的单位为字节
    -k     显示内存的单位为 KB
    -m     显示内存的单位为 M
    -o     忽略缓冲区调节列
    -t     总和信息
    -s<时间>     每隔指定时间执行一次命令,单位为s
    -h     以可读形式显示容量,需要free -V显示版本大于3.3
    -V     版本信息 
    

    使用示例:

    [root@localhost ~]# free -s 3     #每3秒执行一次
    [root@localhost ~]# free -m       #以M为单位
    [root@localhost ~]# free -k       #以K为单位
    

    df命令

    报告文件系统磁盘空间的使用情况。

    -a    列出包括BLOCK为0的文件系统 
    -h    用常见的格式显示出大小(例如:1K 234M 2G) 
    -H    同上,但是这里的1k等于1000字节而不是1024字节 
    -i    用信息索引点代替块表示使用状况 
    -k    指定块大小等于1024字节来显示使用状况 
    -l    只显示本地文件系统使用状况 
    -m    以指定块大小等于1048576字节(1M)来显示使用状况 
    --no-sync    在取得使用信息前禁止调用同步 (default) 
    -P    使用POSIX格式输出 
    --sync    在取得使用信息前调用同步 
    -t    只显示指定类型(TYPE)的文件系统 
    -T    输出每个文件系统的类型 
    -x    只显示指定类型(TYPE)之外的文件系统.
    --help    输出该命令的帮助信息并退出 
    --version    输出版本信息并退出 
    

    使用示例:

    [root@localhost ~]# df       #列出各文件系统的磁盘空间使用情况
    [root@localhost ~]# df -ia   #列出各文件系统ionde使用情况
    [root@localhost ~]# df -T    #列出文件系统的类型
    [root@localhost ~]# df -h    #目前磁盘空间和使用情况 以更易读的方式显示
    [root@localhost ~]# df -k    #以单位显示磁盘的使用情况
    

    iostat命令

    可以提供更丰富的IO性能状态数据。

    -c      只显示CPU行
    -d      显示设备(磁盘)使用状态
    -k      以千字节为单位显示磁盘输出
    -t      在输出中包括时间戳
    -x      在输出中包括扩展的磁盘指标
    

    使用示例:

    [root@localhost ~]# iostat -d -k 1 10         #查看TPS和吞吐量信息
    [root@localhost ~]# iostat -d -x -k 1 10      #查看设备使用率(%util)、响应时间(await)
    [root@localhost ~]# iostat -c 1 10 			  #获取cpu部分状态值
    

    ifstat命令

    ifstat命令 就像iostat/vmstat描述其它的系统状况一样,是一个统计网络接口活动状态的工具。

    -l 		监测环路网络接口(lo)。
    -a 		监测能检测到的所有网络接口的状态信息。
    -z 		隐藏流量是无的接口,例如那些接口虽然启动了但是未用的
    -i 		指定要监测的接口,后面跟网络接口名
    -s 		等于加-d snmp:[comm@][#]host[/nn]] 参数,通过SNMP查询一个远程主机
    -h 		显示简短的帮助信息
    -n 		关闭显示周期性出现的头部信息
    -t 		在每一行的开头加一个时间戳
    -T 		报告所有监测接口的全部带宽
    -w  	用指定的列宽,而不是为了适应接口名称的长度而去自动放大列宽
    -W 		如果内容比终端窗口的宽度还要宽就自动换行
    -S 		在同一行保持状态更新(不滚动不换行)
    -b 		用kbits/s显示带宽而不是kbytes/s
    -q 		安静模式,警告信息不出现
    -v 		显示版本信息
    -d 		指定一个驱动来收集状态信息
    

    使用示例:

    [root@localhost ~]# ifstat -tT      #添加具体的时间和所有监测接口的全部带宽
    

    ps命令

    -a      显示所有终端机下执行的进程,除了阶段作业领导者之外
    -A      显示所有进程。
    -c      显示CLS和PRI栏位。
    -C<指令名称>      指定执行指令的名称,并列出该指令的进程的状况。
    -d      显示所有进程,但不包括阶段作业领导者的进程。
    -e      此参数的效果和指定"A"参数相同。
    -f      显示UID,PPID,C与STIME栏位。
    -g<群组名称>      此参数的效果和指定"-G"参数相同,当亦能使用阶段作业领导者的名称来指定
    -G<群组识别码>      列出属于该群组的进程的状况,也可使用群组名称来指定。
     h      不显示标题列。
    -H      显示树状结构,表示进程间的相互关系。
    -j      采用工作控制的格式显示进程状况。
    -l      采用详细的格式来显示进程状况。
     L      列出栏位的相关信息。
    -m      显示所有的执行绪。
     n      以数字来表示USER和WCHAN栏位。
    -N      显示所有的进程,除了执行ps指令终端机下的进程之外。
    -p<进程识别码>      指定进程识别码,并列出该进程的状况。
    p<进程识别码>      此参数的效果和指定"-p"参数相同,只在列表格式方面稍有差异。
     r      只列出现行终端机正在执行中的进程。
    -s<阶段作业>      指定阶段作业的进程识别码,并列出隶属该阶段作业的进程的状况。
    s      采用进程信号的格式显示进程状况。
     S      列出进程时,包括已中断的子进程资料。
    -t<终端机编号>      指定终端机编号,并列出属于该终端机的进程的状况。
    -T       显示现行终端机下的所有进程。
    -u<用户识别码>      此参数的效果和指定"-U"参数相同。
    -U<用户识别码>      列出属于该用户的进程的状况,也可使用用户名称来指定。
     v      采用虚拟内存的格式显示进程状况。
    -V      显示版本信息。
    -w      采用宽阔的格式来显示进程状况。 
    -x      显示所有进程,不以终端机来区分。
    -y      配合参数"-l"使用时,不显示F(flag)栏位,并以RSS栏位取代ADDR栏位
    

    使用示例:

    [root@localhost ~]# ps aux --sort=-pcpu,+pmem      #CPU或者内存进行排序,-降序,+升序
    [root@localhost ~]# ps -e -o pid,comm,etime        #显示进程运行的时间
    [root@localhost ~]# ps -aux | grep named           #查看named进程详细信息
    

    jps命令

    jps 可以列出本机所有Java进程的pid 。

    -q      仅输出VM标识符,不包括class name,jar name,arguments in main method 
    -m      输出main method的参数 
    -l      输出完全的包名,应用主类名,jar的完全路径名 
    -v      输出jvm参数 
    -V      输出通过flag文件传递到JVM中的参数(.hotspotrc文件或-XX:Flags=所指定的文件 
    -Joption      传递参数到vm,例如:-J-Xms48m
    

    使用示例:

    [root@localhost ~]# jps      #列出本机所有Java进程的pid 
    [root@localhost ~]# jps -m   #列出本机所有Java进程的pid和main method
    

    jstack

    jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。

    -F      当进程挂起,执行jstack <pid> 命令没有任何输出后,将强制转储堆内的线程信息
    -m      在混合模式下,打印 java 和 native c/c++ 框架的所有栈信息
    -l      长列表。打印关于锁的附加信息,例如属于 java.util.concurrent 的 ownable synchronizers 列表
    -h      打印帮助信息
    

    使用示例:

    [root@localhost ~]# jstack -m 88888 >1.txt     #将 java 和 native c/c++ 框架的所有栈信息输出到文件
    [root@localhost ~]# jstack -l 88888 >1.txt     #将堆栈信息输出到文件
    

    jstat

    利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控。

    –class      		监视类装载、卸载数量、总空间及类装载所耗费的时间
    –gc      			监视Java堆状况,包括Eden区、2个Survivor区、老年代、永久代等的容量
    –gccapacity         监视内容与-gc基本相同,但输出主要关注Java堆各个区域使用到的最大和最小空间
    –gcutil      		监视内容与-gc基本相同,但输出主要关注已使用空间占总空间的百分比
    –gccause      		与-gcutil功能一样,但是会额外输出导致上一次GC产生的原因
    –gcnew      		监视新生代GC的状况
    –gcnewcapacity      监视内容与-gcnew基本相同,输出主要关注使用到的最大和最小空间
    –gcold      		监视老年代GC的状况
    –gcoldcapacity      监视内容与-gcold基本相同,输出主要关注使用到的最大和最小空间
    –gcpermcapacity     输出永久代使用到的最大和最小空间
    –compiler      		输出JIT编译器编译过的方法、耗时等信息
    –printcompilation   输出已经被JIT编译的方法
    

    使用示例:

    [root@localhost ~]# jstat -class  15224  1000 10  -class      #显示加载class的数量,及所占空间等信息
    [root@localhost ~]# jstat -gcutil 5061  1000 2000   -gcutil   #统计gc信息
    

    jmap

    jmap命令可以获得运行中的jvm的堆的快照,从而可以离线分析堆,以检查内存泄漏等问题。

    -dump     			 输出jvm的heap信息
    -finalizerinfo    	 打印正等候回收的对象的信息.
    -heap      			 打印heap的概要信息,GC使用的算法,heap的配置及wise heap的使用情况.
    -histo[:live]      	 打印每个class的实例数目,内存占用,类全名信息
    -permstat      		 打印classload和jvm heap长久层的信息. 
    -F     				 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效. 
    -h       			 打印辅助信息 
    -J      			 传递参数给jmap启动的jvm. 
    

    使用示例:

    [root@localhost ~]# jmap -histo 4939      #打印每个class的实例数目,内存占用,类全名信息
    

    jinfo命令

    可以打印出java进程的配置信息:包括jvm参数,系统属性等。

    no option      	 打印命令行参数和系统属性
    -flags      	 打印命令行参数
    -sysprops        打印系统属性
    -h       		 帮助
    

    使用示例:

    [root@localhost ~]# jinfo xxxx          #打印命令行参数和系统属性
    [root@localhost ~]# jinfo -flags xxxx   #打印命令行参数
    

    解决思路

      现在我们来讲一下出现问题的解决思路,现在有一个Java服务崩了,但没完全崩的情况下,你进入服务器终端,应该会卡,或者慢。这时,我们即需要在系统层面排查一次,还要在Java应用方向再排查一次,最后对症下药

    • 系统层面的排查主要有:CPU内存磁盘网络IO
      用到的命令主要有:top、vmstat、free、df、iostat、ifstat、ps,这些命令都查一遍,你就知道是以上哪个方向出问题了,再用Java自带的命令做进一步分析。
    • Java应用方向主要有:死循环频繁gc上下文切换过多OOMStack Overflow内存泄漏
      用到的命令主要有:jps、jstack、jstat、jmap、jinfo,主要结果系统层面的问题,再做进一步的分析。

      相对系统层面,Java应用方向的问题比较多,且杂,但我们可以确定一点的是:不管是什么应用层问题,只要威胁到我们的系统,它一定会表现在CPU、内存、磁盘、网络、IO上。 比如, “死循环” 、 “频繁gc” 和 “上下文切换过多” 会导致CPU压力过大,“OOM”、“Stack Overflow”、“内存泄漏” 会导致内存压力过大,而其它的一些问题会影响到磁盘、网络和IO问题,比如日志太多,磁盘堆满,带宽占用过多,导致网络卡顿等。

    示例:CPU占用过高检查过程

    • 通过top、free、df、iostat、ifstat命令发现,其它资源占用不多,但CPU占用过多,爆满,怀疑是CPU占用过高问题。
    • 通过 top 命令找到 CPU 消耗最高的进程,并记住该进程 ID。
    • 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID,并记住线程 ID。
    • 通过 JDK 提供的 jstack 工具 dump 线程堆栈信息到指定文件中。具体命令:jstack -l [进程 ID] > jstack.log。
    • 由于刚刚的线程 ID 是十进制的,而堆栈信息中的线程 ID 是16进制的,因此我们需要将10进制的转换成16进制的,并用这个线程 ID 在堆栈中查找。使用 printf “%x\n” [十进制数字] ,可以将10进制转换成16进制。
    • 通过刚刚转换的16进制数字从堆栈信息里找到对应的线程堆栈。就可以从该堆栈中看出端倪,接下来改成就是Java代码层面的事了。
    更多相关内容
  • 当前进程的所有的socket句柄、连接的端口如何看等这些恼人的问题,通过阅读"使用netstat命令进行网络问题排查的诀窍",就可以立马找到解决新问题的答案。 本文包含了10个典型的问题及netstat的实际使用方法、实际...
  • JVM内存问题排查

    2021-01-09 08:38:55
    初步诊断思路考虑是不是这台机器上的某个服务把内存撑爆了,所以开始排查内存问题,使用jdk自带脚本,进行内存诊断分析。 1.查看所有Java应用占用的进程(linux常用的是ps -ef|grep java) jps -l 2.查看需要监控...
  • KAFKA问题排查

    千次阅读 2021-11-29 15:17:58
    二、排查问题 1、33环境不能用topic能用,tcp报错如下图 (1)验证kafka是否可用 开启一个生产者和消费者查看kafka是否正常,如下 路径:cd /usr/local/kafka/1/bin 生产者:sh kafka-console-...

    *遇到kafka的问题千万不要直接删除kafka-manager里的topic,会导致topic不能再使用,首先需要确认kafka是否可用*

    一、部署机器

    • test33-1
    • test34-2
    • test35-3

    二、排查问题

    1、33环境不能用topic能用,tcp报错如下图

    (1)验证kafka是否可用

    开启一个生产者和消费者查看kafka是否正常,如下

    路径:cd /usr/local/kafka/1/bin

    生产者:sh kafka-console-producer.sh --broker-list 10.30.200.155:15386 --topic CAR_NEARBY_DRIVER

    消费者:sh kafka-console-consumer.sh --bootstrap-server 10.30.200.155:15386  --topic CAR_NEARBY_DRIVER --new-consumer

    生产者:

    消费者:

    如上情况是正常的,如果不正常建议首先重启kafka集群

    kafka.1.server restart

    2、topic误删导致无法使用topic

    如果误删了topic简单的重新创建是无法修复问题的,就需要进行一次彻底的删除,重启集群,再次重新创建topic,

    删除zk的topic节点

    路径:cd /usr/local/zookeeper/1/bin

    指令:sh zkCli.sh -server {zkAndPort}

    rmr /config/topics/{topicName}

    rmr /brokers/topics/{topicName}

    清除集群各个broker下面的以下目录的topic文件,集群中的三台机器都需要操。

    路径:cd /ccdata/kafka/1/kafka-logs/

    删除:rm {topicName}*

    查看:ls {topicName}*

    重启集群,待重启完成后可以重新创建topic

    路径:cd /usr/local/kafka/1/bin

    创建:sh kafka-topics.sh --create --zookeeper {zkAndPort} --replication-factor 1 --partitions 3 --topic {topicName}

    测试topic是否可用

    生产者:sh kafka-console-consumer.sh --bootstrap-server {kafkaAndPort} --topic {topicName} --new-consumer

    消费者:sh kafka-console-producer.sh --broker-list {kafkaAndPort} --topic {topicName}


    3、以上就是一次简单排查kafka的问题流程

    操作时需要注意切换对应环境:1-33,2-44。

     

    消息消费不到场景问题排查:

    CSDNicon-default.png?t=LA92https://mp.csdn.net/mp_blog/creation/editor/121610894

    展开全文
  • 排查线上问题的9种方式

    千次阅读 2022-03-31 00:11:16
    一次,美国著名的福特公司的一组电机发生故障,在束手无策之时,公司请斯坦门茨出马解决问题。斯坦门茨在电机旁仔细观察,经过计算,用粉笔在电机外壳划了一条线,说:“从这里打开,把里面的线圈减少16圈。”工人们...

    德国科技管理专家斯坦门茨早年移居美国,他以非凡的才能成为美国企业界的佼佼者。一次,美国著名的福特公司的一组电机发生故障,在束手无策之时,公司请斯坦门茨出马解决问题。

    斯坦门茨在电机旁仔细观察,经过计算,用粉笔在电机外壳划了一条线,说:“从这里打开,把里面的线圈减少16圈。”工人们照他说的一试,电机果然运转如初,福特公司给他酬金时,他索价一万美元。

    公司老板觉得一条线要一万美元未免漫天要价。斯坦门茨回答:“用粉笔划一条线一美元,而知道在哪里划要9999美元。”公司老板认为言之有理,乃照付一万美元。

    这个励志故事告诉咱们要懂得如何排查问题的重要价值。今天咱们就来总结一下排查问题的9种方法:

    基础方法

    监控告警

    b964d469b0f93325264287094c9ca3c5.png

    问题发生常用的手段有生产测试、监控告警和人工客诉。人工客诉是咱们最不愿意看到的,那就需要在产生业务影响前及早发现。监控告警是发现问题的有效手段,具体可以参考《通知&告警治理(降噪)的7种方法》这篇文章。

    日志埋点

    埋点是了解用户行为的重要步骤,但更重要的目的是识别用户的关键路径。注入特定的代码以记录关键指标是提升应用性能的重要步骤。

    日志和埋点之间存在着细微的差别。埋点可以看作是日志的子集。被埋点的任何数据都应该记录在日志中。

    埋点承担了为聚合分析发布关键性能数据的职责,日志则提供了用户在不同级别跟踪应用的细节信息,从低到高依次为:

    • Verbose:几乎提供了所有的细节,主要用于跟踪执行过程中控制流

    • Debug:表示数据主要用于调试

    • Info:表示非错误信息

    • Warning:表示可恢复的错误

    • Error:表示不可恢复的错误

    日志的记录会贯穿应用的整个生命周期,而埋点只应该用在开发的特定阶段。通过埋点,可以把特定类型或有有价值的信息素材收集起来,基于这些素材可以做非常多的有价值的分析、追踪。

    问题复现


    这个不用多解释,聊聊复现的步骤:

    ● 确保所有的步骤都被记录。记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤,可能导致无法再现软件缺陷。在尝试运行测试用例时,可以利用录制工具确切地记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的。

    ● 特定条件和时间。软件缺陷仅在特定时刻出现吗?软件缺陷在特定条件下产生吗?产生软件缺陷是网络忙吗?在较差和较好的硬件设备上运行测试用例会有不同的结果吗?

    ● 压力和负荷、内存和数据溢出相关的边界条件。执行某个测试能导致产生缺陷的数据被覆盖,而只有在试图使用脏数据时才会再现。在重启 BUG 复现方法总结机器后,软件缺陷消失,当执行其他测试之后又出现这类软件缺陷,需要注意某些软件缺陷可能是在无意中产生的。

    ● 考虑资源依赖性包括内存、网络和硬件共享的相互作用等。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现?软件缺陷可能最终证实跟硬件资源、网络资源有相互的作用,审视这些影响有利于分离和再现软件缺陷。

    ● 不能忽视硬件。与软件不同,硬件Hi按预定方式工作。板卡松动、内存条损坏或者CPU过热都可能导致像是软件缺陷的失败。设法在不同硬件不再现软件缺陷。在执行配置或者兼容性测试时特别重要。判定软件缺陷是在一个系统上还是在多个系统上产生。

    抓包分析

    tcpdump命令配合Wiresshark等解析工具可对网络问题做初步的排查。比如http请求是明文传输,可以抓到完整的请求内容。但是如果是加密的,至少可以看到有没有RST等异常。或者原本应该观察的到返回包有没有,判断是哪个链路出的问题。

    83da6cbef23a927acf88d2a84c152fa8.png

    这需要对网络知识有比较深的了解。可通过《网络通信知识地图》进行学习,特别是《白话TCP/IP原理》要了解。

    高危方法

    linux命令

    有点命令危险性不高,比如TOP,使用方法可参考:《时刻掌握系统运行状态-深度理解top命令》。但是在线上不能随便用。比如程序正在写一个文件,这时候用命令行执行vim,可能导致fd文件描述符失效。关于文件描述符可参考《白话linux操作系统原理》或《趣谈IO多路复用的本质》。

    感兴趣的朋友甚至可以自己实现一下fd文件描述符失效:

    第一步:进程打开日志文件,使用lsof -p pid

    第二步:vim没打开文件前(或者打开vim没进行wq保存)

    第三步:当vim 修改文件后wq时,会提示

    0a66bb4b8c2700e3202bef277329a73e.png

    提示文件在读期间被修改了,我们选择yes

    第四步:此时再使用lsof -p pid命令来查看打开的文件描述符,进程打开的文件描述符的状态变为了deleted状态。

    linux命令可以作为排查问题的利器,比如我在《懂得三境界-使用dubbo时请求超过问题》里提到的netstat -s ,但是要注意不要对线上造成影响。

    下面用图来总结常用命令使用场景,图小需要手工放大看:

    efed3fef3a1b66462063a0934087af1f.png

    481e72f585ed044e2447b20228e4413b.png

    3b938b77e158a2e670e5380b19564bd2.png

    留后门法

    很久之前我们使用Redis,但是管理端做的不太好,我就在程序里留了后门:可以通过http接口对Redis的进行增删改查操作。但是用http接口做管理,意味着没有标准的权限控制和操作标准流程,很容易受到攻击或者误操作。

    更正统的方法是用标准的运维工具代替这些后门。

    线上调试

    举个例子,有次我们在进行测试环境演练,出现了个怪异的问题。后来有同事说其他一个同事也在用这个环境做调试,所以才会调用哪个接口的地方卡住,出现问题。这种问题要是出现在线上,就是故障了。

    高级方法

    代码走查

    排查问题的最高境界是只通过review代码来发现问题

    逻辑推理

    但很多大神的解决步骤是:第一,听别人讲述问题现象;第二,提出问题以求证;第三,推理出大致原因并给出可选方案及方案的注意点;第四,自己、更多情况下是他人进行验证。为啥是他人,能达到这种境界多是领导或者帮别人排查问题的救火队长,问题发生和自己并没有直接关系。

    想达到这种境界还是需要平时的积累和深入理解和深耕。源码和网络知识学起来~~

    总结

    一张图总结今天介绍的方法:

    0e81253c75d798da7fdbdddf2d7200bb.png

    编程一生

    因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。

    PDCA方法论,检查自己是否错过更新:每周三晚上8点左右,我都会更新文章,如果你没有收到,记得点开【编程一生】公众号找一下(*^▽^*)。

    展开全文
  • MySQL的内存和相关问题排查

    千次阅读 2021-01-28 08:26:58
    文件系统缓存 默认情况下,Linux将使用文件系统会所有的I/O操作进行缓存(这是不建议使用MyISAM的原因之一,MyISAM存储引擎依赖于FS缓存,并且可能导致丢失数据)。Mysql InnoDB引擎中使用O_DIRECT作为innodb_...

    我们都知道数据库是IO密集型一类应用,为了提高其性能大量使用内存代替文件(交换分区)的IO操作是保证数据库稳定、高效的基本原则。那么数据库是如何使用内存的,我们如何查看数据库内存的占用,如何通过通过数据库内存配置设置提高其性能?本文虫虫就以Mysql数据库(InnoDB引擎)为例和大家一起了解下Linux数据库和内存相关的主题。

    e3afe63334837e19ea99e43061fea8f3.png

    读取内存数据非常快,为了提高性能我们要尽最大可能把数据集都放到内存中以保证高效。但是Swap交换分区作为一个救命的稻草,我们还必须要给mysql设置,防止突发情况下内存不够,mysql服务直接被OOM杀掉的情况。同时mysql交换分区占用也是我们衡量一个数据是否健康与否的手段,如果一个数据库频繁的使用了swap则说明,我们需要人工干预优化数据库了。

    内存占用

    在Linux下,我们可以通过使用一些shell命令来了解MySQL的内存使用情况。

    首先使用ps命令来查看mysqld进程的内存使用情况:

    ps -eo size,pid,user,command --sort -size|grep mysqld

    |awk '{hr=$1/1024;printf("%13.2f MB",hr)} {for (x=4;x<=NF;x++){printf("%s",$x)}print ""}'

    |cut -d "" -f2|cut -d "-" -f1

    54213dbd0af0ad3abeddcc8e81247037.png

    MySQL的内存和相关问题排查

    1990.88 MB/usr/local/mariadb/bin/mysqld

    0.49 MB/bin/sh/usr/local/mariadb/bin/mysqld_safe

    top命令也可以查看对应上面的结果也可以用top来得到:

    top -b -o %MEM -n1 -p $(pidof mysqld) | grep PID -A

    78d6de9cb5eab4ef244c02be464f9fbe.png

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

    2239 mysql 20 0 2108536 316836 7548 S 0.0 4.0 48:47.37 mysqld

    其中,VIRT(virtual memory usage)表示mysql使用的虚拟内存总量。它包括所有代码,数据和共享库以及最终要被置换出的页面。

    RES(resident memory usage) 常驻内存,包括当前进程使用的内存,不包括置换出的内存。

    SHR(shared memory) 共享内存,进程使用的的共享内存,也包括其他进程的共享内存。

    交换分区

    我们再来检查检查mysqld是否正在使用交换分区,首先用free -m检查是否有用到交换分区。

    free -m

    5342674ae2dcca4223d7b5507b402d28.png

    MySQL的内存和相关问题排查

    total used free shared buff/cache available

    Mem: 7822 5091 178 83 2552 2290

    Swap: 3999 2 3997

    上面结果了,系统使用少量的交换分区(2M),那怎么判断是不是MySQL用的呢?我们来验证:

    cat /proc/$(pidof gitlab)/status | grep Swap

    279b4a5d3f357167bf6c70e55e90272d.png

    VmSwap:0 kB

    可见mysqld不没用用到交换区,说明我的mysqld在高效运行中。

    这儿我们提供一个脚本,遍历每一个进程,找出那些进程使用了交换分区:

    for i in $(ls -d /proc/[0-9]*)

    do

    out=$(grep Swap $i/status 2>/dev/null)

    if [ "x$(echo $out | awk '{print $2}')" != "x0" ] && [ "x$(echo $out | awk '{print $2}')" != "x" ]

    then

    echo "$(ps -p $(echo $i | cut -d'/' -f3)

    | tail -n 1 | awk '{print $4'}): $(echo $out | awk '{print $2 $3}')"

    fi

    done

    e449325701c4161b0e11e4cec1ae51e1.png

    当然,交换中的页面可能已经存在很长时间了,自从使用一次后,后面就没有在用过。为了获取实时交换分区情况,我们可以用vmstat:

    vmstat 1 10

    c7efef4ad5fbb78d1b0b7121a5922740.png

    在这个服务器上,我们可以看到mysqld没有使用交换,如果系统内存充足,但是mysqld还占用了部分交换分区,是怎么回事?怎么排查呢?

    如果遇到这种情况,可能的直接原因有swappiness和Numa。

    Swappiness

    swappiness参数控制内核将进程移出物理内存并将其放入交换磁盘分区的趋势。我们之前也说过了磁盘IO操作要比RAM慢很多很多,因此如果进程过于频繁地从内存中置换出,这会导致系统和应用程序的响应时间变慢。高swappiness值意味着内核更容易取消内存页面。低swappiness相反,内核将不太容易取消内存页面。swappiness值越高,系统内存置换的越多。

    linux下系统(CentOS、Red Hat、ubuntu)默认的swappiness值为60。如果内存较小则应适当调高这个值。对于内存足够的MySQL服务器,这个默认设置就有点太高了,应该减少。一般情况下,业界建议这个值可以设置到5.或者更小。设置swappiness方法是使用sysctl命令直接改变内核参数。

    sysctl -w vn.swappinness = 1

    NUMA设置

    还有一个方面就是NUMA设置。对于具有多个NUMA核心的服务器,建议将NUMA模式设置为交错,以平衡所有节点的内存分配。 在最新的MySQL 8.0中支持为InnoDB设置NUMA。可以在配置通过启动:innodb_numa_interleave = 1

    要检查是否有多个NUMA节点,可以使用numactl -H

    这是两种不同的输出:

    ea4305a48793bd0ff2d89ef3698b6e52.png

    我们可以看到,当有多个NUMA节点(下)时,默认情况下,内存不会在所有节点之间平均分配。这可以导致更多内存置换。

    文件系统缓存

    默认情况下,Linux将使用文件系统会对所有的I/O操作进行缓存(这是不建议使用MyISAM的原因之一,MyISAM存储引擎依赖于FS缓存,并且可能导致丢失数据)。Mysql InnoDB引擎中使用O_DIRECT作为innodb_flush_method,MySQL将绕过文件系统缓存,不会将任何FS Cache Memory用于数据文件(* .ibd)。

    当然在MySQL中使用的其他非数据文件仍会使用FS Cache。我们来看个例子:

    dbsake fincore binlog.000017

    binlog.000017: total_pages=120841 cached=50556 percent=41.84

    ls -lh binlog.000017

    -rw-r----- 1 mysql mysql 473M Sep 18 07:17 binlog.000017

    free -m

    total used free shared buffers cached

    Mem: 5965 4608 1356 128 435 2456

    -/+ buffers/cache: 1716 4249

    Swap: 2045 30 2015

    dbsake uncache binlog.000017

    Uncached binlog.000017

    # free -m

    total used free shared buffers cached

    Mem: 5965 4413 1552 128 435 2259

    -/+ buffers/cache: 1718 4247

    Swap: 2045 30 2015

    开始检查文件系统缓存中存在多少二进制日志(使用dbsake fincore),我们可以看到473M中有42%使用RAM作为FS缓存。然后我强制取消在缓存中使用这些页面(使用fincore uncache),结果,我们释放了+/- 195MB的RAM。

    上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

    展开全文
  • 网络问题常用排查方法

    千次阅读 2021-12-28 14:47:00
    网络问题常用排查方法 Window端 常用命令 ipconfig #查看本机ip ping XXX #ping ipv4地址,XXX为url或ip ping -6 XXX #ping ipv6地址,XXX为url或ip telnet XXX port #远程连接指定地址(ip可为ipv6地址),XXX为...
  • 本文总结一些常见的线上问题和对应的排查思路,工具。对于线上问题,我们必须记住一个原则:尽快恢复服务,消除影响。不管出于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题并不意味着必须在当下定位到...
  • 对于JVM服务可能出现的问题,我们一般依次排查内容为: (1). 宿主机器问题 (2). JVM内存,是否频繁GC (3). 线程栈,是否线程暴涨,线程死锁 (4). 排查日志,检查程序代码 解决思路: 1.宿主机问题 top...
  • 内存泄漏问题排查

    2021-12-28 13:48:51
    3、打开java控制台(命令jconsole),连接到该进程,切到“内存”tab页,点击右上角的“执行GC”按钮进行垃圾回收 4、重复步骤2,看下对象个数,一直增加不减少,和程序内部逻辑不一样的,就是内存泄漏的。 结合sort...
  • 本文详细讲述了实际项目中遇到的多个网络问题排查过程,以供参考!
  • 如何快速排查生产问题

    万次阅读 2021-07-30 09:10:18
    如何快速排查生产问题 大家都遇到过哪些生产问题呢 磁盘满了? CPU 飙高? 内存溢出? 内存溢出又分好几种: 堆内存溢出、 元空间溢出、 线程栈溢出、 直接内存溢出。 在 Netty 中,最常见的当属直接内存溢出了,...
  • Java服务问题快速排查指南

    千次阅读 2018-08-27 17:21:07
    问题 收到服务内存占用过大告警,登录虚拟机使用ps -ef发现每隔几秒java进程占用的CPU就回暴增一次 排查方向一:服务日志 查看服务日志,正频繁打印连接mail服务器失败,根据错误堆栈信息定位到业务代码位置 ...
  • Linux网络问题排查

    千次阅读 2021-12-06 17:15:27
    Linux网络问题排查网络不通网络速度慢网络排查思路 网络不通 如果是网络不通,要定位具体的问题,一般是不断尝试排除不可能故障的地方,最终定位问题根源。一般需要查看 是否接入到链路 ethtool eth0 是否启用了相应...
  • 线上项目频繁Full GC问题排查解决

    千次阅读 2021-09-16 10:39:04
    排查 1、首先查看GC日志,通过jstat -gcutil -t pid 1000 1000查看GC日志,看到FullGC的次数达到了接近两万次。。。并且GC速率没有下降的趋势。2、又通过jmap -heap pid查看堆内存情况,发现Old区Free剩余2M。。3、...
  • 网络不通问题排查

    千次阅读 2021-10-18 10:02:54
    网络不通问题排查基本思路如下:1、检查物理链路是否有问题。2、查看本机IP地址、路由、DNS的设置是否有问题。3、测试网关或路由器的通畅情况。先测网关然后再测路由器,一级一级地测试。4、测试ping公网ip的通畅...
  • 内存溢出问题排查操作

    千次阅读 2022-03-30 19:32:23
    内存溢出问题排查 1、内存溢出介绍 内存溢出(OOM)指的就是在应用系统中存在无法回收的内存或者使用的内存过多,最后是的程序运行要用到的内存大于能提供的最大内存,有时候需要重启软件甚至重启电脑才可以释放一部分...
  • 网格低速率问题分析及排查思路 1网格低速率路段优化思路 LTE 网络优化中在定位低速率问题时候首先要建立端到端的整 体性排查 识重点关注空口方面的问题 A 覆盖 问题排查 RSRP 电平值异常排查 定点测试时建议选择好点...
  • 记一次服务器响应慢问题排查

    千次阅读 2022-01-25 14:23:00
    这次问题查了一个星期,期间有点紧张,慌得一比,确定问题原因之前都是懵的。 1.发现日志里面有mysql连接超时(Communications link failure,The last packet sent successfully to the server was 0 milliseconds...
  • Java线上环境OOM问题排查

    千次阅读 2022-02-28 22:27:25
    这次跟大家分享的是如何解决线上环境OOM问题
  • 2、在本机cmd下,telnet IP+端口 (注:ip 后面是空格 + 端口号),如果通则万事大吉,如果不通,则进行排查方案 排查方案(如有新的排查方向,后续补上): 1.发现telnet不通的话,则考虑是否服务器防火墙的...
  • Java--线上问题排查--方法/步骤

    千次阅读 多人点赞 2021-10-29 23:40:08
    线上出问题时,我们需要进行详细排查,一般情况下,有以下场景我们可以得知线上出问题了: 请求很慢或者请求失败 监控系统的邮件或者短信提醒 线上排查步骤 以下按顺序进行 是否CPU占用过高 是否内存占用过高 ...
  • 一次mysql数据库性能问题排查记录

    千次阅读 2022-02-27 11:22:20
    目前项目上使用kafka+redis+mysql进行高速公路行驶车辆抓拍流水的存储,之前一直运行正常,但周五上午10点kafka突然出现消息积压,并且无缓解趋势。 二、排查过程 1、检查实时数据处理程序运行状况,发现单条数据...
  • Flink 常见问题排查与任务调优实践

    千次阅读 2021-12-11 07:54:15
    Flink 问题排查 - 作业部署失败 现象:作业无法正常提交与启动 可能成因 确认方法 解决措施 程序包依赖与集群依赖存在版本冲突 日志:NoSuchMethodError/ ...
  • 如何排查串口通信问题

    千次阅读 2022-04-07 11:04:23
    总是会遇到各种各样的通信问题,除了掌握软件知识,必要的硬件技能也必不可少,比如万用表、示波器、逻辑分析仪等,如此才能做到精准定位,早点打卡下班~~鱼鹰根据个人多年的嵌入式开发经验,在此斗胆总结一番,希望...
  • EPKS通用故障排查手册

    2022-06-30 19:54:37
    本文档详细介绍了Honeywell EPKS系统故障排查的方法,从排查思路到详细的操作问题、设置问题及系统管理问题的常见问题故障现象--> 检查方式-->解决方案等等。 本文档可以作为系统维护工程师及现场服务工程师和组态...
  • 服务器崩溃卡顿问题排查思路

    千次阅读 2021-07-11 19:51:48
    本文讲述了服务器崩溃、卡顿时的排查思路。 0x00 前言 0x01 常见崩溃问题 (1) 首先看CPU、内存、和磁盘空间占用是否异常 (2) Session文件过多 (3) 日志文件过多 0x01 域名解析 0x02 Nginx服务 0x03 PHP服务 0x04 ...
  • 线上java JVM问题排查

    千次阅读 多人点赞 2020-01-10 10:42:35
    下面是一个老系统,代码写的有点问题导致出现这样一个JVM占比过高的问题,正常情况下也就是CPU负载不高的时候21:00左右的,也有30万,但是再多一点30几万就是阈值,就会出现堆积。 这个队列一直是增长的快。 这...
  • 没想到说完这句话,我收到了一个问题反馈:某个页面的某个功能区块,用户点击了没反应。 并且配套的还有程序员经典名言:我这里是好的。 初步分析 预期情况:用户点击区块a,会根据服务端下发的url进行页面...
  • K8S集群中Pod资源常见问题排查思路以及处理方法

    多人点赞 热门讨论 2022-05-18 09:28:51
    K8S集群中Pod资源常见问题排查思路以及处理方法 文章目录K8S集群中Pod资源常见问题排查思路以及处理方法1.Pod资源的概念2.Pod资源常见问题排查思路 1.Pod资源的概念 对于Pod资源的核心概念以及配置详解,可以去...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 160,227
精华内容 64,090
热门标签
关键字:

对问题进行了排查