【问题标题】:Why PostgreSQL queries are slower in the first request after server start than during the subsequent requests?为什么 PostgreSQL 查询在服务器启动后的第一个请求中比在后续请求中慢?
【发布时间】:2012-10-05 21:30:40
【问题描述】:

我正在使用 PostgreSQL 9.1.1 和 Rails 3.2.8。使用 NewRelic 的开发模式,我注意到在我的服务器启动或重启后的第一个请求期间,几个 SQL 查询所需的时间比后续请求期间要长得多。

有什么原因吗,是因为准备好的陈述吗?

【问题讨论】:

    标签: ruby-on-rails postgresql postgresql-performance


    【解决方案1】:

    您的服务器托管在什么操作系统上?在 Linux 中,文件系统使用 RAM 缓存来存储文件。当需要打开一个新文件时,如果有空间,则将其存储在缓存中。如果没有空间,则删除最旧/最后访问的文件以为新文件腾出空间。 PostgreSQL 将关系(表和索引)存储为文件。当它们第一次被读取时,Linux 文件系统将它们加载到内存中。这使得访问数据的速度更快。但是初始读取的开销是您正在经历的“缓慢”。数据的后续读取直接从 RAM 中读取 - 除非缓存交换。

    根据我的经验,您应该监控表和索引的大小。如果它们变得太大,来自这样一个“怪物表”的单个查询可能会导致所有其他常用文件交换出缓存,整个系统都会受到影响。让你的表更小(如果你在一百万行范围内尝试分区),并且不要在高度精确的字段(如时间戳)上编制索引 - 而是在日期上编制索引 - 你将拥有更少的索引节点,因此索引更小文件(假设您每天有很多记录)。这将允许操作系统更有效地将您的关系加载到缓存中和从缓存中加载出来,并且您不会注意到速度差异如此之大。

    如果您在 Windows 上托管,则可能无法解释您的性能问题。如果您需要说服您迁移到 *nix 服务器,您应该认真阅读 PostgreSQL 关于性能的文档。

    【讨论】:

      【解决方案2】:

      刚启动后,没有任何索引加载到内存中,因此服务器将不得不进行大量非常缓慢的磁盘读取。随着活动的进行,越来越多的索引页面被加载到内存中,查询这些页面当然要快得多。

      【讨论】:

      • 如果在 9.2+ 上使用 EXPLAIN (BUFFERS, ANALYZE) /* query */;,您可以看到这一点。第一次执行将有read 计划项,后续执行将有shared 非零。
      • 知道为什么长时间不活动后会出现类似的延迟吗?
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-11-11
      • 1970-01-01
      • 1970-01-01
      • 2016-09-17
      • 1970-01-01
      相关资源
      最近更新 更多