第十三篇：Linux常见命令

xnninger

已于 2024-06-21 10:35:34 修改

阅读量297

点赞数

分类专栏：肖哈哈java自学笔记文章标签： linux jvm java

于 2020-12-22 19:30:12 首次发布

本文链接：https://blog.csdn.net/xnninger/article/details/111499725

版权

肖哈哈java自学笔记专栏收录该内容

13 篇文章 22 订阅

订阅专栏

1. 如果系统突然变慢如何排查？

先看日志有没有报错，看CPU、内存使用情况，连接是否被耗尽了

2. CPU突然被打满了如何解决？

主要思路是找到是哪个线程占用着CPU资源，并查看线程堆栈看线程在干啥，然后解决问题

（1）查看进程id：top

（2）查看哪个线程占用CPU资源比较多：top -H -p 1154【H指的是占用CPU资源最大的在前边 p指的是通过进程号查询】

（3）把线程id转为16进制：printf "%0x" 1384【因为线程堆栈中的nid是PID的16进制表示】

（4）查看线程堆栈：jstack 1154 | grep -A 30 "0x568"【进程id为1154，线程id的16进制表示为0x568，-A 30 是之后的30行】

3. 内存满了如何排查？

（1）查看1154进程的gc状态，每2秒刷新一次：jstat -gcutil 1154 2000

（2）查看每次gc后内存使用率有没有降下来，有两种情况。

Case1：如果降下来了，但是很快又升上去了，说明有可能是QPS比较高，这时候需要扩容

Case2：如果没降下来，说明很有可能是内存泄漏导致的。

（3）针对case2:

先用jmap命令看一下内存中对象的占用大小(jmap -histo:live pid)，看能不能直接发现问题所在。

如果不能，就把dump文件下载下来，用分析软件进行分析（比如eclipse memory analyzer）。

（4）dump文件下载下来后，就要先让线上服务器可用，如果是刚上线了版本，就把服务器进行回滚；如果是很长时间没发版本，现在出现了问题，就重启服务

4. 查看端口的命令

netstat 查看端口

lsof -i tcp:[端口号] 查看是否被占用

5. 有没有遇到过线上问题？怎么解决的？

上传大excel内存溢出。

阶段性的出现接口超时。

一般情况下，线上问题的排查思路是：先看日志有没有报错，如果有的话就跟错误信息；用arthas进行线上排查问题。没有的话，看看CPU、内存使用情况，连接是否被耗尽了等等

堆溢出：

        上传一个非常大excel文件，每一行都转换成了java对象，然后又通过JSON.toJSONString()打印了出来。JSON.toJSONString()每次都会创建新对象，这就相当于在疯狂创建对象导致了堆内存溢出。

排查过程：

        先是接收到告警，内存直接被打满了，我们把日志文件保存下来后，先立即重启了服务，确保服务依然对客可用。然后在日志中发现有OOM，堆内存溢出，幸好我们jvm配置了自动保存dump文件，下载下来后用Eclipse Memory Analyzer进行了分析，发现String对象异常多，但其实程序中String对象就是很多，继续排查，发现还有一个对象占用空间很大，然后在程序中就找到了这个对象的使用位置，进而发现了问题。

最终解决：

        首先不要打印，其次大文件限制行数

内存调优：

发现经常会受到请求超过1秒的告警（正常200ms），也能正常返回就是耗时长，看了日志，也没有报错，然后到服务监控上看CPU和内存使用率也不是很高，想着可能是网络抖动，但是还是每天几乎都会收到告警。然后发现告警大多数是在业务高峰期的时候。

然后就去看了一下gc.log，发现young gc的时延在1秒多（full gc一秒正常，ygc 一秒过长），时间点也能和告警时间对齐。我们当时用的是CMS垃圾回收器，CMS的回收策略是最大程度清理内存空间，而且GC的时候会有Stop The World的情况，所以GC的时延高。

解决方案：

重点-控制每次gc时延，保证stw在可接受时间内，使用G1，可配置单次ygc的时延（最终配置的是500ms），G1会尽可能的保证gc时延不超过预期值。

使用Eureka有服务安全下线问题

Eureka会跟服务器之间保持心跳，三次心跳失败，就会把服务器节点拿掉。但是就有一个问题，服务下线和Eureka知晓之间的时间请求都会失败。

解决问题：
这个需要服务提供方来保证。Eureka服务端提供了一个接口，可以调用接口把服务器节点信息拿掉，服务下线前有一个回调钩子，可以在这个回调里边调用Eureka，先把节点信息拿到再shutdown服务，就可以保证服务安全下线。