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\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
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
jstat -gcutil 6902 2000 10 6902為進程號，可以觀察該進程的GC情況
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