我正在尝试测量同一 Postgres 服务器上的各种数据库所产生的负载，以确定如何最好地将它们拆分到多个服务器上。我设计了这个查询：
select
now() as now,
datname as database,
usename as user,
count(*) as processes
from pg_stat_activity
where state = 'active'
and waiting = 'f'
and query not like '%from pg_stat_activity%'
group by
datname,
usename;
但活动进程却出人意料地少！
据我运行查询的客户称，深入挖掘后，我运行了一个简单的查询，该查询返回 20k 行，花了 5 秒才完成。当我询问时pg_stat_activity在那段时间里，过程是idle！我重复了这个实验几次。
Postgres 文档说active means
后端正在执行查询。
and idle means
后端正在等待新的客户端命令。
它真的比这更微妙吗？为什么运行我的查询的进程没有active我什么时候登记入住的？
如果这种方法有缺陷，那么除了定期采样活动进程的数量之外，还有哪些替代方法可以在数据库粒度上测量负载？
您的期望active, idleand idle in transaction非常正确。我能想到的唯一解释是客户端显示数据的巨大延迟。所以查询确实在服务器上完成并且会话是idle但你没有看到客户的结果。
关于负载测量 - 我不会太依赖活动会话的数量。纯粹是运气好才能在活动状态下进行快速查询。例如，假设你可以检查pg_stat_activity每秒都会看到一个活动会话，但在测量之间，一个数据库被查询 10 次，另一个数据库被查询一次 - 但这些数字都不会被看到。因为他们在处决之间很活跃。而这个 10+1 活动状态（尽管意味着一个数据库被查询的频率增加了 10 倍）并不意味着您根本应该考虑加载 - 因为集群太多未加载，您甚至无法捕获执行。但这不可避免地意味着您可以捕获许多活动会话，但这并不意味着服务器确实已加载。
所以至少采取now()-query_start到您的查询以捕获更长的查询。或者甚至更好地节省一些经常查询的执行时间并测量它是否随着时间的推移而退化。或者更好的选择pid并检查该 pid 占用的资源。
顺便说一句，对于较长的查询，请查看 pg_stat_statements - 查看它们如何随时间变化可以给您一些关于负载如何变化的期望
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
