乙個即將上線的go 寫的高頻服務，壓測的時候發現 gc 特別高，高到10%-15% 左右了，本文記錄下優化 gc 的過程和和思路。線上環境1.10.
首先，檢視gc 是否有異常，我們可以使用 gctrace 跟蹤實時的gc 。執行下面命令可以看到gc 的實時資訊。
godebug=gctrace=1 go run cmd/agent_bin.go
gc 45 @37.801s 11%: 0.19+627+0.29 ms clock, 0.38+424/621/0+0.59 ms cpu, 356->415->225 mb, 453 mb goal, 4 p gc 46 @39.126s 11%: 2.9+927+0.16 ms clock, 5.8+342/925/0+0.33 ms cpu, 361->460->275 mb, 450 mb goal, 4 p gc 47 @40.847s 12%: 0.24+1096+0.12 ms clock, 0.49+291/1007/0+0.24 ms cpu, 427->559->319 mb, 551 mb goal, 4 p gc 48 @42.771s 12%: 0.26+841+0.12 ms clock, 0.52+377/830/0+0.24 ms cpu, 486->561->271 mb, 638 mb goal, 4 p gc 49 @44.429s 12%: 3.1+890+0.40 ms clock, 6.2+492/833/0+0.81 ms cpu, 440->528->294 mb, 543 mb goal, 4 p gc 50 @46.188s 12%: 0.23+1165+0.13 ms clock, 0.47+624/1158/0+0.27 ms cpu, 471->579->323 mb, 589 mb goal, 4 p gc 51 @48.252s 13%: 0.26+1410+0.14 ms clock, 0.52+358/1336/9.9+0.28 ms cpu, 506->620->343 mb, 646 mb goal, 4 p gc 52 @50.942s 13%: 0.27+806+0.51 ms clock, 0.55+
優化思路以及優化過程
nginx響應請求 1 建立 socket 連線2 開啟檔案,並沿 socket返回.排查問題,也要注意觀察這兩點 主要從系統命令 dmesg 和 nginx 的error.log 來觀察優化過程 1 判斷 nginx 的瓶頸1.1 首先把 ab測試端的效能提高 使之能高併發的請求 易出問題 too...
mysql思路 MySQL優化思路
通過指令碼，重新整理觀察mysql的status，觀察是否有週期性故障活波動，一般由訪問高峰或者快取失效引起，家快取並更改快取失效策略，是失效時間分散或頁面定時失,show processlist顯示哪些執行緒正在執行。您也可以使用mysqladmin processlist語句得到此資訊。如果您有...
OXWALL優化思路
閱讀oxwall的初始化 日誌實現部分，重點關注主頁的資料讀取流程，在資料讀取流程中增加寫日誌，可以看到初始化頁面涉及資料庫讀取的操作異常多。這將是效率的瓶頸，應該考慮將資料快取到redis中，並結合訊息佇列更新快取和資料庫。研究 安全隱患sql注入 csrf 偽造的跨站點請求 跨站點指令碼 xss...