Low memory setup for simple golang apps

<p>Hello everyone. I have been using appengine to run some simple test apps. The memory usage on appengine for most of these apps is 7-10MB.</p> <p>I wanted to switch some of these apps to a digital ocean 512MB droplet. What setup should I use to get golang running and make the most efficient use of memory?</p> <hr/>**评论：**<br/><br/>very-little-gravitas: <pre><p>A single golang process behind a proxy like caddy (for transparent tls) and a db will easily run on a 512 instance and serve at least 100 concurrent connections without problems. Several instances should be fine behind a proxy too on a 512 if your sites are not high traffic ones. Which flavour of Linux doesn&#39;t matter so much, coreos looks nice but requires docker which you probably don&#39;t need. </p> <p>Try it and you will be pleasantly surprised.</p></pre>balloonanimalfarm: <pre><p>I second this, you can run a lot on one of these little servers--I have 5 websites on one plus a largeish go app on an Ubuntu image. If you use MySQL make sure to tune it though, it likes to hog memory even when it doesn&#39;t need it.</p></pre>very-little-gravitas: <pre><p>I&#39;d recommend using Postgres rather than MySQL, no tuning required and it is IMO a better db.</p></pre>balloonanimalfarm: <pre><p>sqlite is also a good choice for small sites, and it has a good go driver. Unfortunately not every off the shelf software supports it.</p></pre>very-little-gravitas: <pre><p>A couple of problems using sqlite with go:</p> <ul> <li>It requires cgo, which makes cross-compilation difficult, I prefer to deploy binaries.</li> <li>It requires a global lock on the db for writes, fine for small sites with very low usage I guess, but it wasn&#39;t really designed with concurrency in mind. </li> </ul></pre>THEHIPP0: <pre><blockquote> <p>It requires cgo, which makes cross-compilation difficult, I prefer to deploy binaries.</p> </blockquote> <p>cgo still produces binaries.</p> <blockquote> <p>It requires a global lock on the db for writes, fine for small sites with very low usage I guess, but it wasn&#39;t really designed with concurrency in mind.</p> </blockquote> <p>This is not true since sqlite 3.0 anymore.</p></pre>very-little-gravitas: <pre><blockquote> <p>cgo still produces binaries.</p> </blockquote> <p>What I was trying to say was that it makes cross-compilation painful (see problems here for example - <a href="https://github.com/mattn/go-sqlite3/issues/106" rel="nofollow">https://github.com/mattn/go-sqlite3/issues/106</a>). I&#39;m targeting linux servers from OS X and prefer to compile locally. </p> <blockquote> <p>This is not true since sqlite 3.0 anymore.</p> </blockquote> <p>Great thanks, I didn&#39;t know that, it is a wonderful db. </p></pre>dewey4iv: <pre><p>I&#39;m not 100% sure of what you are asking...but here goes:</p> <p>If you are trying to get the &#39;Most Band for Your Buck&#39; I&#39;d suggest going CoreOS and using Docker to get greater density on a single server with multiple processes running. </p></pre>porkbonk: <pre><p>How would using Docker help with less memory use?</p></pre>dewey4iv: <pre><p>It&#39;s more about server density -- making greater usage of the server (especially w/ 512mb total and app usage ~= 7-10mb). RAM isn&#39;t going to be the issue. CoreOS == very light-weight distro and it&#39;s very VERY easy to scale from 1 -&gt; 30 nodes (if needed). Docker containers give you the separation and easy management of a lot of little apps. I have a 5 node cluster running about 60 long-term processes and others that are scheduled as &#34;jobs&#34;. I don&#39;t have to mess around with brittle LB configs or worry when a single node going down or needs to be rebooted. </p></pre>