Please find reply inline:

On Tuesday, August 9, 2016 at 8:10:46 PM UTC+5:30, Michael Jones wrote:
>
> First, a related question—if an attempt to allocate is about to fail, or 
> succeeds while crossing a threshold of “low memory remaining” (if this is 
> even knowable), does/should the runtime change the GC policy to be very 
> aggressive and exploit all possible avenues to remedy? A low water / high 
> water system where when there us much free space the pauses are as small as 
> possible while when in distress aggressive measures are used seems 
> beneficial.
>
>  
>
That would have been acceptable behavior in this situation.
 

> Second, on the actual question—what you seek is difficult. The OS has 
> generally allocated and charged the process with big chunks of unused 
> memory. Freeing activities within the process (Go runtime/GC) do result in 
> less memory pressure in the VM sense while often not reducing the 
> OS-visible number. In some systems the reported number does not go down 
> quickly or at all when the memory is released by the process. So, the 
> metric is difficult to obtain so testing against it is hard.
>
What I was referring to was a bound on heap size that Go's runtime could 
maintain. If there was a way to communicate to Go an upper-bound on max 
heap and the runtime always kicked in GC when it approached that bound 
(even blocking allocations to keep heap size within this limit), would it 
would have helped here? I think this is what you were mentioning above?  

>  
>
> *From: *<golan...@googlegroups.com <javascript:>> on behalf of gaurav <
> gaurava...@gmail.com <javascript:>>
> *Date: *Tuesday, August 9, 2016 at 7:17 AM
> *To: *golang-nuts <golan...@googlegroups.com <javascript:>>
> *Subject: *[go-nuts] Re: go process memory limits and gurantees
>
>  
>
> Thank you for the confirmation!
>
>  
>
> Wonder if I am approaching the problem in a wrong way? How is memory 
> sizing usually done for Go applications - if one is not willing to allocate 
> 2X of the process (real) memory needs?
>
> On Tuesday, August 9, 2016 at 8:15:37 AM UTC+5:30, bronze man wrote:
>
> I do not find this kind of api in golang.
>
> If you found one,please tell me.
>
>  
>
> The best you can do is that calling debug.SetGCPercent(10) to tell golang 
> gc quicker, calling debug.FreeOsMemory() every second to free os memory 
> faster and trying to reduce memory alloc number and size.
>
>  
>
>
> On Sunday, August 7, 2016 at 4:37:42 PM UTC+8, gaurav wrote:
>
> Hi everyone,
>
>  
>
> I am a bit unclear about how to specify memory limits for Go processes and 
> what can be assumed about the Garbage collection behavior when approaching 
> such a memory limit. 
>
>  
>
> Specifically, I would want to be able to 'tell' a Go process to not use 
> more than X GB of RAM and then expect that if ever the process 
> panics/crashes due to lack of memory, then it can be assumed that there are 
> enough live objects that account for entire of the 'permitted' X GB limit.
>
>  
>
> I understand the OS constructs can be used to limit process memory but 
> that will probably not be sufficient  - as the process could have been 
> killed by OS even though Go GC could have internally freed up memory and 
> used that instead of asking OS for more.
>
>  
>
> I understand that fiddling with GOGC will make the GC more aggressive but 
> it doesn't feel right to make this too aggressive to enforce the above 
> desired behavior. Keeping it at default will probably only guarantee me 
> that half the heap contains live/useful objects at any give time.
>
>  
>
> Please let me know if there is something I have missed to read regarding 
> this or if there is already a way to achieve this?
>
>  
>
> --
>
> cheers,
>
> gaurav
>
>  
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to