理解堆读/堆命中

Question

我有一个dockerized数据库(主机有1GB的ram和2个CPU)，在特定的表上有一些表，用于连续读写数据(每5秒一次)，我有一些奇怪的问题，如您所见，heap_read和heap_hit的比率很低：

该表，没有那么多数据，只有300 K行，并且表的结构如下：

这是指数统计数据：

我的意思是，这个系统似乎起作用了，我需要知道我是否需要做一些具体的调整，以使它更好地工作，并使堆_ fine...but /堆_命中率接近于0.99？

谢谢

Answer 1

您正在处理它，就好像块读取是块命中的子集。这是不对的，两者是相互排斥的。要获得真正的命中率，您必须计算为sum(hits)/sum(hits+reads)。但是，不管怎么说，只看命中率是非常无用的，但在PostgreSQL中尤其如此，因为它不使用DirectIO，而是位于操作系统的文件缓存之上。命中率是神话管理的一部分。

据我们所知，该表只对其进行了一两次seq扫描(例如，为创建索引而做的扫描)，而该事件现在正在控制您的统计数据。您可以重置统计数据(或者更好地停止查看它们)，以消除一次性事件。

当已知存在问题时，列seq_scan、seq_tup_read、idx_scan、idx_tup_fetch偶尔(但很少)有助于找出问题的来源。当一开始没有问题要诊断的时候，它们是完全无用的。

相反，您应该花时间做一些有用的事情，比如设置一个缓慢的查询日志("log_min_duration_statement“或者更好的是自动_解释和pg_状态_语句)，设置测试/dev/QA环境，或者运行灾难恢复演练，以便您知道备份正在工作，并且知道如何使用它们。

对于新项目，我最喜欢的auto_explain设置是：

shared_preload_libraries = 'auto_explain'
track_io_timing=on
auto_explain.log_min_duration = '50ms'
auto_explain.log_analyze=on
auto_explain.log_timing=off
auto_explain.log_buffers=on

如果发现log_min_duration捕获的查询太多，则增加它。

拥有log_analyze=on，同时拥有log_timing=on，对所有查询都会带来相当高的开销；因此，设置log_timing=off是一个折衷方案，可以获得尽可能多的细节，但开销最小。