我正在尋找類(lèi)似于-XmxJava 的選項(xiàng)，即分配我的 Go 應(yīng)用程序可以使用的最大運(yùn)行時(shí)內(nèi)存。正在檢查運(yùn)行時(shí)，但如果那是要走的路，則不完全檢查。我嘗試用 func SetMaxStack() 設(shè)置這樣的東西，（可能非常愚蠢）debug.SetMaxStack(5000000000) // bytesmodel.ExcelCreator()我之所以要這樣做，是因?yàn)槟壳坝凶銐虻?RAM 可用，但應(yīng)用程序不會(huì)消耗超過(guò) 4-6%，我在這里可能是錯(cuò)的，但它可能會(huì)迫使 GC 發(fā)生的速度比需要的快得多導(dǎo)致性能問(wèn)題。我在做什么從 RDBMS 系統(tǒng)獲取大數(shù)據(jù)集，處理它以在 excel 中寫(xiě)出。我尋找這樣一個(gè)選項(xiàng)的另一個(gè)原因是限制最終部署它的服務(wù)器上 RAM 的最大使用量。對(duì)此的任何提示將不勝感激。
1 回答
largeQ
TA貢獻(xiàn)2039條經(jīng)驗(yàn) 獲得超8個(gè)贊
當(dāng)前穩(wěn)定的 Go (1.10) 只有一個(gè)旋鈕，可用于通過(guò) Go 運(yùn)行時(shí)執(zhí)行的垃圾收集來(lái)交換內(nèi)存以降低 CPU 使用率。這個(gè)旋鈕叫做GOGC，它的描述是
該
GOGC變量設(shè)置初始垃圾收集目標(biāo)百分比。當(dāng)新分配的數(shù)據(jù)與上次收集后剩余的實(shí)時(shí)數(shù)據(jù)的比率達(dá)到此百分比時(shí)，將觸發(fā)收集。默認(rèn)值為GOGC=100。設(shè)置GOGC=off完全禁用垃圾收集器。該runtime/debug包的SetGCPercent功能允許在運(yùn)行時(shí)更改此百分比。
因此，基本上將其設(shè)置為200將使正在運(yùn)行的進(jìn)程的 Go 運(yùn)行時(shí)可能使用的內(nèi)存量增加一倍。
話(huà)雖如此，我會(huì)注意到 Go 運(yùn)行時(shí)實(shí)際上會(huì)嘗試將其垃圾收集器的行為調(diào)整為您正在運(yùn)行的程序的工作負(fù)載和手頭的 CPU 處理能力。我的意思是，通常情況下你的程序不消耗大量 RAM 并沒(méi)有什么問(wèn)題——如果收集器恰好以足夠快的速度清除垃圾而不會(huì)顯著影響性能，我認(rèn)為沒(méi)有理由擔(dān)心：Go 的 GC 是其中之一在運(yùn)行時(shí)進(jìn)行了最激烈的微調(diào)，實(shí)際上效果很好。
因此，您可以嘗試采用另一條路線(xiàn)：
分析程序的內(nèi)存分配。分析配置文件并嘗試找出熱點(diǎn)在哪里，以及是否（以及如何）優(yōu)化它們。
優(yōu)化。通常，這相當(dāng)于使某些緩沖區(qū)可在對(duì)使用它們的相同函數(shù)的不同調(diào)用之間重復(fù)使用，預(yù)分配切片而不是逐漸增加它們，在認(rèn)為有用的
sync.Pool地方使用等。這些措施實(shí)際上可能會(huì)增加真正使用的內(nèi)存（即，活動(dòng)對(duì)象——而不是垃圾），但它可能會(huì)降低 GC 的壓力。
- 1 回答
- 0 關(guān)注
- 111 瀏覽
添加回答
舉報(bào)
0/150
提交
取消