Question

我有一个在一个小服务器上运行的vanilla postgres数据库，只有一个名为＆＃34; posts＆＃34;的表。该表大约为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)

服务器规格：
- Xeon E3-1220v2
- 4GB RAM
- 500GB硬盘（库存7200rpm，无RAID）
- postgres 9.1
- Ubuntu 12.04
- 没有L1或L2缓存
- Postgres在4个核心中的1个上运行
- Postgres配置是标准的，没什么特别的
- 我已经隔离了服务器，服务器上没有其他重要内容

当查询运行时，磁盘的读取速率为~122M / s（根据iotop）和＆＃34; IO＆gt;＆＃34; ~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。

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

postgres中的连续扫描花了很长时间。如何确定硬件瓶颈？

1 个答案: