sql - 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
  • Ubuntu 12.04
  • 无一级或二级缓存
  • Postgres 在 4 个核心之一上运行
  • Postgres 配置是标准的，没什么特别的
  • 我已经隔离了服务器，服务器上没有运行任何其他重要内容

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

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

Answer 1

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

我没有看到硬件问题的迹象。硬件得到了最大程度的利用。

51sec * 120MB/sec ~ 6GB

您说该表的大小为 5GB。可能更像是 6GB。

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