由于linux的socket監(jiān)聽機制和TCP協(xié)議，多個進程無法監(jiān)聽同一個端口，但是具體到nginx，可以多個nginx進程監(jiān)聽到不同端口，通過一個主進程端口做upstream來實現(xiàn)負載均衡，這個有點類似于網(wǎng)絡的匯聚，可以設置不同的策略，比如iphash，urlhash或者RR。
創(chuàng)新互聯(lián)長期為上千多家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為豐澤企業(yè)提供專業(yè)的網(wǎng)站設計、成都網(wǎng)站建設，豐澤網(wǎng)站改版等技術(shù)服務。擁有十年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
參照的是 這個文章
首先自己寫一段demo
里面負責2件事
doSomeThingOne
genSomeBytes
運行這個程序go run main.go
To install thewrk,you need only:
git clone
cd wrk
make
wrk relies on the openssl and luajit, learn more from its github page
Generating requests
Our demo is listening on the port 9876 ,so let's generate some requests for that.
./wrk -c400 -t8 -d5m
-c400means we have 400 connections to keep open
-t8means we use 8 threads to build requests
-d5mmeans the duration of the test will last for 5 minutes
用這段命令來壓服務器
Our server is very busy now and we can see some information via browser. Inputlocalhost:9876/debug/pprofyou will see:
然后用命令進入
在這里能看見各種方法的運行時間
所以我們安裝Graphviz 在mac下
brew install graphviz
之后再這個(pprof)里面輸入web
會生產(chǎn)一個svg文件
用瀏覽器打開我們就會看到
很顯然gensomebytes里面的math方法最消耗時間。這個就是我們優(yōu)化的對象
其實也很方便在
localhost:9876/debug/pprof/profile改成
localhost:9876/debug/pprof/heap
后面的結(jié)果一樣。。和cpu一樣可以看到那個heap占用了大量的內(nèi)存到時候優(yōu)化吧
這個文章里面的第一個方法就可以做測試內(nèi)存占用的.
有空試試把
分布式程序 A B C D 4個進程在服務器. 監(jiān)控程序E 打包程序F
寫一個監(jiān)控程序定時監(jiān)控這4個進程的CPU 內(nèi)存(搞成配置文件)
達到性能瓶頸（例如 90%CPU 內(nèi)存剩下10%）? E用shell觸發(fā)打包程序F把pprof等信息打包.并發(fā)送郵件
給配置者.
Go語言由Google公司開發(fā)，并于2009年開源，相比Java/Python/C等語言，Go尤其擅長并發(fā)編程，性能堪比C語言，開發(fā)效率肩比Python，被譽為“21世紀的C語言”。
Go語言在云計算、大數(shù)據(jù)、微服務、高并發(fā)領域應用應用非常廣泛。BAT大廠正在把Go作為新項目開發(fā)的首選語言。
Go語言能干什么?
1、服務端開發(fā)：以前你使用C或者C++做的那些事情，用Go來做很合適，例如日志處理、文件系統(tǒng)、監(jiān)控系統(tǒng)等;
2、DevOps：運維生態(tài)中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go語言開發(fā);
3、網(wǎng)絡編程：大量優(yōu)秀的Web框架如Echo、Gin、Iris、beego等，而且Go內(nèi)置的 net/http包十分的優(yōu)秀;
4、Paas云平臺領域：Kubernetes和Docker Swarm等;
5、分布式存儲領域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、區(qū)塊鏈領域：區(qū)塊鏈里面有兩個明星項目以太坊和fabric都使用Go語言;
7、容器虛擬化：大名鼎鼎的Docker就是使用Go語言實現(xiàn)的;
8、爬蟲及大數(shù)據(jù)：Go語言天生支持并發(fā)，所以十分適合編寫分布式爬蟲及大數(shù)據(jù)處理。
簡單來說， SetMaxHeap 提供了一種可以設置固定觸發(fā)閾值的 GC （Garbage Collection垃圾回收）方式
官方源碼鏈接
大量臨時對象分配導致的 GC 觸發(fā)頻率過高， GC 后實際存活的對象較少，
或者機器內(nèi)存較充足，希望使用剩余內(nèi)存，降低 GC 頻率的場景
GC 會 STW （ Stop The World ），對于時延敏感場景，在一個周期內(nèi)連續(xù)觸發(fā)兩輪 GC ，那么 STW 和 GC 占用的 CPU 資源都會造成很大的影響， SetMaxHeap 并不一定是完美的，在某些場景下做了些權(quán)衡，官方也在進行相關(guān)的實驗，當前方案仍沒有合入主版本。
先看下如果沒有 SetMaxHeap ，對于如上所述的場景的解決方案
這里簡單說下 GC 的幾個值的含義，可通過 GODEBUG=gctrace=1 獲得如下數(shù)據(jù)
這里只關(guān)注 128-132-67 MB 135 MB goal ，
分別為 GC開始時內(nèi)存使用量 - GC標記完成時內(nèi)存使用量 - GC標記完成時的存活內(nèi)存量 本輪GC標記完成時的 預期 內(nèi)存使用量（上一輪 GC 完成時確定）
引用 GC peace設計文檔 中的一張圖來說明
對應關(guān)系如下：
簡單說下 GC pacing （信用機制）
GC pacing 有兩個目標，
那么當一輪 GC 完成時，如何只根據(jù)本輪 GC 存活量去實現(xiàn)這兩個小目標呢？
這里實際是根據(jù)當前的一些數(shù)據(jù)或狀態(tài)去 預估 “未來”，所有會存在些誤差
首先確定 gc Goal goal = memstats.heap_marked + memstats.heap_marked*uint64(gcpercent)/100
heap_marked 為本輪 GC 存活量， gcpercent 默認為 100 ，可以通過環(huán)境變量 GOGC=100 或者 debug.SetGCPercent(100) 來設置
那么默認情況下 goal = 2 * heap_marked
gc_trigger 是與 goal 相關(guān)的一個值（ gc_trigger 大約為 goal 的 90% 左右），每輪 GC 標記完成時，會根據(jù) |Ha-Hg| 和實際使用的 cpu 資源 動態(tài)調(diào)整 gc_trigger 與 goal 的差值
goal 與 gc_trigger 的差值即為，為 GC 期間分配的對象所預留的空間
GC pacing 還會預估下一輪 GC 發(fā)生時，需要掃描對象對象的總量，進而換算為下一輪 GC 所需的工作量，進而計算出 mark assist 的值
本輪 GC 觸發(fā)（ gc_trigger ），到本輪的 goal 期間，需要盡力完成 GC mark 標記操作，所以當 GC 期間，某個 goroutine 分配大量內(nèi)存時，就會被拉去做 mark assist 工作，先進行 GC mark 標記賺取足夠的信用值后，才能分配對應大小的對象
根據(jù)本輪 GC 存活的內(nèi)存量（ heap_marked ）和下一輪 GC 觸發(fā)的閾值（ gc_trigger ）計算 sweep assist 的值，本輪 GC 完成，到下一輪 GC 觸發(fā)（ gc_trigger ）時，需要盡力完成 sweep 清掃操作
預估下一輪 GC 所需的工作量的方式如下：
繼續(xù)分析文章開頭的問題，如何充分利用剩余內(nèi)存，降低 GC 頻率和 GC 對 CPU 的資源消耗
如上圖可以看出， GC 后，存活的對象為 2GB 左右，如果將 gcpercent 設置為 400 ，那么就可以將下一輪 GC 觸發(fā)閾值提升到 10GB 左右
前面一輪看起來很好，提升了 GC 觸發(fā)的閾值到 10GB ，但是如果某一輪 GC 后的存活對象到達 2.5GB 的時候，那么下一輪 GC 觸發(fā)的閾值，將會超過內(nèi)存閾值，造成 OOM （ Out of Memory ），進而導致程序崩潰。
可以通過 GOGC=off 或者 debug.SetGCPercent(-1) 來關(guān)閉 GC
可以通過進程外監(jiān)控內(nèi)存使用狀態(tài)，使用信號觸發(fā)的方式通知程序，或 ReadMemStats 、或 linkname runtime.heapRetained 等方式進行堆內(nèi)存使用的監(jiān)測
可以通過調(diào)用 runtime.GC() 或者 debug.FreeOSMemory() 來手動進行 GC 。
這里還需要說幾個事情來解釋這個方案所存在的問題
通過 GOGC=off 或者 debug.SetGCPercent(-1) 是如何關(guān)閉 GC 的？
gc 4 @1.006s 0%: 0.033+5.6+0.024 ms clock, 0.27+4.4/11/25+0.19 ms cpu, 428-428-16 MB, 17592186044415 MB goal, 8 P (forced)
通過 GC trace 可以看出，上面所說的 goal 變成了一個很詭異的值 17592186044415
實際上關(guān)閉 GC 后， Go 會將 goal 設置為一個極大值 ^uint64(0) ，那么對應的 GC 觸發(fā)閾值也被調(diào)成了一個極大值，這種處理方式看起來也沒什么問題，將閾值調(diào)大，預期永遠不會再觸發(fā) GC
那么如果在關(guān)閉 GC 的情況下，手動調(diào)用 runtime.GC() 會導致什么呢？
由于 goal 和 gc_trigger 被設置成了極大值， mark assist 和 sweep assist 也會按照這個錯誤的值去計算，導致工作量預估錯誤，這一點可以從 trace 中進行證明
可以看到很詭異的 trace 圖，這里不做深究，該方案與 GC pacing 信用機制不兼容
記住，不要在關(guān)閉 GC 的情況下手動觸發(fā) GC ，至少在當前 Go1.14 版本中仍存在這個問題
SetMaxHeap 的實現(xiàn)原理，簡單來說是強行控制了 goal 的值
注： SetMaxHeap ，本質(zhì)上是一個軟限制，并不能解決 極端場景 下的 OOM ，可以配合內(nèi)存監(jiān)控和 debug.FreeOSMemory() 使用
SetMaxHeap 控制的是堆內(nèi)存大小， Go 中除了堆內(nèi)存還分配了如下內(nèi)存，所以實際使用過程中，與實際硬件內(nèi)存閾值之間需要留有一部分余量。
對于文章開始所述問題，使用 SetMaxHeap 后，預期的 GC 過程大概是這個樣子
簡單用法1
該方法簡單粗暴，直接將 goal 設置為了固定值
注：通過上文所講，觸發(fā) GC 實際上是 gc_trigger ，所以當閾值設置為 12GB 時，會提前一點觸發(fā) GC ，這里為了描述方便，近似認為 gc_trigger=goal
簡單用法2
當不關(guān)閉 GC 時， SetMaxHeap 的邏輯是， goal 仍按照 gcpercent 進行計算，當 goal 小于 SetMaxHeap 閾值時不進行處理；當 goal 大于 SetMaxHeap 閾值時，將 goal 限制為 SetMaxHeap 閾值
注：通過上文所講，觸發(fā) GC 實際上是 gc_trigger ，所以當閾值設置為 12GB 時，會提前一點觸發(fā) GC ，這里為了描述方便，近似認為 gc_trigger=goal
切換到 go1.14 分支，作者選擇了 git checkout go1.14.5
選擇官方提供的 cherry-pick 方式(可能需要梯子，文件改動不多，我后面會列出具體改動)
git fetch "" refs/changes/67/227767/3 git cherry-pick FETCH_HEAD
需要重新編譯Go源碼
注意點：
下面源碼中的官方注釋說的比較清楚，在一些關(guān)鍵位置加入了中文注釋
入?yún)ytes為要設置的閾值
notify 簡單理解為 GC 的策略 發(fā)生變化時會向 channel 發(fā)送通知，后續(xù)源碼可以看出“策略”具體指哪些內(nèi)容
返回值為本次設置之前的 MaxHeap 值
$GOROOT/src/runtime/debug/garbage.go
$GOROOT/src/runtime/mgc.go
注：作者盡量用通俗易懂的語言去解釋 Go 的一些機制和 SetMaxHeap 功能，可能有些描述與實現(xiàn)細節(jié)不完全一致，如有錯誤還請指出
重慶分公司
重慶分公司
