Kai Krueger kirjoitti:
Ian Dees wrote:
On subsequent updates osm2psgql does not have node information in memory
anymore, so it must request the node information from PostgreSQL. This
takes
orders of magnitudes longer to do than a hit to memory.
One possible additional problem is that
Jukka Rahkonen jukka.rahko...@latuviitta.fi wrote:
Am I right in thinking that if there were suitable diffs available it
would be much faster to update directly the osm_point, osm_line and
osm_polygon tables without going through osm_points, osm_ways and
osm_rels?
This would not work because
On 7-5-2011 18:46, Sven Geggus wrote:
Jukka Rahkonenjukka.rahko...@latuviitta.fi wrote:
Am I right in thinking that if there were suitable diffs available it
would be much faster to update directly the osm_point, osm_line and
osm_polygon tables without going through osm_points, osm_ways and
Sven Geggus kirjoitti:
Jukka Rahkonen jukka.rahko...@latuviitta.fi wrote:
Am I right in thinking that if there were suitable diffs available it
would be much faster to update directly the osm_point, osm_line and
osm_polygon tables without going through osm_points, osm_ways and
osm_rels?
Ian Dees wrote:
On subsequent updates osm2psgql does not have node information in memory
anymore, so it must request the node information from PostgreSQL. This
takes
orders of magnitudes longer to do than a hit to memory.
One possible additional problem is that osm2pqsql retrieves the
Sven Geggus li...@fuchsschwanzdomain.de wrote:
The initial import is very fast (with pbf) and still fast (with .osm.bz2).
It is just updates which are very slow here.
Hm, I just verified this. The import is fast enough (about 10 hours) but I
did expect it to be even faster.
What are the
Hi Sven,
On Thursday 28 April 2011, Sven Geggus wrote:
Disk speed can not be the Problem as I'm using a 2-Disk lvm on SSD here.
Is the data organization on the LVM comparable to a RAID-0 ?
The initial import is very fast (with pbf) and still fast (with .osm.bz2).
It is just updates which are
Markus Wagner mar...@mwagner.info wrote:
After vacuuming and fiddling with those values I am much closer to
realtime. Currently at approx ~120% of realtime. So I think, there is
hope, once I get faster disks.
I'm reopening this thread because I have a very simular Problem and I
suspect that
Hello again...
Quoting Andy Allan gravityst...@gmail.com:
How can I investigate what the bottleneck is? So far, I can see, that there
is a lot of I/O going on and not much CPU usage. The diff import is stuck
upon prompting Going over pending relations,processing relation (...).
In my
Seconded. I have my database on a RAID1 pair of 5.4K RPM drives (which
gives me a speed up in reads and data redundancy, but seems about the same
as a single disk in terms of writes) and am using PostgreSQL 9.0. Before
the fastupdate patch, one minute of diffs took between 2 and 5 minutes to
2011/4/8 NopMap ekkeh...@gmx.de:
I have gotten very good results by adding a 128 MB SSD for the db. They are
getting affordable and it resulted in a speedup x22 in raw db benchmarks and
x5 for total import time.
compared to which disks? (Which was your setup / raid before? What was
the rpm of
Seconded. I have my database on a RAID1 pair of 5.4K RPM drives (which
gives me a speed up in reads and data redundancy, but seems about the same
as a single disk in terms of writes) and am using PostgreSQL 9.0. Before
the fastupdate patch, one minute of diffs took between 2 and 5 minutes to
Markus Wagner wrote:
pointers. You think I can sufficiently improve the situation by adding
one or two more drives (and getting faster ones) to a software
RAID-0?! Or does it have to be a hardware RAID?
I have gotten very good results by adding a 128 MB SSD for the db. They are
I'v been fighting with the same problem for year now. I have a quite
powerfull server AMD 8 cores 16G ram and database on 2x10k sas disks
on raid1. Planet import takes 20hours and I still cant get the
database up to date. At the beginning it takes a lot less time to
apply diff but as the time
Hey everybody,
I hope this list suits the problem I'm trying to solve - searching the
lists, forums, former posts, etc. didn't help.
I followed (roughly) this
http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore
guide to setup a PostGIS server; did a full planet import (took 16.x
On Tue, Apr 5, 2011 at 9:58 AM, Markus Wagner mar...@mwagner.info wrote:
Hey everybody,
I hope this list suits the problem I'm trying to solve - searching the
lists, forums, former posts, etc. didn't help.
You're in the right place.
I followed (roughly) this
Hi,
Some specs of my setup:
-Debian 64Bit
-PostgreSQL 9.0.3, PostGIS 1.5.2; having its own physical drive with
XFS -Intel(R) Core(TM)2 Quad CPU Q9505 @ 2.83GHz
Make sure you've got at least osm2pgsql r25198 (31st Jan) as this will
turn the fastupdate feature off. The impact of this is most
Hi Andy,
In my experience it's all about the disks. What disks do you have,
speed of them etc? I found that 7.2k SATA disks were just about not
quite fast enough, whereas 10k SATA, SAS or SSDs seem to be fine.
As of now I only use a single SATA 2 TB drive. I am afraid, it is
running at only
One more thought:
Looking at the chart here...
http://wiki.openstreetmap.org/wiki/SotM_2010_session:Tuning_the_Mapnik_Rendering_Chain
...it suggests, that a daily diff could be processed with 8 GB RAM and
a plain disk (ok, way faster than my one) at around 1/4 to 1/3 of a day.
Besides
* Frederik Ramm frede...@remote.org [2011-04-05 11:58 +0200]:
Make sure you've got at least osm2pgsql r25198 (31st Jan) as this will
turn the fastupdate feature off. The impact of this is most
pronounced on Postgres 8.4 but seems to be present on 9.0 also.
Seconded. I have my database on a
20 matches
Mail list logo
