Serhat Şevki Dinçer, FYI
Swapfiles by default in Ubuntu http://blog.surgut.co.uk/2016/12/swapfiles-by-default-in-ubuntu.html "By default, in Ubuntu, we usually create a swap partition." "Starting from 17.04 Zesty Zapus release, instead of creating swap partitions, swapfiles will be used by default for non-lvm based installations." Peter On Wednesday, May 3, 2017 at 2:19:25 PM UTC-4, peterGo wrote: > > Serhat Şevki Dinçer, > > "why cant peterGo reproduce the crash?" > > Because I have swap space. > > $ go build ssd.go > $ cat /proc/swaps > Filename Type Size Used Priority > /dev/sda5 partition 7999484 0 -1 > $ ./ssd > 8 > 9 > $ cat /proc/swaps > Filename Type Size Used Priority > /dev/sda5 partition 7999484 1723860 -1 > $ > > Peter > > On Wednesday, May 3, 2017 at 11:24:40 AM UTC-4, Serhat Şevki Dinçer wrote: >> >> Ok if GOGC is the trigger point, then out-of-memory error should be >> consistent on all Ubuntu 64-bit 4gb systems, right? >> If so, why cant peterGo reproduce the crash? >> >> 2 May 2017 16:08 tarihinde "Юрий Соколов" <funny....@gmail.com> yazdı: >> >>> There is nowhere told that GOGC defines border that could not be >>> reached. GOGC defines proportion that triggers GC, ie GC is triggered AFTER >>> GOGC proportion crossed, not before. >>> >>> In fact, if you allocates by small portions, then GC tries to predict >>> when you will reach this border, and tries to start earlier. But it doesn't >>> stop your program if you run faster and cross this border, cause current >>> Golang GC us concurrent and tries to minimize GC pause. How could it >>> minimize GC pause if it ought to stop whole your program to not cross GOGC >>> proportion? >>> >>> And you partially right: GC of old Go's versions may stop program before >>> GOGC proportion crossed. So, if you try Go 1.0 most likely your programm >>> will run. >>> >>> But new behaviour is much better. >>> >>> The point: you should know your instrument and environment. No one GC >>> enabled runtime will be happy if you allocate huge arrays (perl/python/php >>> are exceptions, cause they use reference counting). If you ought to >>> allocate huge arrays in GC runtime, use off-heap allocation (Java men learn >>> that hard way). >>> >>> For example, you may use mmap to allocate huge array. >>> >>> Or, I'll repeat my self, use datastructure without huge continuous >>> allocation (ie slice of slices for your example). Then GC will have a >>> chance to trigger ealier and free some memory before it exhausted. >>> >>> 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" < >>> jfcg...@gmail.com> написал: >>> >>> The allocation request (make) is made to the runtime which covers GC, >>> right? GC percent is also set to 10%. >>> After 1st call returns, my app has about 2gb ram allocated. When 2nd >>> call requests allocation, runtime cannot: >>> - first allocate another 2gb >>> - free the 1st buffer later >>> due to the definition of the GOGC (GC percent). >>> I think this is a GC bug. >>> >>> 2 May 2017 07:09 tarihinde "Sokolov Yura" <funny....@gmail.com> yazdı: >>> >>> GC is triggered *after* allocation than crosses boundary. So your second >>>> allocation is actually tries to complete before first allocation freed. >>>> And >>>> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause >>>> overcommit is not enabled by default. >>>> >>>> Use C/C++, or buy more memory, or change your datastructure from slice >>>> to slice of slice and allocate second dimension lazely, or call >>>> runtime.GC() explicitely between calls to f() (it will block until GC >>>> finishes). >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "golang-nuts" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/golang-nuts/HrZpsyfb3i0/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> golang-nuts...@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.
