孤独酒馆|一个能融会贯通PostgreSQL监控的人，大概率是高手( 三 )
1、会占据大量的数据库存储的空间
2、会影响对此表的数据查询性能
所以表膨胀一直是对POSTGRESQL 的监控中的一个要点
在执行完脚本后,我们就可以观察到bloat的比率 和膨胀占用的空间, 如果我们的可以将这些数据,例如将一些关键表的数据进行历史留存,并且使用一些通过一些前端程序展示某些曲线, 就很容易发现潜在的问题,
例如经常有大型的SQL 占用某些核心表, 导致无法进行有效的 dead tuple 回收,造成某个表的 waste 空间一涨再涨
例如我们可以扩展CREATE EXTENSION pgstattuple; 对 dead_tuple_count /tuple_count*100 来看一下当前POSTGRESQL的 dead_typle_count的一个百分比, 也可以对这些关键的表设定一些警告,当超过多少百分比后
我们就进行相关的报警或触发一些操作.
与其他的数据库比较, POSTGRESQL 在buffer利用上的统计和展示是比较明确的,也是比较方便的, 上面的脚本我们使用POSTGRESQL的扩展 pg_buffercache , 通过这个插件配合系统表,我们可以实时的查看postgresql在buffer hit 方面的状态, buffer hit 大致的意思就是在数据处理时 ， 数据库中的处理的数据在内存中是否都能被命中, 如果这个命中比较低的情况下,说明我们的内存短缺,或者我们有一些系统的实际SQL不合理的.就需要我们更深层次的分析了.
同时通过延伸, 对整体的buffer_percent进行一个累计,后就可以得到我们的内存和数据之间的BUFFER HIT 的比率 。
3、通过系统获得监控数据:
通过postgresql的命令pg_isready来判断是否可以和POSTGRESQL数据库进行连接,并通过返回的数字来判断释放可以连接 还是不可以连接 0 可以连接 1 拒绝连接2 无响应
大家可以注意到,与系统的状态, 简单的信息的获取可以通过 系统的命令 + 简单的过滤 就可以了而详细需要分析的以及历史数据分析等等 大多是要通过其他的方式来进行
图中是通过PSQL 命令执行简单的SQL 语句获得当前PG的连接占总的运行连接的比率, 所以大多数简单的信息大部分都是要提供给图形化或监控报警的.
监控误区误区1、人家监控哪里我就监控哪里 。 例如某保险公司的监控参数, 我直接拿来, 可能部分常规的监控参数是可以通用的,但与特性有关的监控指标照搬就有点多此一举了 。 业务量及业务内容 ， 业务需求都不同 ， 照搬来的监控 ， 有些内容即耗费你的系统的性能,来提取无用的性能点, 又耗费你的精力,导致后期监控疲劳.
误区2、监控的内容要全 。 一个数据库监控的指标可能有上百,甚至上千个 。 都要监控,毫无重点,最终出了事情,不知道哪个监控点应该被响应.
推荐阅读
- 央视财经|这家知名连锁店掀“关店潮”！有人退钱等了一个月
- 武磊|下一个武磊？恒大新星留洋加盟西乙劲旅，18岁夺金靴，把梅西当偶像
- 钱江晚报·小时新闻|浙江街头揪心一幕！电瓶车上3岁男孩一个动作，他和妈妈瞬间飞出……
- 赵立坚|赵立坚：美国以莫须有借口抓捕中国企业高管 连一个弱女子都不放过
- 浙江法法制报|“大男人喝酒，叫一个女的去买单？”因为这句话，他逃了足足10年
- 美食工坊|而有一个很唯美的名字，日本仍保留使用，古代的苹果不叫“苹果”
- 国际今日事|称“感觉好像中彩票”，美国男子在自家后花园发现一个大型游泳池
- 水稻|从“80后”变“90后” ，今天袁隆平许下一个生日愿望
- 穿搭|4款时尚上衣，好看又百搭，让你时髦一个秋天
- 孙冾讲娱乐|女汉子本性暴露无遗！，搞笑GIF：最后这一个动作