实际上使用过 solarwinds，大概在10年前,solarwinds 是美国的一家专门从事IT 产品监控的工作，产品是付费的，一般国内的企业很少使用，主要还是费用比较贵。本次是偶然看到SW 公司的 TKC 系列介绍今年SW针对 POSTGRESQL 的 DPA ，database performance administrator 系列。在针对这个meeting 的详述开始前，对于数据库的监控也就是最近要开始做的那个系统，是有设想的，尤其针对数据库的性能监控方面。
性能监控大部分人想到的
1 针对数据库的慢查询的监控
2 针对数据库的使用的CPU, MEMORY, BUFFER HIT, I/O IOPS 等的监控
3 将这些动态的进行展示
但从深层次的角度，这些是解决问题时出现的解决方案，而不是预防问题的解决方案，也就是我们通常说的前摄性。如何通过监控来发现更深层次的问题，并且通过监控系统进行分析，可以是数据库监控系统下一个方向。
——————————————————————————————
正文：下面是 SW 的 solution Architect
Ash 是来自SW 的 database software Architect .
基于对于数据库系统的问题发现，SQL语句的性能执行问题一直是一个关注点，针对这个问题我们可以从多个角度去分析，如我们的语句在等待什么，如SQL 语句的执行中在等待锁，在等待I/O系统是否准备好，我们将关注点聚焦在我们是否有一个好的有效的路径来去移除这些系统中的瓶颈，来去确认我们能为最终用户来提供一个高质量的系统。
DPA 系统主要针对的是从ORACLE ，SQL SERVER ,等客户迁移到POSTGRESQL 的情况，尤其现在大量的公司考虑到成本的因素，从ORACLE ，SQL SERVER 迁移到POSTGRESQL 情况较多，但同时公司内部并没有专业的POSTGRESQL 的管理人员，所以DPA 系统主要的工作有以下几点
1 通过等待时间去定义系统的瓶颈并且尝试有针对性的去通过调整配置来提供系统的性能
2 根据这些变化来持续跟踪性能获得调整参数后系统是否由此性能变好，或变得更糟
3 定义那些是糟糕的SQL
4 历史性分析和监控功能
通过DPA 来综合性分析，可以找出某一个SQL 在某一个时刻运行的次数，以及这些语句占这一个时刻总体的SQL 的等待时间比，从图中可以看到，我们在调整参数后，整体的性能变化比较大，JAN 11 中UPDATE 语句的变化与 FEB 2 号的语句的性能相差的很多。同时比对数据库非逻辑方面的等待，如I/O 读的等待，等待，这样看上去更明确SQL 与 底层系统性能之间的在哪一个时刻的关系。
同时我们还针对这样的情况给出了相关解决的方案和由谁应该去解决，这样针对一些没有这方面管理知识的客户有很大的帮助和指导。
甚至我们在系统上整合了一个在任意时间线上，问题发生的情况解释，以及你应该去让谁做什么的一个"白话解释"。如上面图中的我们在分析问题后，自动提醒建议客户的开发团队应该去看看如何在应用程序中降低锁的发生，我们管这个很COOL 的功能叫 PG TUNE .
这样不光我们解决了客户的问题，同时我们提供了让客户学习更多的POSTGRESQL 的知识的一个路径。
再如，我们根据分析，我们可以给客户更深层次的和专业的建议，而不是战士某些空洞的曲线和参数。通过这样方式给客户更好的前瞻性。
如我们图例中，性能在 1月15日为什么相对1月13日性能更差了，这里我们给出的建议，数据库系统不能满足活跃的数据装载到系统里面所以我们根据数据的分析针对客户的情况给出了关于内存方面的建议。
在如我们的storage admin模块发现客户的 wal 日志频繁并且checkpoints会引起磁盘的方面的性能问题。
同时经过后期的数据跟踪，我们在2：00给出了，调整max_wal_size参数的意见。
甚至我们根据数据，在后面给出了用户使用 pgbouncer 来增加系统针对连接数过多的建议。
除此之外，我们还可以根据这些数据，给出每天客户的数据库重要的性能问题的TOP 注释，其中DAP 系统是可以感知客户的系统越来越糟糕，那些表什么时间加进来的，同时
对于一些客户没有解决的问题，我们还有提醒的功能，如我们可以提醒客户某些问题已经提醒过，针对某些历史表的问题。
DPA 系统也会记录系统中的负载，并记录和展示出来。
根据这些信息，可以让客户的系统运行的更稳定，并且客户知道他的系统发生了什么需要调整了什么，甚至我们可以在这个系统中给客户进行排课系统，让客户了解到底发生了什么，或者我们可以回顾什么。
同时这也是一个系统能过良好运行的关键，持续对系统进行性能方面的优化。
感谢那些关注的guys , 希望每个人都能时刻关注自己系统的性能并且成功的持续性的交付一个好的服务。
