Closed reneklacan closed 6 years ago
I think this has something todo with the libvips bindings. Based on the commit I make the assumption that @h2non has run several benchmarks (The vegeta changes in the same commit) and that it seemed a good idea at that time.
However, to get a real answer you should wait for @h2non's reply :-)
@Dynom is right. Note that that commit has almost 3 years old, so things may changed since then.
At that time, I was running several exploratory benchmarks and found that some scenarios after stressing the server, the memory increased considerably without freeing up in a relatively short time. After some research and trial-error, I found that in cgo
code, explicitly freeing memory had some benefits in order to decrease resident memory pressure in shorter periods.
Go runtime/GC has improved since then, so it might not have an obvious benefit doing that these days. That being said, the code has been running for quite a while and I don't know user reported issues that could be directly caused by this.
I guess doing some benchmarking/profiling can only clarify this.
Thank you for your answers.
Based on my experiments with 40 instances serving together ~400 requests per second tweaking -mrelease
doesn't have any visible effect on memory consumption which is averaging at ~4.5GB per instance.
Can I please ask you what's the main reason for having
-mrelease
option with the default value of30
.Commit adding this feature is not really explaining anything https://github.com/h2non/imaginary/commit/cad8a2d4d149392ed0272fc81078625bf3d952c5
According to some sources
FreeOSMemory
might not be the best thing to run on production.But I'm not a Go programmer so I'm wondering if you have production experience that suggests that periodically calling
FreeOSMemory
is a positive thing.