最近幾天經常遇到jenkins web無法訪問的情況，systemctl restart jenkins.service后就正常了。
現象如下：
1. systemctl status jenkins.service，發現后台service運行正常
2. ps -ef | grep jenkins沒有結果；netstat -tnlp | grep 8083也無結果。很好奇，systemctl status和ps查詢結果為啥對應不上。。
3. 查詢jenkins.log，根據systemctl status jenkins.service可知啟動文件位置，再找到jenkins.log位置
發現莫名其妙啟動jenkins，而且出現端口占用的異常，實在沒想明白。
4. top操作，發現jenkins內存占用一直11.7%以上，16G內存，也就是長期占用接近2G，是否可能是linux的OOM-killer造成的？
5. 查詢linux主動kill的進程日志，發現28323就是之前jenkins的pid
為確認kill進程的原因，查詢內核日志，dmesg -T -d | grep java
的確是因為OOM，jenkins服務占用內存一度達到10G。。原因還未搞清楚【Out Of Memory Errors】
【補充】最近jenkins服務又頻繁down掉，查看OOM-killer日志確認：
(1) cat /var/run/jenkins.pid獲取jenkins進程id
(2) dmesg -T -d | grep <jenkins進程id>
jenkins服務占用內存一度達到10G。。。
(3) 查看jenkins log，看看jenkins服務down掉時有哪幾個job在運行，發現有兩個。重啟jenkins再手動觸發這兩個job，top命令觀察jenkins以及啟動job占用內存變化（當時也使用遠程jvisualvm觀察jenkins vm堆變化）。最終復現問題（jenkins服務down掉），發現是兩個job的前端構建，node中vue-cli-service build消耗內存太大，每個幾乎占用8G。。。交由前端處理
6. 設置jvm啟動/運行時參數，限制堆內存， -Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m
6. 監控下gc，jstat -gcutil 13771，服務啟動后一天內FullGC4次，時間0.448s，還可以。Jenkins web無法訪問的問題算是解決了。
