对应用程序开发人员的PostgreSQL监视：DBA基础知识

PostgreSQL中文社区 2020-12-15

1056

译者简介

李鑫&崔鹏&海能达DBA团队,任职于海能达通信股份有限公司哈尔滨平台中心,数据库开发高级工程师,致力于postgresql数据库在专网通信领域、公共安全领域的应用与推广,个人兴趣主要集中在:分布式数据库系统设计、高并发高可用数据库架构设计与开源数据库的源码研究。

校对者简介

赵全明任职于华为技术有限公司，数据库内核开发工程师，参与RDS for PostgreSQL管控及GaussDB多个版本的研发，致力于PostgreSQL在全行业的应用与推广。

我成为一名DBA非常偶然，真的是非常偶然。我首次接触PostgreSQL时是一名应用程序开发人员，这类群体都非常喜欢使用SQL编程并使用数据库来帮助解决问题。尽管如此，随着系统投入生产，我必须学习并支持好它们。

PostgreSQL监视和性能优化是一个巨大的话题。实际上，我将阅读我的同事Greg Smith在Ubuntu上对PostgreSQL 13进行基准测试时所写的内容，并提醒我，我还有很多东西要学习！公正地讲，这类文章并不少，但是我想尝试分享我从应用程序开发人员转型运维人员时总结到的一些见解。

在上一篇文章中，（https://info.crunchydata.com/blog/postgresql-monitoring-for-application-developers-the-vitals）我谈到了如何仅通过查看重要统计信息（https://info.crunchydata.com/blog/postgresql-monitoring-for-application-developers-the-vitals）（CPU，内存，磁盘和网络利用率）就可以监视Postgres系统（https://info.crunchydata.com/blog/setup-postgresql-monitoring-in-kubernetes），并在此过程中学到很多东西。这些有关资源利用的统计数据可以作为切入点：它们可以指示系统的哪个部分出现了问题，但也许并不是真正的问题所在。

这是基本DBA统计数据起作用的地方。

这些统计信息提供了有关PostgreSQL数据库活动的总体信息，可以帮助您发现性能和可用性方面的问题，并可以在“不良情况”开始发生之前提供“早期警告”。

那么，这些指标告诉您什么，以及如何使用它们成功管理PostgreSQL数据库？

对于这些示例，我们使用由pgMonitor支持的监视堆栈，该监视堆栈可与Postgres Operator一起安装。

连接统计

总连接数

PostgreSQL所需的配置参数之一是max_connections：超过该值后，客户端将无法成功地连接。这是您需要监视数据库连接数的首要原因：过多的连接可能会导致应用程序出现停机事件。

过多的连接也会影响PostgreSQL数据库的整体性能。这是Postgres中一个经过充分研究的问题，实际上，PostgreSQL 14在该领域将获得巨大的性能提升。

查看与数据库的连接总数可以帮助您优化应用程序的系统架构，并确定正确的设置以在开销可控的同时最大化吞吐量。

闲置事务

关于连接的故事还有很多，而这个故事涉及的是“闲置事务”的连接。一个连接处于事务闲置状态是指是指事务处于执行中（例如某个时候有BEGIN），但尚未提交（COMMIT）或回滚（ROLLBACK）。如果事务中有太多闲置的连接，最终可能会导致系统的整体性能问题以及潜在的维护问题。

事务中处于空闲状态的连接可能会阻止vacuum系统正常运行，如果时间足够长，这可能会导致严重的事务ID回卷问题。如果看到在事务中闲置的连接时间太久了，则应弄清楚原因并尽力消除它们。

事务率

事务速率，无论是以每秒事务（TPS）还是每分钟事务（TPM）衡量，都可以衡量系统的总体吞吐量。通常，该指标本身并不能告诉您太多：事务处理率可能会根据一天中的时间，一周中的某天等而有所不同。您可以使用事务处理率来帮助确定是否存在负载峰值或结合其它指标（例如网络吞吐量）一起确定您的性能是否受到影响。

事务处理速率可以使您对数据库系统的整体性能有一个整体的了解，但是需要与另一个度量标准结合使用，或者需要使用时间跨度比较。

行活动

行活动可以帮助识别应用负载类型，例如是繁重的读取（SELECT），繁重的写入（INSERT UPDATE/ DELETE）还是在两者之间达到平衡。了解负载类型以及其他指标，您可以调整数据库以最大程度地提高应用程序的性能。

例如，可以帮助您调整何时应该执行检查点。在检查点期间，所有“脏数据”（自上一个检查点以来已修改的数据）都将写入磁盘，这是一项昂贵的操作。了解负载类型以及事务处理率，可以帮助您正确地设置检查点。

磁盘使用情况

这很简单：如果PostgreSQL无法写入磁盘，则将导致停机。跟踪磁盘大小很重要，但是了解哪些项目占用了磁盘也很有帮助。

密切注意数据库的整体大小，因为这将显示整体数据的增长率以及何时需要采取一些措施，例如调整磁盘大小或将数据库移至另一个实例。

另外，最好跟踪磁盘上的预写日志（WAL）占用了多少。如果您使用复制插槽，当复制槽位无法收到反馈信息或者，会导致需要保留的WAL的增长。如果由于WAL日志过多而导致磁盘空间不足，则PostgreSQL实例将关闭。

（此外：PostgreSQL 13引入了有助于缓解此问题的功能：max_slot_keep_wal_size）。

跟踪整个系统使用了多少磁盘以及PostgreSQL系统的每个单独组件同样重要。

缓存命中率

我希望我在职业生涯的早期就了解缓存命中率，因为这是一个能够正确调整和调整PostgreSQL实例大小的重要指标。高速缓存命中率是内存中有多少“工作数据集”的度量。如果您请求的数据不在内存中，则PostgreSQL将不得不从磁盘中获取数据，这是一项成本更高的操作。因此，您的目标是尝试使缓存命中率尽可能接近100％。

那么，您的“工作数据集”是什么？简单来说，您的工作数据集就是您的应用程序在给定时间内访问的数据。例如，假设我有一个简单的计划应用程序，该应用程序仅查看当前或将来的约会。因此，我的工作数据集的最大大小是从今天到将来的所有计划项目。我的实际工作数据集可能更小：应用程序更可能访问距离今天更近而不是更远的约会，因此我们可以缩小窗口范围。

您如何帮助提高缓存命中率？最简单的答案是增加内存，并调整PostgreSQL shared_buffers设置。但是，更进一步的答案是“很复杂”，并且需要了解您的数据负载以优化物理资源以及PostgreSQL配置（尽管shared_buffers 在其中起着巨大的作用）。另外，重新启动后，PostgreSQL将需要一些时间才能将工作数据集加载到内存，尽管您可以使用pg_prewarm插件来抵消其中的一些负担。

监视缓存命中率可以帮助您从根本上调整PostgreSQL数据库，了解所需的硬件资源，并帮助您更好地了解自己的应用程序的访问模式。

锁

通常，当我不得不查看锁时，这是因为我的应用程序日志会突然填充两种类型的PostgreSQL错误之一：“无法获取锁”或“死锁”。然后，我将去查看系统表pg_locks，并尝试查找似乎不存在的行为。

锁是PostgreSQL的天然组成部分，它是多版本并发控制（MVCC）的基本组成部分，因此拥有锁是完全正常的。关键在于上面：确保您可以避免由于锁定而导致的错误。我会遇到的最常见的锁定错误是“无法获取锁定”，通常是因为系统此时已饱和。我通常会因糟糕的代码而触发死锁（我承认：我确实编写了一些非常复杂的链式触发器，通常会触发死锁）。

锁定问题很难诊断，更不用说解决了，因为锁定问题通常涉及多个会话，这些会话试图同时执行类似的操作。务必注意系统的整体锁定行为，以防止锁定争用引起应用程序错误。

复制滞后

我对PostgreSQL 9.0（https://www.postgresql.org/about/news/postgresql-90-final-release-available-now-1235/）的发布及其对流复制的支持感到非常兴奋！将其部署到暂存环境后，我无意间给自己上了关于复制滞后（以及WAL回收）（https://info.crunchydata.com/blog/wheres-my-replica-troubleshooting-streaming-replication-synchronization-in-postgresql）的一课。

简而言之，复制滞后是副本或数据库副本与主数据库保持最新状态所花费的时间。通常，您希望此值很小：如果存在导致主数据库不可用的情况，则希望切换到副本，并尽可能减少数据丢失。

（如果您对数据丢失很敏感，则可以考虑同步复制，尽管这也需要权衡取舍）。

副本延迟较大的原因有很多：网络饱和，副本的计算能力，复制断开且未重新连接等。拥有健康的Postgres集群的必要条件是确保副本不要延迟太大！

备份

如果我对备份只字不提，那我就是不负责的。在我给出的几乎每个演示文稿中，我都尝试着讲一个关于使用pgBackRest这样的备份管理工具对数据库进行定期备份的重要性。如果您的系统在订阅期内未成功完成备份，则一定要修复该问题。备份不仅在发生灾难时至关重要，还可以方便地恢复新的集群出来。

无论如何，如果您在生产中运行任何东西，请备份该系统。

结论

您可以使用许多不同的监视指标来帮助确保PostgreSQL系统保持健康。对我来说，我倾向于先从查看系统的CPU，内存，磁盘和网络利用率，（https://info.crunchydata.com/blog/postgresql-monitoring-application-developers-os-stats）然后再开始进行进一步的故障排除。当我参加了更多的Postgres活动后，并且了解到人们在系统和数据库管理方面比我更有经验的时候，我扩展了工具包，以跟踪和分析上面讨论过的许多指标。

如果你在Kubernetes上运行PostgreSQL，或者考虑过这件事，我鼓励你在你的环境上安装Postgres监控,尝试看下，在故障诊断中，可以开发那些模式。

这篇文章是以下系列文章的部分：

l How to Setup PostgreSQL Monitoring in Kubernetes

l PostgreSQL Monitoring for Application Developers: The Vitals

l PostgreSQL Monitoring for Application Developers: The DBA Fundamentals

l PostgreSQL Monitoring for Application Developers: Alerts & Troubleshooting

请点击文章底部“阅读原文”查看原文

postgresql

文章转载自PostgreSQL中文社区，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。