Otimizando as importações do osm2pgsql para dados do OSM

27

Atualmente, estou criando uma instância no EC2 na qual importar todo o instantâneo Planet.osm de todo o valor de dados da Terra para alguns projetos em que estamos trabalhando. Criei uma instância grande do Ubuntu x64 e anexei bastante armazenamento separado em um volume EBS para o banco de dados Postgres e modifiquei-o para abrigar os dados PGSQL lá.

Agora, o servidor está tendo problemas osm2pgsqlpara importar o instantâneo ... Após algumas tentativas com diferentes configurações de memória e outros enfeites, o processo continua emitindo "Killed" depois de passar a maior parte do caminho; depois que foi morto enquanto "passava por caminhos pendentes" e na próxima vez, após ajustar levemente o cache fino, alcançou "caminhos de processamento" antes de travar. Pelo que li, isso geralmente ocorre devido a problemas de memória.

Aqui está minha última tentativa de executar a importação:

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

E aqui estão as especificações para uma instância Large no EC2:

Instância grande 7,5 GB de memória, 4 unidades de computação EC2 (2 núcleos virtuais com 2 unidades de computação EC2 cada), 850 GB de armazenamento de instância local, plataforma de 64 bits

Minha pergunta é - existem alguns bons recursos de benchmark para determinar os requisitos de ajuste para osm2pgsql e Postgres? A velocidade da importação não é tão importante para mim, eu gostaria de garantir que o processo seja concluído com segurança, mesmo que demore 4 ou 5 dias ... Eu li " Otimizando a renderização " de Frederick Ramm documento em cadeia "(PDF) do SOTM do ano passado, mas existem outras boas opiniões / recursos?

— colemanm
fonte

Não seria muito caro fazer isso no EC2?

— Pablo

Não é barato mantê-lo em execução, mas o plano provisório é girá-lo, gerar um conjunto de peças, depois desligá-lo e usá-lo por um tempo até que precisamos aplicar as atualizações. Ainda é muito mais barato do que comprar um servidor maciço ...

— colemanm

1

Interessante! Eu nunca tentei isso no meu antigo XP-Home-Box. Isso realmente funciona? Estou perguntando porque foi escrito para converter trechos de Geofabrik ou Cloudmade não para o planeta inteiro. O planeta parece ser XML inválido. Como você resolveu esse problema?

@Carsten Ao migrar sua resposta para um formulário de comentário, excluí inadvertidamente um comentário de @jvangeld. Aqui está: Oi Carsten, bem-vindo ao GIS.se. É incrível quando os desenvolvedores vêm aqui para ajudar as pessoas com seus programas. Mas sua resposta aqui provavelmente teria sido melhor como um comentário ao post de @ winwaed. Novamente, é ótimo tê-lo aqui!

— whuber

8

Como a documentação diz, você pode precisar de mais de 256 GB de RAM para fazer isso.

Não sei muito sobre o EC2, mas você pode experimentar o modo slim (--slim) ou osmose .

Há um post interessante: http://weait.com/content/build-your-own-openstreetmap-server Ele diz: 'você deve usar o modo slim'.

— Pablo
fonte

Sim, também entendo que o modo slim é necessário para aplicar diffs a atualizações.

— colemanm

4

Devido às restrições de memória, nem tentei usar o osm2pgsql para carregar os dados de roteamento do planet.osm. Em vez disso, usei o osm2po:

http://osm2po.de/

A maior parte da documentação está em alemão, mas com um pouco de experimentação, consegui fazê-la funcionar. Demora alguns dias em um Core 2 Quad dedicado (mas ele está usando apenas um thread).

— winwaed
fonte

2

Me deparei com o seguinte, procurando por outra coisa http://aws.amazon.com/datasets/2844 - Não tenho certeza se isso irá ajudá-lo ou não, mas pode ser um ponto de partida.

— Ian Turton
fonte

Esse trabalho poderia certamente por agora, mesmo que seja a partir de 2009 ...

— colemanm

2

Você conseguiu uma solução para o seu problema, além de usar o pacote pré-gerado antigo? Parece que tenho um problema muito semelhante na instância do EC2. Estou usando o pbf planet em 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

Atualização: parece que encontrei solução - depois de reduzir a memória solicitada para 6 GB (parâmetro -C 6000), o processo funciona (pelo menos já funciona há vários dias, terminará hoje, espero).

Parece que a instância m1.large com 7,5 GB de memória é um pouco pequena para caber todos os nós na memória (o que deve exigir cerca de 11 GB atualmente). O osm2pgsql parece exigir menos de 700 MB a mais de memória necessária, portanto, com o -C 7000, ele está com pouca memória, mas com o -C 6000 (ou possivelmente também -C 6500) funciona.

Além disso, eu sugiro usar uma instância de memória superior com pelo menos 15 GB de RAM, isso deve tornar a importação muito mais rápida. Ou até o dobro da instância de memória extra grande, que custaria o dobro, mas deve poder importar o planeta inteiro no modo não fino dentro de <5 horas (cerca de 3-4 vezes mais rápido que o modo fino). Portanto, seria realmente mais barato.

— JaakL
fonte

1

Eu tenho o osm2pgsql para trabalhar no EC2 usando menos CPU e mais RAM. Ele falhou devido a problemas de memória até eu elevar a instância para uma memória extra grande com 17 GB de RAM.

— datdo
fonte