目錄

這篇文章是在公司做了不少的線上Java服務故障排查和優化之後的一個總結，可以作為一個工具清單，在分析問題的時候需要有整體思路：全局觀，先從系統層面入手，大致定位方向（內存，cpu，磁盤，網絡），然後再去分析具體的進程。

一、Linux

內存和cpu

內存和cpu問題是出問題最多的一個點，因為有些命令如top同時可以觀察到內存和cpu所以放在一起。

top命令

常用參數： -H 打印具體的線程， -p 打印某個進程 進入后 按数字1 可以切換cpu的圖形看有幾個核

下面是我的測試環境shell:

top - 14:28:49 up 7 min,  3 users,  load average: 0.08, 0.26, 0.19
Tasks: 221 total,   2 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  3.4 sy,  0.0 ni, 91.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   985856 total,    81736 free,   646360 used,   257760 buff/cache
KiB Swap:  2094076 total,  1915196 free,   178880 used.   141592 avail Mem 

我一般重點關注的指標有：

%Cpu(s): 5.1 us, 3.4 sy, 0.0 wa

這裏可以非常直觀的看到當前cpu的負載情況，us用戶cpu佔用時間，sy是系統調用cpu佔用時間，wa是cpu等待io的時間，前面兩個比較直觀，但是第三個其實也很重要，如果wa很高，那麼你就該重點關注下磁盤的負載了，尤其是像mysql這種服務器。

load average: 0.08, 0.26, 0.19

cpu任務隊列的負載，這個隊列包括正在運行的任務和等待運行的任務，三個数字分別是1分鐘、5分鐘和15分鐘的平均值。這個和cpu佔用率一般是正相關的，反應的是用戶代碼，如果超過了內核數，表示系統已經過載。也就是說如果你是8核，那麼這個数字小於等於8的負載都是沒問題的，我看網上的建議一般這個值不要超過ncpu*2-2為好。

KiB Mem : 985856 total, 81736 free, 646360 used, 257760 buff/cache

內存佔用情況，total總內存，free空餘內存， used已經分配內存，buff/cache塊設備和緩衝區佔用的內存，因為Linux的內存分配，如果有剩餘內存，他就會將內存用於cache，這樣可以較少磁盤的讀寫提高效率，如果有應用申請內存，buff/cache這部分內存也是可用的，所以正真的剩餘內存應該是free+buff/cache

swap

線上服務器一般都是禁用狀態，所以不用看這項。

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

這一欄主要是看進程的詳情，重點是%CPU %MEM，上面看的是整個服務器的負載，這裡是每個進程的負載。還有看看S這個指標，這個代碼了進程的狀態，有時候有些進程會出現T（暫停）這個狀態。

網絡

ss

netstat的高性能版，參數都基本一致

常用參數： -n 打印数字端口號 -t tcp連接 -l 監聽端口 -a 所有端口 -p 進程號 -s 打印統計信息

ss -s示例：

Total: 1732 (kernel 1987)
TCP:   42373 (estab 1430, closed 40910, orphaned 2, synrecv 0, timewait 40906/0), ports 1924
Transport Total     IP        IPv6
*     1987      -         -        
RAW   18        9         9        
UDP   18        11        7        
TCP   1463      503       960     

可以看到整體的連接情況，如timewait過高，連接數過高等情況

然後使用ss -ntap|grep 進程號 or 端口號查看進程的連接

ping

查看時延和丟包情況

mtr

查看丟包請求

磁盤

磁盤問題在mysql服務器中非常常見，很多時候mysql服務器的CPU不高但是卻出現慢查詢日誌飆升，就是因為磁盤出現了瓶頸。還有mysql的備份策略，如果沒有監控磁盤空間，可能出現磁盤滿了服務不可用的現象。

iostat命令

常用參數： -k 用kb為單位 -d 監控磁盤 -x显示詳情 num count 每個幾秒刷新 显示次數

這個是我查看磁盤負載的主要工具，也可以显示cpu的負載，不過我一般用iostat -kdx 2 10,下面是我測試環境執行情況：

root@ubuntu:~# iostat -kdx 2 10
Linux 4.13.0-38-generic (ubuntu)    11/18/2018  _x86_64_    (1 CPU)
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              24.75   196.05  121.66    9.75  2481.33   961.29    52.40     0.44    3.33    1.12   30.95   0.51   6.71
scd0              0.00     0.00    0.02    0.00     0.08     0.00     7.00     0.00    0.25    0.25    0.00   0.25   0.00

我一般重點關注的指標有：

1. rkB/s和wkB/s: 分別對應讀寫速度
2. avgqu-sz: 讀寫隊列的平均請求長度，可以類比top命令的load average
3. await r_await w_await: io請求的平均時間（毫秒），分別是讀寫，讀和寫三個平均值。這個時間都包括在隊列中等待的時間和實際處理讀寫請求的時間，還有svctm這個參數，他說的是實際處理讀寫請求的時間，照理來講w_await肯定是大於svctm的，但是我在線上看到有w_await小於svctm的情況，不知道是什麼原因。我看iostat的man手動中說svctm已經廢棄，所以一般我看的是這三個。
4. %util: 這個參數直觀的看磁盤的負載情況，我首先看的就是這個參數。和top的wa命令有關聯。

df

查看文件系統的容量

常用參數： -h 友好的單位 如Kb，Mb等

du

統計具體的文件大小

常用參數： -h 友好的單位 如Kb，Mb等 -s 總計，而不是進入每個子目錄分別統計

場景：例如系統磁盤空間不足時，先通過df命令定位到具體的掛載目錄，在進去掛載目錄后，使用
du -sh *查看各個文件或者子目錄的大小定位具體文件

這裏還有ls命令，可以通過加-h和-S（按大小排序）

iostat命令

常用參數： -k 用kb為單位 -d 監控磁盤 -x显示詳情 num count 每個幾秒刷新 显示次數

這個是我查看磁盤負載的主要工具，也可以显示cpu的負載，不過我一般用iostat -kdx 2 10,下面是我測試環境執行情況：

root@ubuntu:~# iostat -kdx 2 10
Linux 4.13.0-38-generic (ubuntu)    11/18/2018  _x86_64_    (1 CPU)
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              24.75   196.05  121.66    9.75  2481.33   961.29    52.40     0.44    3.33    1.12   30.95   0.51   6.71
scd0              0.00     0.00    0.02    0.00     0.08     0.00     7.00     0.00    0.25    0.25    0.00   0.25   0.00

我一般重點關注的指標有：

1. rkB/s和wkB/s: 分別對應讀寫速度
2. avgqu-sz: 讀寫隊列的平均請求長度，可以類比top命令的load average
3. await r_await w_await: io請求的平均時間（毫秒），分別是讀寫，讀和寫三個平均值。這個時間都包括在隊列中等待的時間和實際處理讀寫請求的時間，還有svctm這個參數，他說的是實際處理讀寫請求的時間，照理來講w_await肯定是大於svctm的，但是我在線上看到有w_await小於svctm的情況，不知道是什麼原因。我看iostat的man手動中說svctm已經廢棄，所以一般我看的是這三個。
4. %util: 這個參數直觀的看磁盤的負載情況，我首先看的就是這個參數。和top的wa命令有關聯。

lsof

列出當前系統打開文件，因為在linux下一切皆是文件，連接，硬件等均被描述為文件，所以這個命令也十分有用。

常用參數：

1. -p 查看某個進程的文件
2. 直接加文件名 查看哪些進程打開了文件
3. +d 目錄 查看哪些進程打開了目錄以及下面的文件（不遞歸，+D是遞歸）

Sar
最後補充一個sar(System Activity Reporter)命令，如果系統沒有一個良好的監控，那麼這個命令對於排查問題是很好的補充，很多時候去排查問題的時候發現問題已經沒了，可以通過這個命令查看系統的活動情況，比如各個時間段cpu情況，內存情況。

常用參數：

1. -r 內存信息
2. -q loader信息，運行隊列情況
3. -u cpu信息
4. -W Swap換頁情況

/proc文件系統

/proc是個虛擬文件系統，是內核的一些數據，很多linux命令的都是通過解析/proc文件系統實現的，每個進程都會有一個以pid為目錄名的子目錄存在，通過解析/proc下的進程目錄可以得到很多進程的設置信息和資源佔用信息等。

這裏簡單說個排查過的問題，當時我們線上有個服務，正常ssh登錄的情況下,我們設置了ulimit中的open files為（進程可打開的最大描述符數量）100000，但是有一次在服務的日誌中發現有報錯說文件描述符不夠用。所以

二、JVM

java -XX:+PrintFlagsInitial 可以查看所以的jvm默認參數，其中帶有manageable表示運行時可以動態修改。

20:45 [root@centos]$ java -XX:+PrintFlagsInitial |grep manageable
     intx CMSAbortablePrecleanWaitMillis            = 100                                 {manageable}
     intx CMSTriggerInterval                        = -1                                  {manageable}
     intx CMSWaitDuration                           = 2000                                {manageable}
     bool HeapDumpAfterFullGC                       = false                               {manageable}
     bool HeapDumpBeforeFullGC                      = false                               {manageable}
     bool HeapDumpOnOutOfMemoryError                = false                               {manageable}
    ccstr HeapDumpPath                              =                                     {manageable}
    uintx MaxHeapFreeRatio                          = 70                                  {manageable}
    uintx MinHeapFreeRatio                          = 40                                  {manageable}
     bool PrintClassHistogram                       = false                               {manageable}
     bool PrintClassHistogramAfterFullGC            = false                               {manageable}
     bool PrintClassHistogramBeforeFullGC           = false                               {manageable}
     bool PrintConcurrentLocks                      = false                               {manageable}
     bool PrintGC                                   = false                               {manageable}
     bool PrintGCDateStamps                         = false                               {manageable}
     bool PrintGCDetails                            = false                               {manageable}
     bool PrintGCID                                 = false                               {manageable}
     bool PrintGCTimeStamps                         = false                               {manageable}

Java堆和垃圾收集器

java內存結構

堆內存結構：

java8元空間改動：

java 7種垃圾收集器：

常見搭配：

1. java8默認：Parallel Scavenge和 Parallel Old
2. 低延遲：ParNew和CMS
3. java8以後可以直接使用G1，參數比較簡單

ParNew

Serial的并行版本

Parallel Scavenge

注重的是吞吐量，吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集時間)，其具有自適應的特性

1. 控制最大垃圾收集停頓時間的-XX:MaxGCPauseMillis參數
   MaxGCPauseMillis參數允許的值是一個大於0的毫秒數，收集器將儘力保證內存回收花費的時間不超過設定值。不過大家不要異想天開地認為如果把這個參數的值設置得稍小一點就能使得系統的垃圾收集速度變得更快，GC停頓時間縮短是以犧牲吞吐量和新生代空間來換取的：系統把新生代調小一些，收集300MB新生代肯定比收集500MB快吧，這也直接導致垃圾收集發生得更頻繁一些，原來10秒收集一次、每次停頓100毫秒，現在變成5秒收集一次、每次停頓70毫秒。停頓時間的確在下降，但吞吐量也降下來了。

2. 直接設置吞吐量大小的 -XX:GCTimeRatio參數
   GCTimeRatio參數的值應當是一個大於0小於100的整數，也就是垃圾收集時間佔總時間的比率。如果把此參數設置為19，那允許的最大GC時間就佔總時間的5%（即1 /（1+19）），默認值為99，就是允許最大1%（即1 /（1+99））的垃圾收集時間。

3. UseAdaptiveSizePolicy開關參數
   -XX:+UseAdaptiveSizePolicy是一個開關參數，當這個參數打開之後，就不需要手工指定新生代的大小（-Xmn）、Eden與Survivor區的比例（-XX:SurvivorRatio）、晉陞老年代對象年齡（-XX:PretenureSizeThreshold）等細節參數了，虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或最大的吞吐量，這種調節方式稱為GC自適應的調節策略（GC Ergonomics）。

說說UseAdaptiveSizePolicy參數，加了這個參數-XX:SurvivorRatio會失效，所以有些人會發現新生代比例未如自己的預期，而UseAdaptiveSizePolicy有默認是開啟的

CMS

併發垃圾收集器，注重的是時延，有分配擔保失敗的風險

CMS收集器的GC周期由6個階段組成。其中4個階段(名字以Concurrent開始的)與實際的應用程序是併發執行的，而其他2個階段需要暫停應用程序線程。

初始標記：為了收集應用程序的對象引用需要暫停應用程序線程，該階段完成后，應用程序線程再次啟動。
併發標記：從第一階段收集到的對象引用開始，遍歷所有其他的對象引用。
併發預清理：改變當運行第二階段時，由應用程序線程產生的對象引用，以更新第二階段的結果。
重標記：由於第三階段是併發的，對象引用可能會發生進一步改變。因此，應用程序線程會再一次被暫停以更新這些變化，並且在進行實際的清理之前確保一個正確的對象引用視圖。這一階段十分重要，因為必須避免收集到仍被引用的對象。
併發清理：所有不再被應用的對象將從堆里清除掉。
併發重置：收集器做一些收尾的工作，以便下一次GC周期能有一個乾淨的狀態。

1. -XX:CMSInitiatingOccupancyFraction=90 （jdk1.5默認值68，1.6開始默認值92，指設定CMS在對內存佔用率達到70%的時候開始GC(因為CMS會有浮動垃圾,所以一般都較早啟動GC)
2. -XX:+UseCMSInitiatingOccupancyOnly 只是用設定的回收閾值(上面指定的70%),如果不指定,JVM僅在第一次使用設定值,後續則自動調整
3. -XX:+CMSScavengeBeforeRemark 在CMS GC前啟動一次ygc，目的在於減少old gen對ygc gen的引用，降低remark時的開銷
4. -XX:+CMSParallelRemarkEnabled 併發標記
5. -XX:+ExplicitGCInvokesConcurrent命令JVM無論什麼時候調用系統GC（system.gc()），都執行CMS GC，而不是Full GC
6. -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses保證當有系統GC調用時，永久代也被包括進CMS垃圾回收的範圍內
7. -XX：UseParNewGC 使用CMS時自動開啟，因為CMS不能和Parallel Scavenge搭配使用

上面的參數都建議開啟，CMS需要注意的一個問題就是CMSInitiatingOccupancyFraction參數，這個參數直接影響CMS回收老年代的時機，需要結合自己的業務場景來調整，一般情況下應該盡量設置大一點，但是有一個嚴重的問題，就是浮動垃圾的問題，如果CMS在併發收集的時候出現老年代不能存放晉陞對象將直接進行Full GC使用Serial Old垃圾收集器,所以不能一味追求最大化，如果老年代增長比較慢，那麼可以設置的稍微較大些，如果增長比較快，可以從增大新生代，調低CMSInitiatingOccupancyFraction入手

最後在提下-XX:+DisableExplicitGC ：禁用显示gc （system.gc()）這個參數，很多人因為system.gc()會導致Full gc而禁用显示調用gc，但是這個參數最好不要禁用，現在很多服務端程序都使用了Nio，jvm為了減少內存拷貝，採用了直接內存，直接內存屬於堆外內存，java大多使用了Netty這個框架，他幫我們處理堆外內存的回收，實現的機制就是通過調用system.gc()，發起Full Gc，Full Gc會回收堆外內存，如果將system.gc()禁用，則得等到Full Gc發生才能回收堆外內存，很有可能出現堆外內存佔用過高影響系統性能或者因為內存不足被系統Kill的問題。

gc日誌參數

1. -XX:+PrintGC 輸出GC日誌
2. -XX:+PrintGCDetails 輸出GC的詳細日誌
3. -XX:+PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式）
4. -XX:+PrintGCDateStamps 輸出GC的時間戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
5. -XX:+PrintHeapAtGC 在進行GC的前後打印出堆的信息
6. -XX:+PrintGCApplicationStoppedTime // 輸出GC造成應用暫停的時間
7. -Xloggc:../logs/gc.log 日誌文件的輸出路徑
8. -XX:+PrintTenuringDistribution 打印新生代的年齡分佈（這裏需要注意，如果使用的是Parallel Scavenge，那麼打印的時候是沒有年齡分佈信息的）
9. -XX:+UseGCLogFileRotation 開啟日誌輪換
10. -XX:NumberOfGCLogFiles=5 日誌保留數量
11. -XX:GCLogFileSize=10m 每份日誌保留大小

堆參數

1. -Xms 最小堆大小
2. -Xmx 最大堆大小
3. -Xmn 新生代大小
4. -XX:SurvivorRatio 新生代中Eden區與Survivor區的比例，默認值為8

gc日誌分析

ParNew Gc日誌：

{Heap before GC invocations=4196 (full 3):
 par new generation   total 1887488K, used 1683093K [0x0000000640000000, 0x00000006c0000000, 0x00000006c0000000)
  eden space 1677824K, 100% used [0x0000000640000000, 0x00000006a6680000, 0x00000006a6680000)
  from space 209664K,   2% used [0x00000006a6680000, 0x00000006a6ba5430, 0x00000006b3340000)
  to   space 209664K,   0% used [0x00000006b3340000, 0x00000006b3340000, 0x00000006c0000000)
 concurrent mark-sweep generation total 4194304K, used 1565111K [0x00000006c0000000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 59881K, capacity 64953K, committed 66588K, reserved 1107968K
  class space    used 6615K, capacity 7729K, committed 8224K, reserved 1048576K
2019-10-29T23:48:00.181+0800: 27966.548: [GC (Allocation Failure) 2019-10-29T23:48:00.181+0800: 27966.548: [ParNew
Desired survivor size 107347968 bytes, new threshold 15 (max 15)
- age   1:    2287832 bytes,    2287832 total
- age   2:     132752 bytes,    2420584 total
- age   3:     102408 bytes,    2522992 total
- age   4:     125768 bytes,    2648760 total
- age   5:     145464 bytes,    2794224 total
- age   6:      82808 bytes,    2877032 total
- age   7:     104736 bytes,    2981768 total
- age   8:      79216 bytes,    3060984 total
- age   9:      89496 bytes,    3150480 total
- age  10:      81864 bytes,    3232344 total
- age  11:      91304 bytes,    3323648 total
- age  12:      78912 bytes,    3402560 total
- age  13:      80960 bytes,    3483520 total
- age  14:      91560 bytes,    3575080 total
- age  15:      78992 bytes,    3654072 total
: 1683093K->5343K(1887488K), 0.0342117 secs] 3248204K->1570530K(6081792K), 0.0343754 secs] [Times: user=0.17 sys=0.01, real=0.03 secs]
Heap after GC invocations=4197 (full 3):
 par new generation   total 1887488K, used 5343K [0x0000000640000000, 0x00000006c0000000, 0x00000006c0000000)
  eden space 1677824K,   0% used [0x0000000640000000, 0x0000000640000000, 0x00000006a6680000)
  from space 209664K,   2% used [0x00000006b3340000, 0x00000006b3877f50, 0x00000006c0000000)
  to   space 209664K,   0% used [0x00000006a6680000, 0x00000006a6680000, 0x00000006b3340000)
 concurrent mark-sweep generation total 4194304K, used 1565186K [0x00000006c0000000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 59881K, capacity 64953K, committed 66588K, reserved 1107968K
  class space    used 6615K, capacity 7729K, committed 8224K, reserved 1048576K
}

gc日誌中打印了新生代，老年代和元空間等內存信息，其中Times: user=0.02 sys=0.01, real=0.01 secs三個時間分別是用戶態的時間，內核態的時間和牆鍾時間。牆鍾時間表示真正過去的時間，而用戶態和內核態的時間則是乘了相應的cpu核心數。

CMS GC日誌：

2019-10-29T18:03:19.578+0800: 7285.945: [GC (CMS Initial Mark) [1 CMS-initial-mark: 3182477K(4194304K)] 3254261K(6081792K), 0.0044508 secs] [Times: user=0.01 sys=0.01, real=0.00 secs]
2019-10-29T18:03:19.582+0800: 7285.949: [CMS-concurrent-mark-start]
2019-10-29T18:03:20.812+0800: 7287.179: [CMS-concurrent-mark: 1.229/1.229 secs] [Times: user=3.86 sys=0.46, real=1.23 secs]
2019-10-29T18:03:20.812+0800: 7287.179: [CMS-concurrent-preclean-start]
2019-10-29T18:03:20.823+0800: 7287.190: [CMS-concurrent-preclean: 0.011/0.011 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
2019-10-29T18:03:20.823+0800: 7287.190: [CMS-concurrent-abortable-preclean-start]
{Heap before GC invocations=896 (full 3):
 par new generation   total 1887488K, used 1747877K [0x0000000640000000, 0x00000006c0000000, 0x00000006c0000000)
  eden space 1677824K, 100% used [0x0000000640000000, 0x00000006a6680000, 0x00000006a6680000)
  from space 209664K,  33% used [0x00000006a6680000, 0x00000006aaae9780, 0x00000006b3340000)
  to   space 209664K,   0% used [0x00000006b3340000, 0x00000006b3340000, 0x00000006c0000000)
 concurrent mark-sweep generation total 4194304K, used 3182477K [0x00000006c0000000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 60431K, capacity 66281K, committed 66588K, reserved 1107968K
  class space    used 6828K, capacity 8138K, committed 8224K, reserved 1048576K
2019-10-29T18:03:25.649+0800: 7292.016: [GC (Allocation Failure) 2019-10-29T18:03:25.649+0800: 7292.016: [ParNew
Desired survivor size 107347968 bytes, new threshold 15 (max 15)
- age   1:    1362152 bytes,    1362152 total
- age   3:     124920 bytes,    1487072 total
- age   4:     115256 bytes,    1602328 total
- age   5:     165000 bytes,    1767328 total
- age   6:      99776 bytes,    1867104 total
- age   7:      97728 bytes,    1964832 total
- age   8:      94616 bytes,    2059448 total
- age   9:      93176 bytes,    2152624 total
- age  10:     111352 bytes,    2263976 total
- age  11:     127800 bytes,    2391776 total
- age  12:      85248 bytes,    2477024 total
- age  13:     110984 bytes,    2588008 total
- age  14:     101880 bytes,    2689888 total
- age  15:      96288 bytes,    2786176 total
: 1747877K->18163K(1887488K), 0.0364969 secs] 4930355K->3200776K(6081792K), 0.0366162 secs] [Times: user=0.17 sys=0.00, real=0.04 secs]
Heap after GC invocations=897 (full 3):
 par new generation   total 1887488K, used 18163K [0x0000000640000000, 0x00000006c0000000, 0x00000006c0000000)
  eden space 1677824K,   0% used [0x0000000640000000, 0x0000000640000000, 0x00000006a6680000)
  from space 209664K,   8% used [0x00000006b3340000, 0x00000006b44fcd88, 0x00000006c0000000)
  to   space 209664K,   0% used [0x00000006a6680000, 0x00000006a6680000, 0x00000006b3340000)
 concurrent mark-sweep generation total 4194304K, used 3182613K [0x00000006c0000000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 60431K, capacity 66281K, committed 66588K, reserved 1107968K
  class space    used 6828K, capacity 8138K, committed 8224K, reserved 1048576K
}
 CMS: abort preclean due to time 2019-10-29T18:03:25.825+0800: 7292.192: [CMS-concurrent-abortable-preclean: 4.952/5.002 secs] [Times: user=10.51 sys=1.44, real=5.01 secs]
2019-10-29T18:03:25.826+0800: 7292.193: [GC (CMS Final Remark) [YG occupancy: 81039 K (1887488 K)]2019-10-29T18:03:25.826+0800: 7292.194: [Rescan (parallel) , 0.0142974 secs]2019-10-29T18:03:25.841+0800: 7292.208: [weak refs processing, 0.0019208 secs]2019-10-29T18:03:25.843+0800: 7292.210: [class unloading, 0.0230836 secs]2019-10-29T18:03:25.866+0800: 7292.233: [scrub symbol table, 0.0054818 secs]2019-10-29T18:03:25.871+0800: 7292.238: [scrub string table, 0.0707817 secs][1 CMS-remark: 3182613K(4194304K)] 3263652K(6081792K), 0.1182958 secs] [Times: user=0.17 sys=0.01, real=0.11 secs]
2019-10-29T18:03:25.946+0800: 7292.313: [CMS-concurrent-sweep-start]
2019-10-29T18:03:27.771+0800: 7294.138: [CMS-concurrent-sweep: 1.825/1.826 secs] [Times: user=3.98 sys=0.52, real=1.82 secs]
2019-10-29T18:03:27.771+0800: 7294.138: [CMS-concurrent-reset-start]
2019-10-29T18:03:27.781+0800: 7294.148: [CMS-concurrent-reset: 0.010/0.010 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]

JVMTI介紹

JVM相關參數：

 -agentlib:<庫名>[=<選項>]
                  加載本機代理庫 <庫名>, 例如 -agentlib:jdwp
                  另請參閱 -agentlib:jdwp=help
-agentpath:<路徑名>[=<選項>]
                  按完整路徑名加載本機代理庫
-javaagent:<jar 路徑>[=<選項>]
                  加載 Java 編程語言代理, 請參閱 java.lang.instrument

JVMTI(Java Virtual Machine Tool Interface)即指Java虛擬機工具接口，它是一套由虛擬機直接提供的 native 接口，通過這些接口，開發人員不僅調試在該虛擬機上運行的 Java 程序，還能查看它們運行的狀態，設置回調函數，控制某些環境變量(JMX)，從而優化程序性能。Java Agent就是基於JVMTI的，所以眾多基於Java Agent的技術例如APM，遠程調試，各種性能剖析同樣是基於這個技術。

JVMTI 接口：

JNIEXPORT jint JNICALL
Agent_OnLoad(JavaVM *vm, char *options, void *reserved);

JNIEXPORT jint JNICALL
Agent_OnAttach(JavaVM* vm, char* options, void* reserved);

JNIEXPORT void JNICALL
Agent_OnUnload(JavaVM *vm); 

-agentpath是c/c++編寫的動態庫，-agentlib和-javaagent是一個instrument的JVMTIAgent（linux下對應的動態庫是libinstrument.so）。

Attach機制

Jvm提供一種jvm進程間通信的能力，能讓一個進程傳命令給另外一個進程，並讓它執行內部的一些操作，比如說我們為了讓另外一個jvm進程把線程dump出來，那麼我們跑了一個jstack的進程，然後傳了個pid的參數，告訴它要哪個進程進行線程dump。

Attach命令列表

static AttachOperationFunctionInfo funcs[] = {
  { "agentProperties",  get_agent_properties },
  { "datadump",         data_dump },
  { "dumpheap",         dump_heap },
  { "load",             JvmtiExport::load_agent_library },
  { "properties",       get_system_properties },
  { "threaddump",       thread_dump },
  { "inspectheap",      heap_inspection },
  { "setflag",          set_flag },
  { "printflag",        print_flag },
  { "jcmd",             jcmd },
  { NULL,               NULL }
};

Attach流程：

Jstack源碼：
https://android.googlesource.com/platform/libcore/+/0ebbfbdbca73d6261a77183f68e1f3e56c339f9f/ojluni/src/main/java/sun/tools/jstack/JStack.java

查看java線程：

其中Siginal Dispatcher是處理進程信號的線程，Attach Listener正式Attach機制處理線程。

java自帶工具

jps

查看Java進程列表

常用參數：

1. -l: 輸出應用程序主類完整package名稱或jar完整名稱
2. -m:輸出主函數傳入的參數

jmap

查看JVM堆的情況

常用參數：

1. -heap
2. -dump 這個命令還有兩個常用參數
   1. live 只dump存活對象，會導致GC
   2. file=file dump文件名

示例：jmap -dump:live,file=heap.dump <pid>

這裡有兩點，一方面需要注意live會導致GC，有時候在查問題的時候可能不是你預期的效果，一般查內存問題時不加這個選項，另外dump文件如果比較大，可以先壓縮在傳回本地

jstack

查看JVM的堆棧情況，監測死鎖等

這個命令比較簡單，一般不用加什麼參數，有時候JVM沒響應時可以加-F參數。一般這個命令可以結合top，在top定位到佔用cpu高的線程后，在具體在Jstack打印的堆棧中查看線程，有時候也需要多次打印堆棧來進行對比

jstat

查看JVM gc信息，觀察JVM的GC活動

常用參數： -gccause 這個參數包含了-gcutil的信息多了一個gc原因

示例： jstat -gccause <pid> 1000

11:19 [supertool@y051]$ jstat -gccause  10711 1000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                 
  0.00  21.23  95.99  69.88  91.56  82.62   1187   22.511     4    0.141   22.652 Allocation Failure   No GC               
  0.00  21.23  99.51  69.88  91.56  82.62   1187   22.511     4    0.141   22.652 Allocation Failure   No GC               
 21.30   0.00   3.51  69.88  91.56  82.62   1188   22.530     4    0.141   22.671 Allocation Failure   No GC               
 21.30   0.00   7.02  69.88  91.56  82.62   1188   22.530     4    0.141   22.671 Allocation Failure   No GC               
 21.30   0.00  10.14  69.88  91.56  82.62   1188   22.530     4    0.141   22.671 Allocation Failure   No GC               
 21.30   0.00  13.62  69.88  91.56  82.62   1188   22.530     4    0.141   22.671 Allocation Failure   No GC               
 21.30   0.00  16.78  69.88  91.56  82.62   1188   22.530     4    0.141   22.671 Allocation Failure   No GC               

jinfo

查看設置的JVM參數和啟動時的命令行參數，還可以動態修改JVM參數

常用參數

1. -flags 查看jvm參數值
2. -sysprops 查看系統屬性值

示例：jinfo -flags 10711

Non-default VM flags: -XX:BiasedLockingStartupDelay=0 -XX:CICompilerCount=4 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=75 -XX:+CMSParallelRemarkEnabled -XX:ErrorFile=null -XX:GCLogFileSize=10485760 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=null -XX:InitialHeapSize=1073741824 -XX:MaxHeapSize=1073741824 -XX:MaxNewSize=268435456 -XX:MaxTenuringThreshold=15 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=268435456 -XX:NumberOfGCLogFiles=20 -XX:OldPLABSize=16 -XX:OldSize=805306368 -XX:+PrintClassHistogram -XX:+PrintCommandLineFlags -XX:+PrintConcurrentLocks -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:StringTableSize=6000000 -XX:+UseBiasedLocking -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseFastUnorderedTimeStamps -XX:+UseGCLogFileRotation -XX:+UseParNewGC 
Command line:  -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 -XX:+PrintCommandLineFlags -Xms1g -Xmx1g -Xmn256m -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Dfile.encoding=UTF-8 -XX:MaxTenuringThreshold=15 -XX:StringTableSize=6000000  -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintClassHistogram -XX:+PrintConcurrentLocks -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=20 -XX:GCLogFileSize=10m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/java/logs -XX:ErrorFile=/var/java/logs/jvm-error.log -Dlog4j.config.file=log4j_.properties -Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.Log4jLogDelegateFactory -Dvertx.options.maxEventLoopExecuteTime=100000000 -Dvertx.options.warningExceptionTime=300000000 

JDPA(Java Platform Debugger Architecture)

java遠程調試，需要jvm啟動時加參數：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

遠程調試非常有用，有時候測試環境很難復現時，可以用通過遠程調試查看線程數據

三、三方工具

jprofile

CPU性能分析

抽樣：每隔一段時間，獲取線程棧，分析各個棧上出現的方法的次數

優點：性能高
缺點： 不適合做精確的分析
適用範圍：尋找程序的執行熱點，cpu密集型

指令插入：使用增強的技術修改java class的字節碼，在函數的出入口增加埋點

優點：數據準確
缺點：導致jvm內聯優化失效，性能低
適用範圍：分析具體耗時路徑的各個執行時間，io密集型

一般先使用抽樣在定位到大致的範圍，然後使用指令插入分析具體代碼執行路徑中的耗時，jprofile可以通過過濾只對指定類進行增強

1. Thread Status：選擇線程統計狀態，Runnable显示的是cpu時間，不包含sleep這種時間一般都是這個模式。還可以使用IO Net模式分析io等待，Wait分析鎖競爭模式
2. Call tree filters ：調用樹過濾：用於過濾不需要的類，例如你使用web框架，棧中起始的方法都是框架中的代碼，最後才是你的業務代碼，這時候可以使用Call tree filters來過濾不需要的類型，減少統計造成的性能開銷

內存剖析

分析內存泄漏的利器，主要是看內存中內存佔比和大對象。很多時候如果有內存泄漏基本都是以為某些類型的對象佔用了大頭。

arthas （類似btrace的工具）

Arthas 是Alibaba開源的Java診斷工具。線上debug的工具，很多時候因為性能和安全等原因我們不能直接遠程調試線上的jvm，這時候我們可以使用arthas來查看內存的數據，方法調用情況，打印日誌信息等。

比較常用的：

1. watch 看方法調用情況 -c 統計周期，默認值為120秒
2. monitor 統計方法調用信息
3. getstatic 查看靜態變量
4. logger 查看和修改logger
5. trace 方法內部調用路徑，並輸出方法路徑上的每個節點上耗時

示例：

1. monitor -c 5 com.miaozhen.bazaro.deal.PreferredDealFilterService filter
2. watch com.miaozhen.bazaro.share.manager.util.DealManager getDspToDealsByPid "returnObj"

gceasy

https://gceasy.io/ 一個在線分析gc日誌的網站，

四、實際案例

連接泄漏

場景描述：我們公司的用戶服務對接了第三方騰訊雲通信服務，在用戶註冊的時候我們需要走http接口調騰訊雲，問題就出在http連接那塊，同事當時採用了,線上出現了cpu100%的問題，日誌出現java.lang.OutOfMemoryError: GC overhead limit exceeded。

排查思路：這個其實很好定位，本來還想打印線程棧看下到底是哪個導致的cpu100%，一看日誌直接定位到gc出問題。GC overhead limit exceeded是指gc佔用了大量的cpu時間又回收不了內存引起的，從內存泄露去考慮，重啟服務 ，啟動參數加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./user.hprof -verbose:gc -Xloggc:user%t.log。問題復現的時候獲得了堆的dump文件，然後通過Jprofile分析，發現有大量的http.HttpKeepAliveCache實例，佔用了80%的內存，大致定位到是由於http連接泄露。同事封裝的HttpUtil中使用了HttpsURLConnection，在讀取完數據的時候沒有關閉InputStream導致連接沒有關閉。

說明：GC overhead limit exceeded，默認情況下，如果Java進程花費98%以上的時間執行GC，並且每次只有不到2%的堆被恢復，則JVM拋出此錯誤。這個錯誤是parallel Scavenge 特有的

String拼接導致內存溢出

公司的後台有段時間會間歇性的卡頓，嚴重的情況下會導致cpu100%。在cpu100%的時候，通過top定位到進程號，然後輸入H切換到線程，記住具體的進程號，使用jstack打印java進程的線程棧，jstack輸出為十六進制，需要將top的轉換成十六進制的然後入找線程經常卡在哪個方法。定位到方法發現是查詢用戶關聯設備號的方法出問題，方法的邏輯是從數據庫查詢設備號，在內存中以以逗號分隔拼接返回，如1,2,3。這個bug的原因是有如下：

sql出錯，導致查詢返回數據量很多，正常情況最多幾百個，但是異常情況有七萬個設備號
字符串拼接採用str+=”1234″的形式，導致大量的內存分配和回收。
運營在點擊後台查詢的時候發現沒返回，點掉就重新點，導致服務器多個線程卡在這個方法造成cpu100%。解決完sql，改用StringBuilder問題解決。

堆內存佔用過大

我們的一個服務程序，老年代設置了10g，新生代2g，偶會會出現內存溢出的線程，通過分析內存發現deal數據佔用了大量內存，最高可達9.4g。

堆數據：

問題代碼：

優化后堆數據：

優化后降低了老年代改為4g，大大降低了Jvm的堆的大小，16g機器現在可部署兩個實例，且Full Gc穩定在一天一次，Young Gc 5s一次，均處正常。

CPU佔用高問題

最近在分析拍賣程序時，發現com.miaozhen.bazaro.deal.PreferredDealFilterService#filter方法佔用了90%的cpu時間。

cpu熱點圖：

問題代碼：

分析該方法的時長：

查看耗時deal數據

aerospike線程阻塞導致內存溢出問題

問題：拍賣在五點多收到網站推送數據的時候發生OOM。

查看日誌發現，有很多關於線程阻塞的報錯，是讀取aerospike卡住導致。報錯如下：

觀察gc分析結果：

可以看到本來堆內存始終穩定在一個水平，在一個時間點之後，堆內存開始穩步上漲，十分符合內存泄漏的特徵。

觀察堆內存數據：

注：這個堆內存不是當時，當時的堆內存沒找到，佔比是類似的。這個圖內存優化之後的，所以老年代只有4g。

可以看到其中OrderedExecutor佔用了大量的內存，這個數據接口是用來存放http請求的接口。

總結：

晚上九點40線程阻塞，但是請求的任務不停地往他的tasks裏面放，十分鐘后grafana監控显示上升了16%的超時率（六個verticle掛了一個），從4%到20%。
查看內存監控圖，9點40開始內存上升，不再回收，最終存了2900萬個tasks，一個線程佔用了10g內存，到晚上11.15左右日誌出現大量的空指針和超時，十分鐘后監控圖显示全部超時，gc監控显示大量full gc，因為內存不夠大量的gc佔用了進程cpu時間。，5點多的時候推送物料，服務器內存溢出。

參考資料：

問題

1. 什麼樣的代碼算是耗時的代碼，或者說耗時代碼的特徵是什麼
2. jvm一個線程發生OOM會導致JVM掛掉嗎
3. 內存問題會導致cpu飆高嗎

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

Transformer模型由《Attention is All You Need》提出，有一個完整的Encoder-Decoder框架,其主要由attention(注意力)機制構成。論文地址：。

其整體結構如圖所示：

 

模型分為編碼器（Encoder）和解碼器（Decoder）兩部分，包含內部結構的總體結構如下圖所示：

 

                                                      圖二

在論文中編碼器部分由6個相同編碼器疊在一起，解碼器部分也是由6個相同解碼器疊在一起，編碼器之間不共享參數。(這裏不一定要是6個)

在將詞向量表示送入編碼器、解碼器之前，先做positional encoding，下面依次對positional encoding、encoding、decoding進行介紹：

1、positional encoding

 

 

如圖所示，由於attention機制不包含位置信息，因此句子首先進行embedding得到詞向量表示，同時為了增加位置信息，根據句子中詞的位置信息給詞嵌入添加位置編碼向量，論文中添加位置編碼的方法是：構造一個跟輸入embedding維度一樣的矩陣，然後跟輸入embedding相加得到multi-head attention 的輸入。

作者希望引入絕對位置的編碼公式，讓模型能夠學習到相對位置信息，作者使用的positional encoding生成固定位置表示如下：

已知三角函數公式如下：

 

 

 作者希望通過絕對位置的編碼公式，讓模型可以學習到相對位置信息。雖然如此獲得的 position embeddings，兩者之間的點積能夠反應相對距離，但它缺乏方向性，並且這種特性(相對距離)會被原始 Transformer 的注意力機制破壞。

基於公式 (1),位置t的位置嵌入可以表示為：

 

 

 

 

 

 

2、encoding

如圖二左邊結構所示，編碼器主要由前饋神經網絡層與多頭自注意力層構成，值得注意的是，在每個編碼器中的每個子層（自注意力、前饋網絡）的周圍都有一個殘差連接，並且都跟隨着一個“層-歸一化”步驟。這裏先介紹attention機制，還是舉個栗子：

假設我們想要翻譯這個句子：

“The animal didn’t cross the street because it was too tired”

那麼it在這句話中是是指animal還是street，人類好理解這句話，但是對機器來說就很困難了。當模型處理這個單詞“it”的時候，自注意力機制會允許“it”與“animal”建立聯繫。隨着模型處理輸入序列的每個單詞，自注意力會關注整個輸入序列的所有單詞，幫助模型對本單詞更好地進行編碼。如下圖。

 

當我們在編碼器#5（棧中最上層編碼器）中編碼“it”這個單詞的時，注意力機制的部分會去關注“The Animal”，將它的表示的一部分編入“it”的編碼中。

接下來介紹attention實現的思想。

計算自注意力的第一步就是從每個編碼器的輸入向量（每個單詞的詞向量）中生成三個向量。也就是說對於每個單詞，我們創造一個查詢向量、一個鍵向量和一個值向量。這三個向量是通過詞嵌入與三個權重矩陣后相乘創建的。在論文中這三個向量的維度比詞嵌入向量要低，實際中維度更低不是必須的，只是架構上的選擇，可以使多頭注意力的大部分計算保持不變。

計算自注意力的第二步是計算得分。假設我們需要對第一個詞’Thinking’計算自注意力向量那麼需要拿輸入句子中的每個單詞對“Thinking”打分。這些分數決定了在編碼單詞“Thinking”的過程中有多重視句子的其它部分。

這些分數是通過打分單詞（所有輸入句子的單詞）的鍵向量與“Thinking”的查詢向量相點積來計算的。所以如果我們是處理位置最靠前的詞的自注意力的話，第一個分數是q1和k1的點積，第二個分數是q1和k2的點積。

 

第三步和第四步是將分數除以8(8是論文中使用的鍵向量的維數64的平方根，這會讓梯度更穩定。這裏也可以使用其它值，8隻是默認值)，然後通過softmax傳遞結果。softmax的作用是使所有單詞的分數歸一化，得到的分數都是正值且和為1。

 

這個softmax分數決定了每個單詞對編碼當下位置（“Thinking”）的貢獻。顯然，已經在這個位置上的單詞將獲得最高的softmax分數，但有時關注另一個與當前單詞相關的單詞也會有幫助。

第五步是將每個值向量乘以softmax分數(這是為了準備之後將它們求和)。這裏的直覺是希望關注語義上相關的單詞，並弱化不相關的單詞。

第六步是對加權值向量求和，然後即得到自注意力層在該位置的輸出。

 

這樣自注意力的計算就完成了。得到的向量就可以傳給前饋神經網絡。

在現實中自注意力機制是通過矩陣來實現的，與上面思路一樣：

第一步是計算查詢矩陣、鍵矩陣和值矩陣，如下圖所示：

 

將前面的計算步驟可以合併成：

 

介紹完自注意力機制后，介紹在論文中使用的多頭自注意力機制“multi-headed” attention。

 

每個頭都是獨立的查詢/鍵/值權重矩陣，從而產生不同的查詢/鍵/值矩陣。在論文中採用的是8頭，那麼經過8次不同權重矩陣運算，我們會得到8個不同的Z矩陣。

 

然後我們將這8個矩陣壓縮成一個矩陣，實現原理是將這8個矩陣拼接在一起，然後再用一個權重矩陣與之相乘，得到一個融合所有注意力頭信息的矩陣Z，再將其求和與歸一化後傳給前饋層。

 

Decoding(解碼器)：

解碼器內部組件與編碼器大同小異，需要注意的是，解碼器的第一個注意力層被稱作MaskedMulti-Head Attention,通過加入了MASK操作，使得我們只被允許處理輸出序列中更靠前的那些位置，即我們只能attend到前面已經處理過的語句。第二個注意力層被稱作encoder-decoder attention layer，由圖二可知，它的query來自前一級的decoder層的輸出，key、value來自encoder的輸出，encoder的輸出可以幫助解碼器關注輸入序列哪些位置合適。接下來送入前饋層，然後重複這些步驟，直到到達一個特殊的終止符號，它表示transformer的解碼器已經完成了它的輸出。每個步驟的輸出在下一個時間步被提供給底端解碼器，並且就像編碼器之前做的那樣，這些解碼器會輸出它們的解碼結果 。另外，就像我們對編碼器的輸入所做的那樣，我們會嵌入並添加位置編碼給那些解碼器，來表示每個單詞的位置。

 

在解碼完成後會輸出一個實數向量，經過一個簡單的全連接神經網絡（線性變換層）映射到一個被稱作對數幾率（logits）的向量里，假設從訓練集中學習一萬個單詞，那麼對數幾率向量為一萬個單元格長度的向量——每個單元格對應某一個單詞的分數。接下來的Softmax 層便會把那些分數變成概率（都為正數、上限1.0）。概率最高的單元格被選中，並且它對應的單詞被作為這個時間步的輸出。

 

 

 參考：

　　　

　　   　　    

         

 

 

（完）

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※南投搬家前需注意的眉眉角角，別等搬了再說!

場景需求

• 不需要長時間使用的郵箱
• 需要大量創建臨時郵箱
• 使用匿名郵箱

環境說明

• **` Forsaken Mail是一個臨時郵箱系統，可以供任何人接受郵件，即收即毀，支持自定義郵箱地址前綴，這裏就說下Docker和NPM兩種安裝教程，任選一種即可，有興趣或者有需求的可以玩玩。

• Github地址：https://github.com/denghongcai/forsaken-mail

開啟25 跟3000端口

• 發工單開 25 跟 3000端口
• 寶塔面板放行25 跟 3000端口
• 運營商（xx雲等）到安全組開啟機可
• 國外VSP（如xx工等） 一般不用開

安裝Docker環境

Docker 官網

#CentOS 6
rpm -iUvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum update -y
yum -y install docker-io
service docker start
chkconfig docker on

#CentOS 7、Debian、Ubuntu
curl -sSL https://get.docker.com/ | sh
systemctl start docker
systemctl enable docker

Docker 運行 Forsaken Mail 鏡像

​`````` docker run --name forsaken-mail -d -p 25:25 -p 3000:3000 denghongcai/forsaken-mail 

注意：可能會出現端口25被佔用

##找出佔用端口程序PID
$ netstat -anp |grep 25
##關閉該程序
$ kill -9 PID
## 重新運行Docker 鏡像
docker start ID/name

使用 域名 代替 IP

做到前面這一步已經可以通過 VSP_IP :3000 來訪問，但是不能通過 域名：3000 進行訪問

此時就應該進行域名解析——登錄你的域名管理。

• 一級域名解析

需要添加以下2條解析記錄。 了解MX記錄 ， A 記錄可參考上一篇

#MX記錄， xx.com 是你買的域名 mx 不要更改
xx.com    MX   10     mx.xx.com
#A記錄 
mx.xx.com   A   服務器IP

• 其實如果xx.com 被你用了的話，就需要使用 二級域名解析(比如 mail.xx.com)

#CNAME記錄
mail         CNAME     @ 
#A記錄 
mail.xx.com   A   服務器IP

配置Https訪問

如果還不滿足使用http://mx.xx.com:3000，或者想使用Https域名訪問主界面，那我們可以使用Caddy反代。這裏所使用的域名只能是上面設置MX記錄的xx.com，並提前將域名A記錄解析到服務器IP。

1、安裝Caddy
使用命令：

wget -N --no-check-certificate https://raw.githubusercontent.com/ToyoDAdoubiBackup/doubi/master/caddy_install.sh && chmod +x caddy_install.sh && bash caddy_install.sh
#備用地址
wget -N --no-check-certificate https://www.moerats.com/usr/shell/Caddy/caddy_install.sh && chmod +x caddy_install.sh && bash caddy_install.sh
2、配置Caddy

2、配置Caddy

#以下全部內容是一個整體，請修改2個域名后一起複制到SSH運行！
echo "xx.com {
 gzip
 tls admin@moerats.com
 proxy / mx.xx.com:3000
}" > /usr/local/caddy/Caddyfile

3、啟動Caddy

/etc/init.d/caddy start

最後可以打開https://xx.com訪問，使用Docker應用還是容易的。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!