OSMデータのosm2pgsqlインポートの最適化

27

現在、EC2でインスタンスを構築しています。このインスタンスで、現在取り組んでいるいくつかのプロジェクトの地球全体のデータのPlanet.osmスナップショット全体をインポートします。大規模なUbuntu x64インスタンスをスピンアップし、Postgresデータベース用にEBSボリュームに多数の個別のストレージを接続し、PGSQLデータを格納するように変更しました。

現在、サーバーはosm2pgsqlスナップショットのインポートに問題があります...さまざまなメモリ構成などで2、3回試行した後、プロセスはほとんどの処理を行った後「Killed」を出力し続けます。「保留中のウェイを通過中」に削除され、次回、スリムキャッシュをわずかに調整した後、クラッシュする前に「処理中のウェイ」に到達しました。私が読んだことから、これは一般的にメモリの問題によるものです。

インポートを実行する私の最新の試みは次のとおりです。

osm2pgsql -v -U osm -s -C 4096 -S default.style -d osm /data/osm/planet-latest.osm.bz2

そして、EC2のLargeインスタンスの仕様は次のとおりです。

ラージインスタンス7.5 GBのメモリ、4つのEC2コンピューティングユニット（それぞれ2つのEC2コンピューティングユニットを備えた2つの仮想コア）、850 GBのローカルインスタンスストレージ、64ビットプラットフォーム

私の質問です-osm2pgsqlとPostgresのチューニング要件を決定するための良いベンチマークリソースはありますか？インポートの速度はそれほど重要ではありません。4〜5日かかる場合でも、プロセスが安全に完了することを確認できるようにしたいと思います。フレデリックラムの「レンダリングの最適化」を読みました。チェーン」（昨年のSOTMからの（PDF）ドキュメントですが、他にも良い意見/リソースはありますか？

— コールマン
ソース

EC2でそれを行うのは非常に高価ではないでしょうか？

— パブロ

実行し続けるのは安価ではありませんが、暫定計画では、更新を適用する必要があるまで、スピンアップし、タイルセットを生成してシャットダウンし、しばらくそのセットを使用します。巨大なサーバーを購入するよりもずっと安い

— ...-colemanm

1

面白い！古いXP-Home-Boxでこれを試したことはありません。本当に機能しますか？地球全体ではなく、GeofabrikまたはCloudmadeからの抽出物を変換するために書かれたからです。惑星は無効なXMLのようです。この問題をどのように解決しましたか？

@Carstenコメントフォームへの応答を移行する際に、@ jvangeldによるコメントを誤って削除しました。こんにちは、Carsten、GIS.seへようこそ。開発者がここに来て人々のプログラムを支援するのは素晴らしいことです。しかし、ここでのあなたの答えは、おそらく@winwaedの投稿へのコメントとしての方が良いでしょう。繰り返しますが、ここにいることは素晴らしいことです！

— whuber

8

ドキュメントが言うように、それを行うには256GB以上のRAMが必要になるかもしれません。

EC2についてはあまり知りませんが、スリム（--slim）モードまたはOsmosisを試すことができます。

興味深い投稿があります：http : //weait.com/content/build-your-own-openstreetmap-server 「スリムモードを使用する必要があります」と書かれています。

— パブロ
ソース

ええ、私はまた、更新の差分を適用するにはスリムモードが必要であることも理解しています。

— コールマン

4

メモリの制約のため、osm2pgsqlを使用してplanet.osmのルーティングデータをロードしようとさえしませんでした。代わりに、osm2poを使用しました。

http://osm2po.de/

ほとんどのドキュメントはドイツ語ですが、少し実験を重ねることでなんとか機能させることができました。専用のCore 2 Quadでは数日かかります（ただし、スレッドは1つしか使用していません）。

— winwaed
ソース

2

http://aws.amazon.com/datasets/2844を探しているときに次のことに出くわしました-それがあなたを助けるかどうかはわかりませんが、それは出発点かもしれません。

— イアン・タートン
ソース

2009年からですが、今のところ間違いなく動作する可能性があります

— ...-colemanm

2

古い事前に生成されたパッケージを使用する以外に、問題の解決策を得ましたか？EC2インスタンスでも非常によく似た問題があるようです。私はhttp://download.bbbike.org/osm/からpbf planetを使用しています

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

更新：私は解決策を見つけたようです-尋ねられたメモリを6 GB（パラメーター-C 6000）に減らした後、プロセスは動作します（少なくとも数日間は動作しましたが、今日は終了します）。

7.5GBのメモリを備えたm1.largeインスタンスは、すべてのノードをメモリに収めるには少し小さすぎるようです（今日では約11GBが必要です）。osm2pgsqlは、必要なメモリに700MB未満の余分なメモリを必要とするため、-C 7000ではメモリ不足になりますが、-C 6000（または-C 6500）でも動作します。

また、少なくとも15GBのRAMを持つより高いメモリインスタンスを使用することをお勧めします。これにより、インポートがはるかに高速になります。または、2倍のコストがかかる特大メモリインスタンスを2倍にすることもできますが、非スリムモードで惑星全体のインポートを<5時間以内に実行できるはずです（スリムモードよりも約3〜4倍高速）。だから、実際には安くなります。

— JaakL
ソース

1

私はosm2pgsqlをより少ないCPUとより多くのRAMを使用してEC2で動作するようにしました。メモリの問題が原因で、17ギガバイトのRAMを使用してインスタンスを非常に大きなメモリにアップするまで失敗しました。

— ダット
ソース