如何衡量网络影响PostgreSQL性能

是很常见的许多基础设施层站PostgreSQL数据库和应用服务器之间。最常见的是连接领取、负载平衡器、路由器、防火墙等。我们经常忘记或者理所当然相关网络啤酒花和额外开销它创建的整体性能。但它可能会导致严重的性能损失在很多情况下,整体吞吐量恶化。我一直试图得到一个很好的估计开销持续很长一段时间。以前我对如何写了传输的数据量作为SQL执行的一部分,以及光标位置,影响整体性能。

与此同时,Hans-Jurgen Schonig演讲长大的,旧的Unix socket和讨论TCP / IP连接,触发我写些其他方面的网络对性能的影响。他展示了一个具体案例2 x的性能下降而使用TCP / IP连接。

如何检测和测量的影响

没有简单的测量网络开销的影响机制。但是一个非常接近的分析从pg_stat_activity wait_events可以告诉我们尽可能的故事。所以我们应该抽样等事件。许多方法存在wait-event抽样,包括扩展。但是我不喜欢上安装特殊的工具或扩展的用户环境等事件取样。在Pe雷竞技下载官网rcona支持,我们使用pg_gather方法收集和研究等事件,因为它是一个独立的SQL脚本,不需要安装任何数据库系统。这是设计得非常轻量级的。将会有2000个样本收集每个会话。

pg_gather分析报告可以显示等待事件和与每个会话相关联的其他信息。

但我将讨论,强调只有等待事件的部分在这个博客,通过不同类型的工作负载和网络性能出现在等待事件。

案例1:查询检索大量的行

让我们考虑的情况下pg_dump逻辑备份在不同的机器上。如果网络速度快,我们可以看到大量的CPU利用率和“DataFileRead”等事件。

当然,有“ClientWrite”事件,等待事件相关的写数据到客户端(pg_dump)在这种情况下。如果客户机是一个轻量级的工具psql网络是非常快,“ClientWrite”甚至可能成为看不见的。

但让我们看看等待事件如果网络慢下来的样子。

我们可以看到,CPU利用率和“DataFileRead”等事件都下降,表明整个服务器端会话活动缓慢倒下。同时,“ClientWrite”上升到1821,表明会话花费大量时间发送数据到客户端(pg_dump)。也有“ClientRead”,表明pg_dump的承认是花时间。

“ClientWrite”激增并不依赖于客户端工具。下面是一个普通的截图psql会话查询检索大量的记录。

这种过度“ClientWrite”很好的发现问题在这些情况下。

案例2:批量数据加载

这是对之前的情况。但PostgreSQL有更多的工作要做批量数据的写操作。后等待事件捕获从很快/低延迟的网络。

显然,PostgreSQL过程必须花时间“WALWrite,”和“DataFileExtend, WALSync。“现在,如果网络放缓,这些等待事件我们可以看到隐身性能瓶颈的出现。

下面是等待事件从同一批量数据加载较慢的网络上。

我们可以看到,“ClientRead”已经成为主要的等待事件。这意味着服务器从客户端会话是花更多的时间阅读。

可能不是戏剧性的变化在许多系统中,但总体而言“ClientRead”更加突出。

案例3:对交易的影响

人们可能会问有什么特别事务。在OLTP工作负载,语句可以是简单的和小造成任何可观察到的网络的影响。但反复服务器和客户端之间的通信会导致语句之间不必要的延误和最后的提交或回滚。是的,我的意思是延迟/每个语句之间的差距。

以下是高速网络的等待事件并使用pgbench极大。

显然,有高WAL-related等待事件和CPU使用率。但是我们可以看到有相当大的“ClientRead”也。这是因为会有很多交易网络交互。ClientRead交易是不可避免的,它是可以预计5 - 10%。

但随着网络慢下来,“ClientRead”变得越来越重要。下面是来自相同的pgbench事务工作负载的信息较慢的网络上。

ClientRead成为最大的等待事件在这种情况下。

你可能会想,什么是"Net/Delay *”出现?这额外的分析可以在pg_gather的新版本(版本21)评估延迟以外的事务块。有关详细信息,请参阅下一个会话。

案例4:连接的利用率

随着网络延迟的增加,客户端将无法使用服务器的连接会话尽可能。上的服务器会话等八个“ClientRead”/“ClientWrite”或闲置着。无论哪种方式,它可以极大地影响系统的吞吐量。

在一个事务中,延迟捕获“ClientRead”,但两个事务之间的延迟不是捕获因为会话暂时变“空闲”。pg_gather新版本准备估计瞬时切换到空闲的服务器浪费时间或"Net/Delay *。“这可能是由于网络延迟或糟糕的应用程序响应。从数据库方面,很难区分他们。但"Net/Delay *”可以给一个好主意多少服务器时间都被浪费了。

是否有可能在应用程序服务器上安装PostgreSQL客户端工具,很容易模拟负载和研究网络延迟和应用响应延迟和与实际数据的对比。

延迟/延迟变得更可见当有很多反复在客户机和服务器之间的通信。这可以很容易地通过创建一个单独的声明文件进行测试。(取自Hans-Jurgen想法。)

这可以对TCP连接远程数据库上执行指定的秒数。

在我的服务器之间的高速网络,我可以得到下面的结果作为单一的TPS会话。

但是等待事件分析pg_gather告诉我,更多的时间是花在Net/Delay *。

是有道理的,因为“选择1”在服务器上没有太多,这工作量是发送反复沟通。

与当地Unix套接字连接,单一会话吞吐量增长了两倍多!

但是等待事件的分析告诉我们,然而,客户端和服务器之间的通信是一个主要的消费者。

这种类型的高度交互的工作负载可能受益于服务器端编程(存储过程/函数),甚至一个扩展。有趣的是,CPU使用量的比例与TPS当Unix使用套接字连接;这是一个重要的一点注意。“ClientRead”增加,因为更多的数据从客户端。

如果网络减慢在这种情况下,"Net/Delay *”也会增加,CPU使用率和TPS下降,因为会话处理两个语句之间的花更多的时间什么都不做。

因为这个特定工作负载没有交易和较少的数据发送到服务器,“ClientRead”可以下降到一个不显明的水平,正如我们看到的。

总结

从pg_stat_activity“事件”等信息可以告诉我们许多细节性能和网络拥塞。不只是事件的总和,但两个等待事件之间的差距和模式有很多信息挖下来。正确收集和分析数据讲述了从PostgreSQL的角度以及它如何体验网络。更重要的是,分析成为独立于数据库托管或操作系统工具。不需要有任何复杂的工具或框架,要达到这个要求。这样的独立的SQL脚本可以方便地发现问题和瓶颈。尽管这篇博客是特定的网络,等待事件分析可以通用的许多情况下。

雷竞技下载官网Percona分布PostgreSQL提供最好的和最关键的企业组件从开源社区在一个分布,设计和测试一起工作。

raybet52