开发者社区> 问答> 正文

关于postgresql在实际场景下所碰到的问题

jaywu 2016-12-02 21:06:59 1322

大家好,我想咨询下两个关于postgresql使用的问题,也是我们在实际生产上所遇到的问题

先描述下我们的配置:

1. Postgresql 9.2, 标准版本,未改变编译参数

2. 一台主库,两台从库(Stream Replication)(其中一个通过级联复制挂又挂了一个从库)

3. 主数据库搭在一台vm上 系统为Solaris ,ssd(读写近1G),CPU 32; 内存 : 64G

4. 数据库大小 : 300G

5. 主表 :3000万行 X 200+字段;每月以400万数据增长;

6. 一些子表会达到1亿条以上,但是大部分的读写都发生在主表上;

7. 有一些重查询发生在主库上

8. 主表上有将近30多个btree索引,两个gin index(双字段组合索引,平均一个gin在12g左右)

9. shared_buffer = 7G

我们现在所碰到的问题:

1. 经常发现连接数激增,现在通过限制连接数来降低数据库负载。大概想知道,连接数应该限制在一个什么样的范围内比较合理。当然这个和业务场景,还有SQL的效率有关系。现在设置的是数据库端512 max connection,没有用pgBouncer Pooling,但是程序端(集群)用了dbcp做连接池,连接配置加在一起大概是基本上在maxActive 600 maxIdle 400左右。经常会发现数据库端有300个active连接就快不行了。有一次甚至挂掉,无响应。请问这个正常吗?连接数,大概要配在多少?

2. 在以上描述的规模,我们现阶段是不是要考虑分库了?之前还有很多事情能做,读写分离,程序优化,搜索引擎等等,但是总感觉再不做拆库就来不及了。请问大概数据量在多少要考虑拆库了?

SQL 固态存储 搜索推荐 关系型数据库 Unix 数据库 PostgreSQL 索引
分享到
取消 提交回答
全部回答(1)
  • 德哥
    2019-07-17 20:30:59

    连接数激增和业务请求有关,比如响应变慢后,可能需要通过新增连接来满足程序的请求。如果业务上没有出现异常,业务量也没有明显的增长,建议你需要关注的是数据库的优化,查一下当时的数据库的等待事件,系统的状况等。
    分库也一样,先摸清楚原因。可以先升级硬件,比如很多数据库的瓶颈都在IO层面,先升级到SSD,可以解决大部分问题,当然还有部分是SQL没有优化好导致的,如果真的是一台库解决不了你的问题,分库是很好的方法。

    0 0
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题
推荐课程