I have recently read [this
article](https://thebuild.com/blog/2026/04/24/huge-pages-end-to-end/) about
Huge Pages on Linux, why they can make sense when running PostgreSQL and how to
use them. (There is also this somewhat older
[article](https://www.percona.com/blog/why-linux-hugepages-are-super-important-for-database-servers-a-case-with-postgresql/),
also about the problems of a PostgreSQL without Huge Pages.)
The first article explains really well how Huge Pages work and how to enable
them, so I tried it out and did some preliminary benchmarks and it looks like
an osm2pgsql import can be a bit faster with Huge Pages turned on and enough
reserved for 16GB `shared_buffers`. The effect is not that big and the
benchmarks weren't very thorough, so I am not sure how large the effect really
is, but I am quite sure it won't hurt. And I would expect that the most gain
would not be on the import side, but when rendering or otherwise processing the
data, so that's something that need more looking into.
Long-standing wisdom has been that any higher settings then 2 GB for
`shared_buffers` doesn't help with osm2pgsql. From looking at the articles it
might be that this was due to not having Huge Pages enabled. That's certainly
something we should explore.
I wont have that much time at the moment to look into this, but wanted to put
this out there in case somebody wants to experiment or already has some
experience with this.
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/discussions/2479
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/repo-discussions/[email protected]>
_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
