3 ms·

> While we're here I'd love to talk about Go's lack of memory pressure control/feedback though. How people are working around it/using Go in production -- is ev

by kmlx 6y ago

> While we're here I'd love to talk about Go's lack of memory pressure control/feedback though. How people are working around it/using Go in production -- is everyone just right/over-provisioning servers? using `ulimit memlock`? Hoping on swap? none of these in my case. i simply used go’s benchmark tool to figure this out. i kept running it and trying out stuff along the way. at the end of development i ended up with a very performance-focused codebase. result: i now have a running golang app that’s been up for 2 years without a single restart, indirectly serving millions of users on just 4 cores and 4gb of ram. no memory leaks, no cpu issues. very impressive compared with the standard java solutions that that company usually pursues. this being said, it really depends on your use case. this golang software was a proxy that was handling an LRU cache. definitely not rocket science.

hardwaresofton 6y ago
> none of these in my case. i simply used go’s benchmark tool to figure this out. i kept running it and trying out stuff along the way. at the end of development i ended up with a very performance-focused codebase. That sounds like "right-provisioning", or am I misunderstanidng you? > result: i now have a running golang app that’s been up for 2 years without a single restart, indirectly serving millions of users on just 4 cores and 4gb of ram. no memory leaks, no cpu issues. very impressive compared with the standard java solutions that that company usually pursues. This kind ofexperience is exactly what I was expecting to get out of Golang, very easily. That said, 4 cores sand 4GB of RAM is a lot of resources for a single binary, also there is the magic of swap to save you if you ever get in trouble (the app would theoretically get slower to the point of becoming unresponsive). I'm not sure how complex this application is, and I'm certainly not arguing for Java (because that's both hard to optimize, tune and write in the first place) but I wonder if there's a difference in complexity here. Is it the usual 3 tier app kinda deal? > this being said, it really depends on your use case. this golang software was a proxy that was handling an LRU cache. definitely not rocket science. Ahh there it is, thanks for sharing this bit -- Go would function as an excellent LRU cache -- I assume this program is performing a redis like functionality for another app? Are you offering the LRU functionality itself to users? I am actually kind of interested in what it does now...

by kmlx 6y ago

hardwaresofton 6y ago

> none of these in my case. i simply used go’s benchmark tool to figure this out. i kept running it and trying out stuff along the way. at the end of development i ended up with a very performance-focused codebase. That sounds like "right-provisioning", or am I misunderstanidng you? > result: i now have a running golang app that’s been up for 2 years without a single restart, indirectly serving millions of users on just 4 cores and 4gb of ram. no memory leaks, no cpu issues. very impressive compared with the standard java solutions that that company usually pursues. This kind ofexperience is exactly what I was expecting to get out of Golang, very easily. That said, 4 cores sand 4GB of RAM is a lot of resources for a single binary, also there is the magic of swap to save you if you ever get in trouble (the app would theoretically get slower to the point of becoming unresponsive). I'm not sure how complex this application is, and I'm certainly not arguing for Java (because that's both hard to optimize, tune and write in the first place) but I wonder if there's a difference in complexity here. Is it the usual 3 tier app kinda deal? > this being said, it really depends on your use case. this golang software was a proxy that was handling an LRU cache. definitely not rocket science. Ahh there it is, thanks for sharing this bit -- Go would function as an excellent LRU cache -- I assume this program is performing a redis like functionality for another app? Are you offering the LRU functionality itself to users? I am actually kind of interested in what it does now...