If I understood your scenario correctly, I would assume that it is not the Goroutines overhead per se but the traceroute command processes spawned in the Goroutines that drives the resource demand. The pure Goroutine memory overhead should be quite neglectable (size of G struct + initial dynamic stack). Thus, I would look for packages that provide traceroute like functionality (e.g. https://github.com/aeden/traceroute) to execute the ICMP requests in process.
Am Donnerstag, 16. August 2018 05:29:44 UTC+2 schrieb faizan khan: > > Hi everyone, > > I am writing a CLI based golang programme which will run traceroute > command for a range of IPs. Sometimes a range will include 63*256*256 ips, > which is close to 4 million IPs. Each traceroute runs in a goroutine and > then there is a watcher goroutines that acts on the console output from the > traceroute. so for each ip 2 goroutines. I have capped the number of > goroutines to 512 by creating a buffered channel. > > After a lot of trial and error I have had a stable run on an 8GB server > with an 8GB swap file, if I run the same programme on a 512MB server with > 1GB swap file, it takes the server to peak utilization thereby shutting me > out. After which I have to restart my server to gain access again. If I > lower the buffered channel size to 100 on the 512MB server it runs fine. > > Is there a formula of some sort using which I can find out the server size > from the number of goroutines or the go programme... > > cheers, > Faizan > -- 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.
