那在使用PG的时候,可能很快就会体会到PG之美, 与功能强大,这里就不在多说,今天要说的是,POSTGRESQL 在高并发下,超高连接对PG的冲击,以及为什么PG 在高并发连接中,需要使用pgbouncer...而为了获取这些信息的变化对share_buffer 和 backend 的临时数据进行获取,他会遍历到其他的process, 而如果我们建立的backend越多, 也就是连接到PG的连接越多, 就会导致遍历获取数据...和系统无响应的情况中, 而是随着backend变多后,内部沟通的成本变高,导致性能上的问题,所以PG在多连接中,是需要使用PGPOOL 或者 pgbouncer 之类的缓冲池来保证系统的性能,另外还有一个问题就是为什么要有这么多的连接...那既然知道了PG在处理超多的连接上会有性能的问题,那如何解决这个问题对大多数使用的人就有相关的意义,可以带着这个问题来问几个问题
1 为什么要有并发那么多连接, 例如一个数据库要承受3000+以上的连接数...idle in transaction 这也就说明经常有大事务长时间在等待什么,这也是解决问题的一个点,为什么一个事务要长时间霸占连接,并等待.
3 一些连接,只连接不清理不关闭,可能是程序设计有失误