linux常用命令及内存占用率高分析
1、查找文件
find ./ -name "*simulation*"
find ./ name "*bak" | xargs rm -f
find ./ name "*bak" | xargs rm -rf 递归删除
find / -name "application-dev.properties"
2、查找内容
grep -r test /usre/src 递归显示带test的行
grep -r 162.168.1.251 /
3、修改文件属性
chown -R sftp:sftpgroup opt/
chown sftp:sftpgroup test.txt
4、修改文件权限
chmod -R 777 opt/
-rwxrw-r-- 最前面的-代表文件 d代表目录
文字设定：
chmod ug + w o - x test.txt
5、查看用户 用户组
cat /etc/group
cat /etc/passwd
6、抓包命令
tcpdump -s o -i any port 18350 -V -W data.cap
strings data.cap >abc.txt
less abc.txt
截获主机hostname发送的所有数据 （eth0代表网卡）
tcpdump -i eth0 src host hostname
监视所有送到主机hostname的数据包
tcpdump -i eth0 dst host hostname
tcpdump host 199.177.1.4 and port 9092 -A
tcpdump src host 199.177.1.4 and port 9092 -A
7、查看系统日志 linux 重启信息 （最近谁登陆过在log下面的其他目录）
less /var/log/messages
8、
df -h 磁盘使用率
sudo du -sh * 查看当前目录下各个目录文件的磁盘使用空间
free 内存使用率
top cpu 使用率
9、查看端口监听情况
netstat -an|grep 18350
netstat -anltp|grep 27017
lsof -i:8542
10、查看进程
ps -ef|grep java
ps -fu XXX （XXX为应用名称）
11、新建用户和用户组
groupadd -g 202 dbgroup
useradd -u 2021 -d /home/db -g dbgroup -s /bin/csh -m db
passwd db
12、tar 包命令
tar -zcvf config.tar.gz config/
tar -zxvf config.tar.gz
13、如果一个单板你能ping通 但ssh连接不上：
cat /etc/hosts.deny 删除你的ip
cat /etc/hosts.allow 加上你的ip
14、windows文件转为linux文件
dos2unix xxx.sh
执行shell文件时，每行都报 commond not found时 就可能是这个问题。
15、 查看所有shells
cat /etc/shells
echo &SHELL 查看当前用户下的shell 若系统下没有安装csh，可以yum install csh 进行安装。
16、在文件里层层查找先要的内容
grep "bobe" *.txt | grep "20180512" |grep "cn >> result.txt
17、查看目录下文件的数量
ll | wc -l
18、root用户下修改单板时间
date -s "2019-10-01 12:04:39"
19、cpu 内存超高问题定位， 打印堆栈信息
（1）先用top命令查看进程
（2）top -H -p 25696 查看具体进程里子进程情况，找到使用较高的子进程
（3） jstack -l 21950 >> 123.txt 把进程的堆栈信息打印出来，把上面找到的使用内存最高的子进程即线程号转为16 位编码，根据16位编码在25698.txt里找对应的nid，查看具体堆栈信息。
20、前后台环境安装
前台： 在linux创建用户，安装jdk，安装tomcat，然后把maven打的前台包放在webapps下面即可。
后台：springboot启动的话，已经集成了tomcat。
创建用户，安装jdk，直接在项目里用maven 在父pom下打全量包，放在用户家目录下即可。
根据进程号查看具体进程:
ps -aux|grep 5584
21.cpu超高分析
（1）代码中有死循环或者接近死循环的操作
（2）快速创建大量临时变量，导致频繁触发gc回收，gc回收时jvm有停顿，CPU也占用很高
1、找到java的进程
ps -ef|grep xxx
2、查看具体进程里的信息 top -H -p 22423
3、打印进程的堆栈信息 jstack -l 22423 >> 6.txt
4、把2步骤里占用cpu最高的线程 转为16进制 printf "%x\n" 31218 ，然后根据16进制在堆栈日志里查找堆栈。
或则直接：
printf "%x\n" 5858
16e2
jstack 5753|grep 16e2 -A 30
22、内存泄漏分析
MemoryAnalyzer.exe工具使用说明：
（1）打开jvisualVM，打进入要分析的java进程的监视选项卡，点击 堆dump，生成C:\Users\wangna\AppData\Local\Temp\visualvm.dat\localhost_31996\heapdump-1590374952368.hprof文件。
（2）使用MemoryAnalyzer.exe （D:\tools\MemoryAnalyzer-1.10.0.20200225-win32.win32.x86_64\mat），双击打开
file -> open file 打开heapdump-1590374952368.hprof文件。进入 Leak Suspects，分析给出的Problem Suspect 点击进入Details，分析代码，查看各个类对象的个数。
（3）还可以点击 System Overview，查看系统使用内存情况以及各个线程使用内存情况和大对象的使用情况。
jvisualVM工具使用说明：
打开visualVM， 文件-》装入 选择hprof文件， 选择类 选项卡，可以按实例数排序查看各个类的实例个数，也可以在下面按类名收索单个类的实例个数。继续点击进去看 引用 ，可以看到该实例的引用。引用就是 new 对象时 自定义的对象名称， 常见的是在 map、list 中引用。
jmap 命令解析：
（1）在inux 上根据进程号导出.hprof文件：
jmap -dump:format=b,file=flink.hprof 31622
jmap -dump:live,format=b,file=xxx.hprof pid
（2）在linux上查看各个类的实例数和内存占用大小（即堆内存详细信息）：
jmap -histo 6902
jmap -histo:live 6902 > xxx.log
jmap -histo:live 6902|head -n 10>xxx.log 打印前10行
live的选项，实际上是产生一次Full GC来保证只看还存活的对象。有时候也会故意不加live选项，看历史对象。java有垃圾回收机制，不需要程序显示释放，jvm会自己出发GC，把没有引用的对象即非live的对象销毁。
从安全点日志看，从Heap Dump开始，整个JVM都是停顿的，考虑到IO（虽是写到Page Cache，但或许会遇到background flush），几G的Heap可能产生几秒的停顿，在生产环境上执行时谨慎再谨慎。
（3）查看进程的内存分配和使用情况（即堆内存概要信息）：
jmap -heap pid:查看进程 新生代 老生代内存分配大小和使用情况。
Heap Configuration: ##堆配置情况
Heap Usage: ##堆使用情况
（4）查看进程启动后 jvm各个参数设置
jinfo pid ：查看进程 启动后 jvm各个参数设置，如堆大小 新老生代大小 数据区占用大小等。
nohup启动时指定 jvm参数：
nohup java -jar -server -Xms48g -Xmx48g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=30 -XX:+DisableExplicitGC -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/ns5000sa/logs/gc_log_8000.log /home/XXX.jar > todbgc.log &
启动时指定初始化内存大小：
java -Xms48g -Xmx48g -jar /home/ns5000sa/XXX.jar >/dev/null &
23、查看GC
（1）jstat -gcutil 6902 2000 10 6902为进程号，可以观察该进程的GC情况
（2）java 程序打印垃圾回收情况:
启动参数加上：
-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/home/gclogs.log
flink打印垃圾回收情况:
bin 目录下
vi taskmanager.sh
export JVM_ARGS="${JVM_ARGS} -Xms${TM_HEAP_SIZE}M -Xmx${TM_HEAP_SIZE}M -XX:MaxDirectMemorySize=${TM_MAX_OFFHEAP_SIZE} -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/home/gclogs.log"
25、系统cpu、内存和io使用不高，但cpu等待队列较多负载较大的问题分析：
1、查看系统的等待队列 内存 cpu 和io等整体资源消耗命令
vmstat 1
2、查看各个进程的每秒上下文切换情况
pidstat -w 1
3、查看指定进程号每秒上下文切换情况：
pidstat -w -p 48863 1 10
3、找到切换频繁的进程后，查看该进程的上下文切换数
grep ctxt /proc/进程号/status
grep ctxt /proc/5743/status
voluntary_ctxt_switches: 4821 #自愿的上下文切换
nonvoluntary_ctxt_switches: 1 #非自愿的上下文切换
引起上下文切换的原因：
对于抢占式操作系统而言， 大体有几种：
当前任务的时间片用完之后，系统CPU正常调度下一个任务；
当前任务碰到IO阻塞，调度线程将挂起此任务，继续下一个任务；
多个任务抢占锁资源，当前任务没有抢到，被调度器挂起，继续下一个任务；
用户代码挂起当前任务，让出CPU时间；
硬件中断；
cswch/s: 每秒任务主动(自愿的)切换上下文的次数，当某一任务处于阻塞等待时，将主动让出自己的CPU资源。
nvcswch/s: 每秒任务被动(不自愿的)切换上下文的次数，CPU分配给某一任务的时间片已经用完，因此将强迫该进程让出CPU的执行权。
context switch过高会导致CPU像个搬运工，频繁在寄存器和运行队列之间奔波 ，更多的时间花在了线程切换，而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载，系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。
26、内存使用情况分析：
free m
(1)
Mem:内存的使用情况总览表。
totel:机器总的物理内存 单位为：M
used：用掉的内存。
free:空闲的物理内存。
注：物理内存(totel)=系统看到的用掉的内存(used)+系统看到空闲的内存(free)
我们平时看内存的使用也就看这些。
(2)从程序的角度分析
shared:多个进程共享的内存总和，当前废弃不用。
buffers：缓存内存数。
cached: 缓存内存数。
注：程序预留的内存=buffers+cached
buffers/cached可以分为两部分 + buffers/cached 和 - buffers/cached。
总的物理内存=|+ buffers/cached|+|- buffers/cached|；
- buffers/cached：程序角度上看已经使用的内存数，这才是程序实实在在用掉的内存数。
+ buffers/cached：程序角度上看未使用、可用的内存数。
小结
实际上来说，程序占用的真正内存就是：- buffers/cached 的数值。
所以看系统，真正已经用的内存数：used-(buffers+cached)的值。
真正未用到的内存数：free+buffers+cached 的值。
+buffers+cached是被程序预留的内存，其他的进程用不到另外一个进程预留的内存。
swap分区通常被称为交换分区，这是一块特殊的硬盘空间，即当实际内存不够用的时候，操作系统会从内存中取出一部分暂时不用的数据，放在交换分区中，从而为当前运行的程序腾出足够的内存空间。也就是说，当内存不够用时，我们使用 swap 分区可以把原本存放在buff和cache中的内容转移至硬盘中，这样腾出来的内存空间就可以给应用程序使用了，所以说buff和cache部分的内存，也可以认为是可用的内存。
缓存占用的内存可以手动释放出来：
先sync..同步下数据
echo 3 > /proc/sys/vm/drop_caches
