Postgres max_connections woes

<p>So a site that I&#39;m maintaining has recently hit some &#34;too many client connections&#34; errors from the database. Since Postgres defaults to a maximum of 100 connections, I called <code>db.SetMaxOpenConns(100)</code>, but it kept happening. My initial fix for that was to subtract the number of connections reserved for the superuser, which defaults to 3, and that seemed to work, but after a while I started seeing them again. I&#39;m now subtracting max_connections by 10 (kind of a crapshoot), and so far it looks good, but I&#39;m keeping an eye on it.</p> <p>My question is, why does setting the maximum number of connections in Go to the value defined in the database not work? Is there a fundamental difference behind the definition of &#34;connection&#34; used by Go versus the one used by Postgres, or is there something else going on?</p> <hr/>**评论：**<br/><br/>hayzeus: <pre><p>The max connections parameter works fine, but you should not be trying to run that close to the server limit.</p> <p>Firstly, do you really need 100 connections? And are you leaving 100 idle connections in the pool? You could try lowering that. Bear in mind that if you hit the max connection limit in your app, you&#39;ll still get a connection when one is free. If you hit that limit in postgres, you&#39;re screwed.</p> <p>You can also use pgbouncer or another proxy in transaction mode. In general, using a connection manager with postgres is a good idea in a serious production site. <a href="https://pgbouncer.github.io/" rel="nofollow">https://pgbouncer.github.io/</a> </p> <p>Finally, the postgres default of 100 connections is pretty low. I generally up the limit to 500-800, but you may need tweak some sysctl settings.</p> <p>Source: I&#39;ve been using postgres since 7.xish</p></pre>tty5: <pre><p>Run <code>SELECT * FROM pg_stat_activity;</code> when it runs out of connections - see what else is there.</p></pre>mixedCase_: <pre><p>When benchmarking with wrk a REST api I made that hits the database, I had the same experience you did: The max amount of open connections managed by Go should not exceed 90% of postgres&#39; max allowed or else the Go app is going to starve.</p> <p>I have no idea what causes it or if 90% is the right number, but after following that rule, I haven&#39;t had the application ever starve no matter the load.</p></pre>tex0: <pre><p>Why do you need that many concurrent connections? We&#39;ve managed to have no more than a dozen open db connections on a fairly busy production API.</p></pre>geordano: <pre><p>May be try to tune your db, this may help <a href="http://pgtune.leopard.in.ua/" rel="nofollow">http://pgtune.leopard.in.ua/</a></p></pre>: <pre><p>[deleted]</p></pre>MoneyWorthington: <pre><p>No, because the documentation for <code>database/sql</code> says that it handles its own pooling. Is there a reason to use one specifically for Postgres?</p></pre>thematrix307: <pre><p>Ah, do you have a single application server?</p></pre>