ProxySQL 本身是一款非常棒的MYSQL 中間件的開源產品, 在公司運行了一段時間后,突然一天報警,所在機器的CPU 出奇的高,之前在測試系統, 預生產, 以及生產系統均沒有出現問題. 開始未來緊急解決問題,重新啟動了proxysql服務,并查看錯誤日志.

PROXYSQL 的系統版本的2.012 MYSQL 的版本是8.011 , PROXYSQL 的錯誤在上邊. 但后期又繼續發生了類似的問題, 并且其中有一次,重新啟動PROXYSQL 后在 1- 2秒后, 問題重復,CPU 又開始標高,但CPU 等其他指標都比較低.

隨后我們針對PROXYSQL 進行了壓縮, 通過模仿高并發連接, 1000并發,不斷的進行數據訪問, 以及模擬突然的連接失效(斷掉), 看看PROXYSQL 本身是不是出現的我們遇到的類似的問題.

在壓力測試的過程中,PROXYSQL 系統本身沒有出現任何異常的情況, CPU 始終在 %3以下, 在壓力測試超過1000并發后, 并且PROXYSQL 最大設置的MAX Connection 1000 的情況下, PROXYSQL 在短時間有CPU 消耗達到25%的情況.? 但整體的情況是穩定的.

那到底什么導致了PROXYSQL 系統的CPU 在某個時間段突然超高并且只能進行相關的重啟后,CPU 才能下降.

這里和公司的網絡安全人員進行了相關的配合,其中發現在漏洞掃描期間,PROXYSQL 有CPU 超高的時間匹配度.隨后網絡安全人員,進行了如下測試,

PROXYSQL?

在漏洞掃描程序掃描時, 會對PROXYSQL 開放的 X11? 協議端的端口進行掃描,在掃描時會反饋,下面的信息, 8.0.5 是在PROXYSQL 設置的,因為如果使用了MYSQL 8 后在PROXYSQL 中的version 信息不設置的情況下, 會導致JAVA 程序訪問MYSQL的問題, 因為8.0以后的MYSQL 去掉了 query_cache , 但如果PROXYSQL 不設置版本,則 JAVA 的封包的程序會回饋, query_cache 找不到的 問題, 而 mysql_native_password 也是因為兼容大部分MYSQL 原理的程序登錄的方式,將MYSQL 的默認密碼驗證的方式調整成原來5.X的方式.?

所以這里漏掃程序會對敏感詞 password 展開嘗試性的密碼匹配庫的嗅探工作,而這樣的工作導致,proxysql 在X11 端口中出現問題,進入一個死循環.

最終導致PROXYSQL 出現CPU 超高的問題.

解決方案: 在防火墻的IPS 模塊對無效請求的數據包進行過濾(其實網絡的問題,我不大理解到底IPS 是什么,怎么就對無效請求的數據包進行過濾,就避免了PROXYSQL 的CPU 不在提高,回來還的深入的問一下網絡人員)

另外對其中一個參數,mysql-threads 在解決問題的時候,有人提出加大proxysql? 中的 mysql-threads 的線程數,提高 proxysql 處理的速度,降低CPU 的 usage 的百分比.

實際這樣的想法是錯誤, mysql-threads 本身針對當前CPU 的數量進行的設置,PROXYSQL 本身針對系統的運行期間,CPU 主要消耗在? SYSTEM CPU ,而不是USER CPU , 這里的意思是CPU 主要是消耗子在將信息從 客戶端發送給MYSQL 以及信息專遞回 客戶端的, 如果 USER CPU 本身消耗的很高的情況下,則說明PROXYSQL 在處理數據方面有問題, 例如設置了太多的規則,導致一個SQL 在規則方面耗費的CPU 較多的情況.

另外盲目調整 mysql-threads 本身就是一個問題, 如果CPU 本身CORE 就很少,但是PROXYSQL 使用CPU 較多, 調整mysql-thread 更大的情況下,會造成CPU 上下文切換比較頻繁,最終導致CPU 更加的繁忙.

所以如果CPU 高先分析以下幾個問題

1? CPU 在什么 時間點高,是一直高還是有時間段

2? 如果是有時間點的高,則考慮業務,或者業務觸發的某些業務量上漲后的問題

3? 如果是CPU 一直高,則考慮是由于一些BUG 或者 非業務的問題造成的,主要就要去查看日志,和進行STRACE 問題了, 難度可能就有提高了,另外PROXYSQL 中的設置的規則太多也可能會造成相關的問題.

總結

以上是生活随笔為你收集整理的airodump-ng wlan0mon扫描不到网络_MySQL ProxySql 由于漏洞扫描导致的 PROXYSQL CPU 超高...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。