I haven't tried tip yet, but I saw this patch yesterday. It looks like this might help as I'm not using these pools directly. Over time though, I would expect the GC to free the memory allocated. It's true that I see much lower values in the profiler for the in_use memory, but I wonder why my machine keeps saying that the application is using quite some memory (400 MB for a simple web app seems quite a lot)... maybe the GC collects the memory but does not return it to the system?
@Andrey: I might create a gist, unfortunately I can't share the full codebase. The initialization though, looks mostly like that: https://github.com/zalando/chimp/blob/master/api/server.go#L124 . I wonder if setting proper read and write timeouts and disabling keepalives might help. On Saturday, October 15, 2016 at 8:43:44 PM UTC+2, alb.do...@gmail.com wrote: > > Does this happens on tip too? There was a recent CL that > modified the code of the nat pool; see > > https://go-review.googlesource.com/#/c/30613/ > > exp. the "Eliminate allocation in divLarge nat pool" part. > > > Il giorno sabato 15 ottobre 2016 16:28:01 UTC+2, Raffaele Di Fazio ha > scritto: >> >> Hi, >> I have a web application that over time uses more and more memory. This >> is the output of pprof of the heap: >> >> go tool pprof -alloc_space lushan-server https: >> //localhost:8083/debug/pprof/heap >> Fetching profile from https://localhost:8083/debug/pprof/heap >> Saved profile in /Users/rdifazio/pprof/pprof.lushan-server.localhost: >> 8083.alloc_objects.alloc_space.022.pb.gz >> Entering interactive mode (type "help" for commands) >> (pprof) top >> 43.06MB of 67.07MB total (64.20%) >> Dropped 4 nodes (cum <= 0.34MB) >> Showing top 10 nodes out of 188 (cum >= 1.50MB) >> flat flat% sum% cum cum% >> 26MB 38.76% 38.76% 26MB 38.76% math/big.putNat >> 3MB 4.48% 43.24% 3.50MB 5.22% encoding/json.(*decodeState). >> objectInterface >> 2.50MB 3.73% 46.97% 2.50MB 3.73% crypto/tls.(*Conn).write >> 2MB 2.98% 49.96% 2MB 2.98% crypto/tls.(*block).reserve >> 2MB 2.98% 52.94% 10.50MB 15.66% encoding/json.Unmarshal >> 1.55MB 2.31% 55.25% 1.55MB 2.31% regexp.(*bitState).reset >> 1.50MB 2.24% 57.49% 9.50MB 14.17% github.com/go-openapi/spec.(* >> Schema).UnmarshalJSON >> 1.50MB 2.24% 59.72% 27.50MB 41.00% math/big.nat.divLarge >> 1.50MB 2.24% 61.96% 5.50MB 8.20% math/big.nat.expNN >> 1.50MB 2.24% 64.20% 1.50MB 2.24% crypto/sha512.New384 >> (pprof) >> >> >> ROUTINE ======================== math/big.putNat in /usr/local/Cellar/go/ >> 1.7.1/libexec/src/math/big/nat.go >> 26MB 26MB (flat, cum) 38.76% of Total >> . . 550: } >> . . 551: return z.make(n) >> . . 552:} >> . . 553: >> . . 554:func putNat(x nat) { >> 26MB 26MB 555: natPool.Put(x) >> . . 556:} >> . . 557: >> . . 558:var natPool sync.Pool >> . . 559: >> . . 560:// q = (uIn-r)/v, with 0 <= r < y >> >> >> >> The memory allocated in math/big.putNat seems to increase over time, >> generating a very high usage of memory for a web applications that is >> executing very few requests per second. I wonder why and how I can better >> analyze this issue. Please notice that this happens only when serving >> HTTPS. >> >> I'm currently using go 1.7 and the app itself uses the gin web framework. >> >> Thanks in advance! >> >> Raffaele >> > -- 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.
