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
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
" 31218 ，然后根据16进制在堆栈日志里查找堆栈。
或则直接：
printf "%x
" 5858
16e2
jstack 5753|grep 16e2 -A 30
22、内存泄漏分析
（1）打开jvisualVM，打进入要分析的java进程的监视选项卡，点击 堆dump，生成C:Users
aAppDataLocalTempvisualvm.datlocalhost_31996heapdump-1590374952368.hprof文件。
（2）使用MemoryAnalyzer.exe （D: oolsMemoryAnalyzer-1.10.0.20200225-win32.win32.x86_64mat），双击打开
file -> open file 打开heapdump-1590374952368.hprof文件。进入 Leak Suspects，分析给出的Problem Suspect 点击进入Details，分析代码，查看各个类对象的个数。
（3）还可以点击 System Overview，查看系统使用内存情况以及各个线程使用内存情况和大对象的使用情况。
在linux 上根据进程号导出.hprof文件
jmap -dump:format=b,file=flink.hprof 31622
在linux上查看各个类的实例数和内存占用大小：
jmap -histo 6902
jmap -histo:live 6902 > xxx.log
23、查看GC
jstat -gcutil 6902 2000 10 6902为进程号，可以观察该进程的GC情况
jmap -heap pid:查看进程 新生代 老生代内存分配大小和使用情况。
jinfo pid ：查看进程 启动后 jvm各个参数设置，如堆大小 新老生代大小 数据区占用大小等。
nohup启动时指定 jvm参数：
nohup java -jar -server -Xms1g -Xmx1g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=30 -XX:+DisableExplicitGC -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/data/www/$project_name/online/logs/gc_log_8000.log ***.jar > javaxxx.log &
24、系统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之间的共享数据。