記一次fastdfs問題的排查。
fastdfs基本架構特點鮮明，分為tracker、storage兩個模組，前者乙個，後者多個，用以保證「分布式、冗餘式」，因此後者一般多個伺服器且乙個伺服器放乙個，一台伺服器允許同時具有tracker和storage（一般也的確如此，畢竟tracker不怎麼佔空間）。
tracker只作為彙總者、統計者、通知者角色，面向上層業務通知；storage除了業務上的「儲存」，也有通知功能，但是僅面向tracker，用以讓tracker知道自己的資訊、實現間接對外開放和分布式冗餘儲存。
部署注意事項有二。
一為，必須有乙個nginx凌駕於tracker、storage之上與後兩者互動，雖然tracker只是作為乙個中間商不參與任何資料流而storage參與最終的資料流互動，但是storage不能直接對外，必須通過該更上層的nginx；
二為，storage自己伺服器居然也必須有乙個「內建」nginx，用以與更上層、更外部進行互動。本次問題根源在於「內建」nginx掛了。
首先根據更上層、更外部的nginx的日誌發現，上行資料流不可獲取（更上層nginx與storage之間），進而發現storage的80埠不可訪問；順帶發現storage連telnet等基礎命令都沒有，用scp、rpm等命令處理之，期間涉及rpm -qa與netstat等命令，此為其他問題。一開始以為80不可用，是因為防火牆問題（順帶發現是centos7，無iptables而是firewalld），進而yum安裝（此時居然臨時有了外網許可權），同時用systemctl等systemd模組命令管理（狀態、伺服器重啟自啟動、啟動、關閉等）。結果發現與防火牆無關，只是對應80的服務未啟，對應服務是「內建」nginx，該nginx居然在fastdfs資料夾內部。
啟動「內建」nginx，關閉不必要的防火功能，業務啟動，恢復正常。
flip close Oops問題排查
1 問題描述 oops 1 cpu 0 0 00000000 00000001 64206e6f 838ceae0 4 838ceae0 83816140 00000001 00000007 8 0000080f 00000004 00000020 83934668 12 82fdb128 ffff...
404問題排查
當tomcat沒有日誌的時候，不一定訪問沒有到達tomcat 我們可以通過web.xml中的filter來攔截請求，把斷點打到第乙個filter smartfilterdispatcher 上，確定請求，然後檢視問題在 resource name add cust topic destination...
GC問題排查
一 使用jps檢視執行緒id 二 使用jstat gc 3331 250 20檢視gc情況，一般比較關注perm區的情況，檢視gc的增長情況。三 使用jstat gccause 額外輸出上次gc原因 四 使用jmap dump format b,file heapdump 3331生成堆轉儲檔案 五...