Threadser.net
數據
關鍵字
功能建議
Blog
Following
Threads
Change language
登入
串文
串文鏈結
2024-12-13 02:10
我的第一個 debug 動作,就是先連進系統裡看網頁伺服器的 log,結果發現有一條記錄是錯在某個我多年前所安裝、但早就沒在用的 WSGI module,是跟 Python web app 有關的。因為用不到了,我就順手把它給卸載;不過,問題仍是沒解決,開始報出某些 process coredump 了⋯。 忙了一小陣,發現是資料庫吃掉系統的 CPU 資源。不過,通常這都是太多人點擊了報告頁面所導致的,因為它會向我們的資料庫下數十道 SQL query 指令。我就下了 restart 讓它重啟,但結果並沒有比較好,重啟後不到5分鐘,系統負載又持續飆高⋯。 這時我的同事來了,他在系統裡看了看,懷疑是硬體出了問題。畢竟這套系統也上架很多年了,近年來只要每逢跳電或電力系統維修,我們的機器就像抽樂透一樣,看是哪一台會中獎,中了不是硬碟壞掉就是主機板爛掉。 他就帶著我一同去檢查,結果查了之後竟然是一切都沒問題!這下可好,要如何找問題? (2/6)
讚
6
回覆
1
轉發
作者
尼爾的程式技能樹 | 分享 Python 相關經驗和技巧
neil.skilltree
粉絲
5,059
串文
143+
讚
回覆
轉發
24小時粉絲增長
發文前
4,979
發文後24小時
4,999
變化
+20 (0.40%)
互動率
(讚 + 回覆 + 轉發) / 粉絲數
0.14%
回覆 (BETA)
最先回覆的內容
發文後
用戶
內容
幾秒內
尼爾的程式技能樹 | 分享 Python 相關經驗和技巧
neil.skilltree
我們只好坐下來仔細地 debug。發現是如果經由入口網站存取系統,才會有高負載的問題,如果是從自己手工打造的報告頁面進來,反而很順。這就讓我們開始懷疑入口網站所對應到的資料庫表格。 於是我同事就開始把每一個表格都跑最佳化程序,直到某一個表格時特別慢,我們就猜是這個表格搞的鬼。因為這表格裡面的內容不重要,他就下了道指令把資料清空,接著重啟資料庫和網站,就真的變順了。大功告成! 沒想到,兩個小時過後,同樣的問題又跑出來了⋯我的同事就再度埋首於一堆系統的 log 中,而我因為對伺服器調校不擅長,只能盯著網站的 config、一行一行的掃過,看看能不能幫上一點忙。 但幾個小時過去,完全沒有進展。上千行的 config 也看完了,實在是不知該怎麼辦。就在這時,我想到了一個看似不靠譜,但其實很有科學依據的方法:站起來走一走。 (3/6)