postgres 中的顺序扫描花费的时间令人惊讶。如何确定硬件瓶颈？

Question

我有一个普通的 postgres 数据库在一台小型服务器上运行，只有一个名为“posts”的表。该表大小约为 5GB，包含 900 万行。

当我运行一个简单的顺序扫描操作时，大约需要51 秒！:

EXPLAIN ANALYZE select count(*) from posts;
                                                    QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=988701.41..988701.42 rows=1 width=0) (actual time=51429.607..51429.607 rows=1 loops=1)
   ->  Seq Scan on posts  (cost=0.00..966425.33 rows=8910433 width=0) (actual time=0.004..49530.025 rows=9333639 loops=1)
 Total runtime: 51429.639 ms
(3 rows)

• 服务器规格：
  • 至强 E3-1220v2
  • 4GB内存
  • 500GB 硬盘（原厂 7200rpm，无 RAID）
  • postgres 9.1
  • 乌班图12.04
  • 无 L1 或 L2 缓存
  • Postgres 在 4 个核心之一上运行
  • Postgres 配置是标准的，没什么特别的
  • 我已经隔离了服务器，并且服务器上没有运行任何其他重要的内容

当查询运行时，磁盘读取速度约为 122M/s（根据 iotop），“IO>”约为 90%。只有 1 个核心的使用率为其容量的 12%。看起来此操作中几乎没有使用内存，可能约为 5MB。

从这些统计数据来看，瓶颈似乎是 IO，但我很困惑，因为磁盘的读取速度更快，（根据我使用的速度测试，sudo hdparm -Tt /dev/sda我得到了大约 10,000M/s），但同时iotop显示90% 的值我还没有完全理解。

Answer 1

你的磁盘肯定不会以 10GB/秒的速度读取:) 这是缓存的性能。这里的硬件已经达到极限了。120MB/秒是典型的顺序速率。

我没有看到任何硬件问题的迹象。硬件得到了最有效的利用。

51sec * 120MB/sec ~ 6GB

你说表的大小是5GB。可能更像是6GB。

这些数字是有道理的。这里没问题。