The Open Street Map project provides invaluable data that keeps driving users toward the PostGIS and PostgreSQL stacks. Loading today’s full Planet data set takes a 120GB XML file and unrolls it into over a terabyte of database data. Crunchy’s benchmark labs have followed the expansion of that Planet data over the last six database releases, as the re-ignition of the CPU wars combined with parallel execution features landing in the database. We’ll take a look at that data evolution, which server configurations worked, and which metrics techniques still matter in the all SSD era.
2. The Open Street Map and osm2pgsql Loader
● The Open Street Map project provides invaluable data that keeps
driving users toward the PostGIS and PostgreSQL stacks.
● Baseline Planet data set loader option osm2pgsql unrolls a 120GB
XML file (or 70GB PBM one) into up to a terabyte database.
3. Crunchy Benchmarking Labs
● Crunchy runs a set of benchmark labs focused on various
PostgreSQL community goals.
● I run a “Farm” focused on storage and regression testing, mainly with
comparisons of bare metal Linux and Mac laptops. Hardware visible
at https://browser.geekbench.com/user/232126
● Code published to pgbench-tools. Results and PG metrics written to
database. Graphs via various Python data analysis tools.
● PG15 testing : osm2pgsql is an alternate backend to pgbench.
5. osm2pgsql loading stages
Processing
Node(6959649k 663.5k/s)
Way(772748k 29.16k/s)
Relation(8931370 862.18/s)
● Derived or intermediate tables: COPY, CREATE TABLE AS, CREATE INDEX
(B-Tree).
● CREATE INDEX (PostGIS).
● Parallel index builds have greatly reduced the CPU bound periods.
● On SSD, single core performance predicts performance for over half
the runtime.
○ Intel’s Xeon line has long held the lead there.
12. Well known osm2pgsql tuning
https://osm2pgsql.org/doc/manual.html
https://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks
● Use PBM input, shrinking download to 70GB.
● Use temporary flat file for Nodes
○ Currently 70GB and growing. Can leave on root SSD disk.
● Increase dedicated node cache memory in favor of almost
everything else.
13. Use PBM files instead of OSM [xml+bzip]
● Protocol buffer Binary Format vastly better.
● 7700X CPU adds AVX512 memory transfers.
○ Up to 74% better on simple memory-bound single core SELECT tests!!
CPU Memory k/s Secs Hours PBM k/s Minutes
3950X 128GB 474 16637 4.6 9759 14
5950X 128GB 682 11549 3.2 12468 11
7700X 64GB 784 10053 2.8 17077 8
14. osm2pgsql Memory Budgeting: 128GB RAM
Phase Dynamic memory Static memory
Nodes Node Cache: Up to 50GB Shared Buffers
Ways Same Up to 48GB
Relations Same
CTAS Work Mem: 1GB plenty
CREATE INDEX Maintenance Work Mem:
Up to 20GB
18. Controversial adjustments
autovacuum = off
full_page_writes = off
● My results turn autovacuum off for a 4% gain
○ Standard trade-off for bulk loading
○ Not all hosting platforms allow this?
○ Workaround is to starve it of as many resources as you can
● Full page writes are a platform specific storage optimization
○ Most likely outcome 1% gain
○ Shouldn’t advise regular users to ever tinker with this one
19. Advanced tuning: Background Writer
Tuned for heavy writes:
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 500
bgwriter_lru_multiplier = 4.0
Or just disable:
bgwriter_lru_maxpages = 0
checkpoint_flush_after=0 [new parameter]
22. Linux tuning
$ sudo blockdev --setra 4096 /dev/nvme2n1
$ sudo cpupower frequency-set --governor=performance
● Boot PCI3.0 SSD plus single PCI4.0 NVMe SSD for tests, no RAID.
● Using ext4 filesystem
○ COW filesystems might safely disable full_page_writes
● Setup Linux swap.
○ For single server installs, osm2pgsql memory peaks can wipe out the
database server.
○ 32GB used here for full Planet.
● Huge pages can be useful too. Hard to measure with single workload.
