如何优化注浆速度？

我在通过osm2pgrouting创建的postgis数据库上使用pgrouting。它在有限的数据集上表现出色（3.5k种方式，所有最短路径A *搜索均<20 ms）。

但是，由于我从Europe.osm导入了一个更大的边界框（122k方向），因此性能下降了很多（最短路径的成本约为900ms）。

我认为使用A *不会使这些边缘中的大多数受到干扰。

到目前为止，我为提高速度所做的工作：

• 在几何列上放置索引（无明显影响）
• 我的内存从8GB增加到16GB
• 将Postgresql内存设置（shared_buffers，effective_cache_size）从（128MB，128MB）更改为（1GB，2GB）（无明显效果）

我感觉大多数工作都在制作图形的C Boost库中完成，因此优化postgresql不会给我带来更好的结果。当我对每次搜索选择的A *行集合进行细微更改时，我有点担心boost库无法缓存我的图形，并且每次都必须重建所有122k边（即使它只会使用非常每个查询的限制子集）。而且我不知道与实际最短路径搜索相比，花了多少钱。

你们中有人在122k或更高版本的OSM数据集上使用注浆吗？我应该期待什么表现？哪些设置对性能的影响最大？

当面对这样的任务时，您的主要目标是保持理性。不要基于“胆量感觉”改变参数。尽管直觉似乎对好莱坞有效，但对生活在现实世界中的我们却不起作用。好吧，至少不是我的直觉;-)。

你应该：

1. 建立可用的和可重复的度量标准（例如查询查询所需的时间）

2. 将指标结果保存在电子表格中并取平均值（最好和最差）。这将告诉您所做的更改是否朝着正确的方向发展

3. 在查询运行时使用top和vmstat监视您的服务器（假设您在* nix上），并查找重要的模式：大量io，高cpu，交换等。如果cpu在等待i / o，则尝试改善磁盘性能（这应该很容易，请参阅下文）。如果CPU的100％没有足够的磁盘实用性，则必须找到一种改进查询的方法（这可能会更难）。

为了简单起见，我假设网络在这里没有扮演任何重要的角色。

改善数据库性能

升级到最新的Postgres版本。版本9比以前的版本好得多。它是免费的，所以您没有理由不这样做。

在这里阅读我推荐的书。

您确实应该阅读它。我相信此案的相关章节是5,6,10,11

改善磁盘性能

1. 获取一个SSD驱动器，然后将整个数据库放入其中。读取性能很可能会翻两番，写入性能也应该从根本上提高

2. 为postgres分配更多的内存。理想情况下，您应该能够分配足够的内存，以便可以将整个（或最热的部分）缓存到内存中，但又不要缓存太多，以免发生交换。交换非常不好。上一段引用的书对此进行了介绍

3. 在所有磁盘上禁用atime（将noatime选项添加到fstab）

提高查询性能

使用上面引用的书中描述的工具来跟踪您的查询并查找值得优化的站点。

更新资料

注释之后，我查看了存储过程的源代码

https://github.com/pgRouting/pgrouting/blob/master/core/src/astar.c

而且似乎已经调整了查询​​后，由于该算法完全在内存中运行（不幸的是仅在一个CPU上运行），因此没有太多改进的余地。恐怕您唯一的解决方案是找到一种更好/更快的算法，或者一种可以运行多线程的算法，然后将其与postgres集成，方法是创建像pgrouting这样的库，或者使用某种中间件来检索数据（并缓存它），然后将其提供给算法。

高温超导

我也有同样的问题，正要在邮件列表中询问，所以谢谢大家！

我在路由表上使用百万行半的射击之星。计算大约需要十秒钟。对于2万行，将花费近三秒钟。我需要流星，因为我需要转弯限制。

这是我尝试实现的一些想法：

• 在pgRouting可以获取方法的SQL上，请使用st_buffer，以便它不会获取所有方法，而只是“附近”的方法：

  select * from shortest_path_shooting_star（'SELECT rout。* FROM routing rout，（select st_buffer（st_envelope（st_collect（geometry）），4）作为来自路由的几何，其中id ='|| source_ ||'或id ='|| target | |'）e WHERE rout.geometry && e.geometry'，来源，目标，true，true）；

它提高了性能，但是如果该方式需要超出缓冲区范围，它可能会返回“找不到路径”错误，所以...大缓冲区吗？几次调用增加缓冲区直到找到方法？

• 快速路线已缓存

就像dassouki建议的那样，我将缓存一些“有用的”路线，因此，如果距离太长，它可以通过这些快速路线，而只需要找到进出它们的出路即可。

• 按GIS索引划分表

但是我想，如果涉及到内存，那并不重要……无论如何都应该对其进行测试。

请继续发布，如果您发现其他想法。

另外，您是否知道Postgres9是否有一些已编译的pgRouting？

我们刚刚在git中创建了一个转弯受限最短路径的分支@ https://github.com/pgRouting/pgrouting/tree/trsp

对不起，还没有文档，但是如果您在pgRouting列表上问问题，我会在那里闲逛并会回答。该代码比流星运行速度快得多，并且基于Dijkstra算法。

-史蒂夫

我有一个包含〜1200000边的源路由表。在配备SSD的i7上，创建路由需要12秒。我提高性能的想法是将边缘表分成几个缩放级别表。我的意思是和Google Tiles一样的水平。例如，在第8缩放级别，我有88张桌子。每个表都包含道路的子集，并且它们的区域彼此重叠，以便计算彼此之间相距不超过290公里的两个点之间的路线需要2秒钟。在第9级，计算时间下降到0.25秒，我们有352张桌子。在我们编辑道路的情况下，所有图形的创建不会超过一个小时。提高路由速度的根本方法是使用Floyd-Warshall算法。但是没有人知道在那么多边缘计算前身矩阵需要多少费用。