您好,登錄后才能下訂單哦!
本篇內容介紹了“nginx工作進程分析”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
有天接收到業務同事反映,說有些業務超時比例過高。我嘗試查詢問題,最終定位到nginx將一些請求反向代理到錯誤的路徑上,導致超時。
我準備從以下線索追蹤問題:
反向代理到的錯誤路徑,這個錯誤的路徑之前是做什么業務。
反向代理的配置是否正確
nginx配置生效操作是否正確
這個路徑指向的服務器是之前業務的負載,由于這個機器比較就,就將他下架了。此服務器上已經沒有相關業務程序,如果有實時請求反向代理到這臺機器上,由于該服務器沒有部署相關業務程序,請求失敗
我們觀察了upstream相關配置,的確沒有配置轉發到這臺舊機器的配置。
使用的命令是:
nginx -t
nginx -s reload
先檢查配置是否正確,然后重載。
nginx的reload命令做的是什么樣的操作。
參考官方文檔
http://nginx.org/en/docs/beginners_guide.html
一旦master 進程接收到需要重載配置文件的信號時,它會檢查新配置文件中語法是否正確,嘗試著適用該配置。如果成功,master進程會啟動新的工作進程,并且向舊的工作進程發送關閉信號,請求關閉舊工作線程。否則,master進程回滾到改動之前的配置狀態,繼續使用舊的配置文件。老的工作線程,接收到需要關閉的信號時,停止接收新的連接,并且繼續服務當前的請求,直到這些請求全部被處理。最后,老的工作線程退出。
回想到錯誤現象:nginx將一些請求反向代理到錯誤的路徑上,導致超時
存在一些請求反向代理到錯誤的路徑,但是大多數請求的反向代理都是正確的。是不是有些工作進程使用的是當前的配置文件,而有一些工作進程使用的是舊的配置文件。那些走舊的配置文件的工作進程將請求反向代理到錯誤的路徑上。
實際是檢驗真理的唯一道路,我們登陸服務器查詢下該nginx下的工作進程:
nginxbug1.png
nginxbug3.png
發現果然有一個工作進程的創建時間是2018年,明顯有問題。pid為 36766 的nginx master下有一個pid為30284 工作進程的創建時間是 2018年。
“nginx工作進程分析”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。