4 ms·

> I ask because I just ran into this working on a tiny project whose only job was to serve a single file[0] (with few resources) and was immediately bit by the

> I ask because I just ran into this working on a tiny project whose only job was to serve a single file[0] (with few resources) and was immediately bit by the OOM killer (I used docker to artificially limit resources). This looks like some badly-written, memleak-inducing code. You can cause that in pretty much any language. To Golang's defence - we use InfluxDB and Telegraf on hundreds of production hosts and I've never seen those processes grabbing unhealthy amounts of memory.

hardwaresofton 6y ago
> This looks like some badly-written, memleak-inducing code. You can cause that in pretty much any language. Could you point at the line that is an obvious memory leak? There are three versions right now: v1 - net/http (no leak, but perf wasn't great in comparison) v2 - fasthttp v2.1 - fasthttp (+ []bytes) v2.2 - fasthttp (mem leak fixed thanks to a contribution) All of these versions are <50 lines of code. The issue was not the code I wrote, but my misuse of the underlying library (fasthttp in this case) -- but I don't think any part of the code I wrote stands out as particularly memleak-inducing. I'd like to think writing very similar code against net/http and fasthttp producing such different results is a bit of a problem, my golang code aside. The interfaces look the same, act the same, but seem to have wildly different consequences. > To Golang's defence - we use InfluxDB and Telegraf on hundreds of production hosts and I've never seen those processes grabbing unhealthy amounts of memory. This is reasonable, I expect InfluxDB to be very well written software, but I'd like to point out: - the Go devs at InfluxDB are way better than me at writing go - memory usage and management (and not blowing up your server) is a key feature of InfluxDB - I was trying to serve... a single file At this point I'm quite tempted to try this with PyPy + Falcon or NodeJS and see how similarly naive code would perform with 2 cores and 100MB. Those other languages have different characteristics (harder to deploy for example) but it feels like all I'd have to do is make the right library choice (which I tried to do for Go) to get some pretty decent performance (which I expected to get with Go).
- bitcharmer 6y ago
  You just admitted yourself in a reply to a sibling comment that there was a memory leak. What am I missing here?
  - hardwaresofton 6y ago
    > This looks like some badly-written, memleak-inducing code. You can cause that in pretty much any language. I must have misunderstood you because it read like you were suggesting the code could be determined to be memory leak inducing at a glance — wanted to know which part of it looked like that if so.

hardwaresofton 6y ago

> This looks like some badly-written, memleak-inducing code. You can cause that in pretty much any language. Could you point at the line that is an obvious memory leak? There are three versions right now: v1 - net/http (no leak, but perf wasn't great in comparison) v2 - fasthttp v2.1 - fasthttp (+ []bytes) v2.2 - fasthttp (mem leak fixed thanks to a contribution) All of these versions are <50 lines of code. The issue was not the code I wrote, but my misuse of the underlying library (fasthttp in this case) -- but I don't think any part of the code I wrote stands out as particularly memleak-inducing. I'd like to think writing very similar code against net/http and fasthttp producing such different results is a bit of a problem, my golang code aside. The interfaces look the same, act the same, but seem to have wildly different consequences. > To Golang's defence - we use InfluxDB and Telegraf on hundreds of production hosts and I've never seen those processes grabbing unhealthy amounts of memory. This is reasonable, I expect InfluxDB to be very well written software, but I'd like to point out: - the Go devs at InfluxDB are way better than me at writing go - memory usage and management (and not blowing up your server) is a key feature of InfluxDB - I was trying to serve... a single file At this point I'm quite tempted to try this with PyPy + Falcon or NodeJS and see how similarly naive code would perform with 2 cores and 100MB. Those other languages have different characteristics (harder to deploy for example) but it feels like all I'd have to do is make the right library choice (which I tried to do for Go) to get some pretty decent performance (which I expected to get with Go).

bitcharmer 6y ago
You just admitted yourself in a reply to a sibling comment that there was a memory leak. What am I missing here?
- hardwaresofton 6y ago
  > This looks like some badly-written, memleak-inducing code. You can cause that in pretty much any language. I must have misunderstood you because it read like you were suggesting the code could be determined to be memory leak inducing at a glance — wanted to know which part of it looked like that if so.