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.
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. From: <golang-nuts@googlegroups.com> on behalf of gaurav <gauravagarw...@gmail.com> Date: Tuesday, August 9, 2016 at 7:17 AM To: golang-nuts <golang-nuts@googlegroups.com> 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+unsubscr...@googlegroups.com. 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.
