Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
testify gets basically everything about Go testing wrong. It even takes its arguments in the wrong order.
https://github.com/golang/go/wiki/TestComments#assert-librar...
https://github.com/golang/go/wiki/TestComments#got-before-wa...
They did at least:
https://github.com/golang/go/wiki/TestComments#compare-full-...
Although the diff-ing is significantly more limited than cmp.
Definitely a memory leak, but the code is like < 50 lines -- it's a memory leak (and/or my bone-headed misuse) in the underlying library, fasthttp.
I got some help with fixing it from a reader though:
https://gitlab.com/mrman/kcup-go/-/merge_requests/7
Again, the goal was to serve a single file -- I should point out that v1 was using net/http and it did quite well (memory scaled up and down as necessary), but the combination of resource contraints (on my side, I only gave it 100MB of RAM), and use of fasthttp that wasn't ideal/correct caused the issues. It went something like this:
v1 - net/http
> There's a proposal in github about being able to set an upper memory limit. Right now, you'd have to live with the possibility of being evicted from a k8s cluster however.
You've activated my trap card! I actually have another issue with k8s -- their rejection of swap seems like a bad judgement (though I'm sure it helped them ship faster and accomplish other things -- I just made this comment[0].
> That being said, if you think your go process shouldn't be consuming "that much memory (user definition here)", it's time to start profiling. I've uncovered my fair share of pebcak memory leaks that way.
Yeah but I was trying to serve... a single file with contents in memory. I'm pretty biased for Rust, but at some level isn't it a bit ridiculous if I have to break out the profiler for that? I spent like 30 minutes figuring and ultimately searching for the right combination of `move` and `async` to figure out how to give the async closures the right reference, but that code is much easier to read (for me, since I have paid the Rust tax), much more correct, and performed very well without me having to pull out a profiler.
[0]: https://github.com/kubernetes/kubernetes/issues/53533#issuec...
It sounds like you have a memory leak in your golang app. That shouldn't be happening. Time to bust out pprof.
I'd say though GC is what limits golang as a systems language. If you are doing lots of memory heavy things, I'd say golang is not the correct language to use. You probably should never implement a database in golang for example. You end up with never ending memory issues that are very difficult to ever solve. Prometheus has been plagued from this since its inception. The latest fun Prometheus memory thing is it uses twice the memory at startup that it actually needs during runtime when reading its wal logs [1]. Cassandra has similar fun times in Java.
[1] https://github.com/prometheus/prometheus/issues/6934
> Checking to see whether the interface "contains" a nil pointer is almost always an error. It is not something you should ever do when you have an interface value.
So here's where I do that:
https://github.com/gwd/session-scheduler/blob/master/handle_...
The pattern is basically:
var foo = interface{}