现在服务器在使用
osm2pgsql时遇到了问题导入快照...经过几次尝试，使用了不同的内存配置，但经过大部分尝试后，该过程始终输出“ Killed”（杀死）；一旦它在“遍历未决方式”时被杀死，下一次，在稍微调整了细长缓存之后，它到达了“处理方式”，然后崩溃了。根据我的阅读，这通常是由于内存问题造成的。这是我最近一次运行导入的尝试：
以下是EC2上大型实例的规格：
大型实例7.5 GB内存，4个EC2计算单元（2个虚拟内核，每个虚拟内核具有2个EC2计算单元），850 GB本地实例存储，64位平台
我的问题是-是否有一些好的基准测试资源来确定osm2pgsql和Postgres的调优要求？导入速度对我来说并不那么重要，我只是想确保过程安全完成，即使需要4到5天...我已经阅读了Frederick Ramm的“优化渲染链”（PDF）文件，来自去年的SOTM，但是还有其他好的意见/资源吗？
#1 楼
正如文档所述，您可能需要超过256gb的ram来实现。我对EC2不太了解，但是您可以尝试使用超薄（--slim）模式或尝试渗透。 br />
有一个有趣的帖子：http://weait.com/content/build-your-own-openstreetmap-server
它说，“您必须使用苗条模式”。
评论
是的，我也了解必须使用苗条模式才能应用差异进行更新。
–colemanm
2011-2-14 15:10
#2 楼
由于内存限制，我什至没有尝试使用osm2pgsql来加载planet.osm的路由数据。取而代之的是，我使用osm2po：http://osm2po.de/
大多数文档都用德语编写，但是经过一些试验，我设法使其正常工作。在专用的Core 2 Quad上花费几天时间（但它仅使用一个线程）。
#3 楼
我在寻找其他内容时遇到了以下问题http://aws.amazon.com/datasets/2844-我不确定它是否会帮助您，但这可能是一个起点。评论
即使从2009年开始，这绝对也可以立即使用。
–colemanm
2011-2-14在20:53
#4 楼
除了使用旧的预先生成的软件包以外，您是否还可以解决您的问题？我似乎在EC2实例中有非常相似的问题。我正在使用http://download.bbbike.org/osm/time ./osm2pgsql -S default.style --slim -d gis -C 7000 --hstore /mnt/planet/planet-latest.osm.pbf
osm2pgsql SVN version 0.70.5
...(creating db tables)
Reading in file: /mnt/planet/planet-latest.osm.pbf
Processing: Node(741920k) Way(0k) Relation(0)Killed
real 276m47.695s
的pbf planet更新：看来我找到了解决方法-将请求的内存减少到6后GB（参数-C 6000）的过程正常运行（至少现在已经工作了几天，希望今天能完成）。
似乎具有7.5GB内存的m1.large实例太少了，无法容纳所有节点的内存（现今大约需要11GB）。 osm2pgsql似乎需要不到700MB的额外内存，因此，使用-C 7000时，它正在运行的内存不足，但是使用-C 6000（或者也可能是-C 6500）时，它可以工作。
我也建议使用具有至少15GB RAM的更高内存实例，它应该使导入速度更快。甚至是两倍大的内存实例，这将花费一倍，但应该能够在<5小时内以非苗条模式完成完整的星球导入（比苗条模式快约3-4倍）。因此它实际上会更便宜。
评论
在EC2上这样做不是很昂贵吗？保持运行并不便宜，但临时计划是将其旋转，生成磁贴集然后将其关闭并使用该设置一段时间，直到我们需要应用更新为止。与购买大型服务器相比，它仍然便宜得多...
有趣！我从未在旧的XP-Home-Box上尝试过此操作。真的有效吗？我问这是因为它是为转换Geofabrik或Cloudmade的摘录而不是针对整个星球而编写的。这个星球似乎是无效的XML。您是如何解决这个问题的？
@Carsten在将您对评论表格的回复迁移时，我无意中删除了@jvangeld的评论。它是：嗨，卡斯滕，欢迎来到GIS.se。当开发人员来这里帮助人们开发程序时，这真是太棒了。但您在这里的答案作为对@winwaed帖子的评论可能会更好。同样，很高兴你在这里！