首先就要祭出原理, 到底连接分配的内存要从哪里来分配,大部分人包括我,认为,导致PG无法接受大量连接的主要原因,其实是内存....但实际上我们做一个测试,我对一个使用8G内存的PG ,加载3000个并发连接并且查询同一个表,并且同时将 shared_buffers 调整成20MB ,然后我就等待着PG崩溃.
?
?
?...实际上我并没有如愿, PG 还是稳稳的运行, 但系统有一点缓慢,有点卡的感觉
内存方面也并没有与我预期的会彻底的用光契合.
?...而为了获取这些信息的变化对share_buffer 和 backend 的临时数据进行获取,他会遍历到其他的process, 而如果我们建立的backend越多, 也就是连接到PG的连接越多, 就会导致遍历获取数据...那既然知道了PG在处理超多的连接上会有性能的问题,那如何解决这个问题对大多数使用的人就有相关的意义,可以带着这个问题来问几个问题
1 为什么要有并发那么多连接, 例如一个数据库要承受3000+以上的连接数