邢台wap网站建设报价,广安发展建设集团官方网站,罗湖附近公司做网站建设哪家好,php开发网站建设PgSQL-使用技巧-如何衡量网络对性能的影响 PG数据库和应用之间常见的部件有连接池、负载平衡组件、路由、防火墙等。我们常常不在意或者认为涉及的网络hops对整体性能产生的额外开销是理所当然的。但在很多情况下#xff0c;它可能会导致严重的性能损失和拖累整体吞吐量。相当… PgSQL-使用技巧-如何衡量网络对性能的影响 PG数据库和应用之间常见的部件有连接池、负载平衡组件、路由、防火墙等。我们常常不在意或者认为涉及的网络hops对整体性能产生的额外开销是理所当然的。但在很多情况下它可能会导致严重的性能损失和拖累整体吞吐量。相当长一段时间我试图对这种开销进行良好的评估之前写过how the volume of data transmission as part of SQL execution, as well as the cursor location, affects the overall performance: https://www.percona.com/blog/impact-of-network-and-cursor-on-query-performance-of-postgresql/ 如何检测和衡量影响 没有简单的机制用来衡量网络开销的影响。但是对pg_stat_activity中的wait_events可以尽可能多的告诉我们相关信息。所以我们应该对等待世界进行采样。我们使用pg_gather作为收集和分析等待事件。他是一个独立的SQL脚本无需在数据库系统上安装任何东西。他的设计也很轻巧每隔会话可以采集2000个样本。该项目地址 https://github.com/jobinau/pg_gather 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批量数据加载 与前面的情况相反。但PG批量些操作需要做大量工作。下面的等待事件是从真实的fast/low延迟网络采集的 显然PG进程必须在“DataFileExtend”、“WALWrite”和“WALSync”上花费事件。现在如果网络速度变慢随着性能瓶颈的出现我们看到的许多等待事件可能看不见。 以下是较慢网络下加载批量数据的等待事件 正如所见“ClientRead”已成为主要的等待事件。意味着服务器会话花费更多事件从客户端读取数据。许多系统中这种变化可能并不明显但总体而言“ClientRead”变得更加突出。 案例3对事务的影响 OLTP负载上SQL可能简单且短小不会造成任何可观察到的网络影响。但服务器和客户端之间的来回通信可能会导致SQL和最终提交或回滚之间出现不必要的延迟。即每隔语句之间的间隙。 下面是快速网络下pgbench的微事务的等待事件 显然与 WAL 相关的等待事件和 CPU 使用率很高。但我们可以看到也有相当多的“ClientRead”。发生这种情况是因为微事务会有大量的网络交互。ClientRead 对于事务来说是不可避免的预计 5-10% 就可以了。 但随着网络速度变慢“ClientRead”变得越来越重要。以下是来自较慢网络上相同 pgbench 事务工作负载的信息。 在这种情况下ClientRead 成为最大的等待事件。 您可能想知道“Net/Delay*”显示的是什么新版本的 pg_gather版本 21中提供了此附加分析用于评估事务块外的延迟。详情请参阅下一节。 案例4连接利用率 随着网络延迟的增加客户端连接将无法尽可能使用服务器会话。服务器会话必须等待第八个“ClientRead”/“ClientWrite”或闲置。无论哪种方式它都会极大地影响系统的吞吐量。 在事务内延迟被捕获为“ClientRead”但不会捕获两个事务之间的延迟因为会话暂时变为“空闲”。pg_gather 新版本准备了对服务器浪费时间或“网络/延迟*”时短暂切换到空闲的估计。这可能是由于网络延迟或应用程序响应不佳造成的。从数据库方面来说很难区分它们。但“网络/延迟*”可以很好地了解浪费了多少服务器时间。 当客户端和服务器之间存在大量来回通信时延迟/等待时间变得更加明显。通过创建单个语句文件可以轻松测试这一点。 echo SELECT 1 query.sql 这可以通过 TCP 连接针对远程数据库执行指定的秒数。 $ pgbench -h 10.197.42.1 -T 20 -f query.sql 在我的服务器之间的快速网络上我可以获得以下结果作为单个会话的 TPS。 …
latency average 0.030 ms
initial connection time 5.882 ms
tps 32882.734311 (without initial connection time) 但 pg_gather 的等待事件分析告诉我更多的时间花在了 Net/Delay* 上。 这是有道理的因为“SELECT 1”在服务器上不需要做太多事情而且这个工作负载都是关于发送来回通信。 使用本地Unix套接字连接单个会话吞吐量增加了一倍以上 latency average 0.013 ms
initial connection time 1.498 ms
tps 75972.733205 (without initial connection time) 但等待事件分析告诉我们客户端-服务器通信仍然是主要的时间消耗者。 “ClientRead”增加是因为从客户端传输了更多数据。 如果在这种情况下网络速度变慢“Net/Delay*”也会增加并且 CPU 使用率和 TPS 会下降因为会话在处理两个语句之间花费更多时间不执行任何操作。 由于这个特定的工作负载没有事务并且发送到服务器的数据较少因此“ClientRead”可能会下降到不明显的水平正如我们所看到的。 总结 来自 pg_stat_activity 的“wait events”信息可以告诉我们有关性能和网络拥塞的许多详细信息。不仅仅是事件的总和两个等待事件和模式之间的差距也有很多信息需要挖掘。pg_gather独立 SQL 脚本可以方便地发现问题和瓶颈。尽管这篇博文专门针对网络但等待事件分析对于许多情况都是通用的。 原文 https://www.percona.com/blog/how-to-measure-the-network-impact-on-postgresql-performance/
