performance - postgres 查询性能设置

Question

我有一个 web 应用程序，它在大约 33.000 行的 postgresql View 上执行搜索。如果我单独尝试这个，大约需要 1-2 秒才能得到结果，我首先想到的是没问题。但后来我从微软下载了 Web 应用程序压力测试工具，为我的 webapp 增加了一些负载。所以我首先尝试了 10 个并发“用户”。当测试运行并且我执行搜索时，它需要更长的时间，我必须等待大约 10-20 秒才能得到我的结果，我认为这是 Not Acceptable 。因为我是空洞数据库 (Postgresql) 的新手，所以我在过去 3-4 天里读了很多书，但我无法使搜索速度更快。我更改了一些配置设置，如 work_mem、shared_buffer 等，但情况并没有好转。

所以我的问题是:任何人都可以给我一些提示，我可以在我的配置或服务器上更改哪些内容以获得更好的性能，同时支持超过 10 个并发用户？

以下是有关服务器和 View 的一些详细信息:

服务器(虚拟机):

3 GHZ Xeon
3 GB Ram
40 GB Harddrive

View 的 Select 语句看起来像这样:

SELECT my selects, ....   
FROM tab1
JOIN tab2 ON tab1.index1 = tab2.index1
JOIN tab3 ON tab1.index0 = tab3.index0
JOIN tab4 ON tab1.index1 = tab4.index1;

我在每个 index1 和 index0 上设置了一个索引。

解释分析(使用默认的 postgres.conf):

EXPLAIN ANALYZE SELECT * from view_myview;

Nested Loop  (cost=0.90..29042.71 rows=49840 width=1803) (actual time=0.384..5380.477 rows=33620 loops=1)  
 ->  Merge Join  (cost=0.90..11740.81 rows=24403 width=1257) (actual time=0.263..2548.377 rows=22601 loops=1)
     Merge Cond: (tab2.index1 = tab1.index1)
     ->  Merge Join  (cost=0.00..7170.63 rows=15968 width=1251) (actual time=0.157..1225.752 rows=15968 loops=1)
           Merge Cond: (tab2.index1 = tab4.index1)
           ->  Index Scan using tab2_index1_idx on tab2 (cost=0.00..3617.45 rows=15968 width=1025) (actual time=0.053..239.399 rows=15968 loops=1)
           ->  Index Scan using tab4_index1_idx on tab4 (cost=0.00..3310.83 rows=17103 width=226) (actual time=0.045..253.721 rows=17103 loops=1)
     ->  Index Scan using tab1_index1_0_idx on tab4  (cost=0.00..4226.13 rows=24403 width=50) (actual time=0.051..347.333 rows=24403 loops=1)
->  Index Scan using tab3_index0_idx on tab3 (cost=0.00..0.64 rows=2 width=568) (actual time=0.030..0.050 rows=1 loops=22601)
     Index Cond: (tab3.index0 = tab1.index0)
Total runtime: 5814.165 ms

希望大家帮忙，

妮可

Answer 1

您实际上每次都在阅读整个 View ，根本没有任何过滤吗？如果这意味着您要在应用程序中进行过滤，那么您真的应该将它们作为 WHERE 子句下推。如果您使用的是 WHERE 子句并且只是不将其包含在此处的帖子中，那么您需要重新发布包含的内容:-)

如果您每次都阅读整篇文章，那么是的，您无能为力。正如之前评论的那样，增加您的 shared_buffers 以便一切都适合(它似乎是一个小型数据库)。

该计划确实看起来有点奇怪 - 您到底更改了哪些配置参数，更改了什么？