search

consbio / mbtileserver

Basic Go server for mbtiles
ISC License
658 stars 104 forks source link

Guidelines for memory and CPU? #111

Closed philvarner closed 3 years ago

philvarner commented 3 years ago

I think it would be useful to have some guidelines for how much memory and CPU to allocate for an instance. The only note in the documentation is that hosting "a bunch" of tilesets works on a EC2 nano (512 MiB, 1 vCPU).

I have a mbtiles file that's about 1.7GB, it crashes on an ECS node with 512 MiB / 0.25 vCPU. I upped this to 3GiB/1 vCPU and it seems to be working well. However, I don't know what the relationship between the mbtiles file size and the memory is. I imagine it's more performant to more memory that the total size of your mbtiles, but I don't know.

Any guidance on sizing would be greatly appreciated!

brendan-ward commented 3 years ago

I've been able to run several mbtiles files > 1 GB each on an AWS EC2 T2 / T3 tiny instance (1 vCPU / 1 GB memory; though I always allocate 4 GB SWAP on these instances). The core memory usage is directly proportional to the number of tilesets, but not the size of the tilesets. The memory per tileset should be very small; we are just keeping a connection to the tileset and a few other attributes in memory for each.

As you request tiles from it, memory usage will go up a little bit (mostly proportional to the number of unique tile requests per timeframe and their respective tile memory footprint), but most of that should be transient and releasable as the tiles are returned in the request. I've noticed that the memory is not always released by Go / reclaimed by the OS, so you'll typically see a higher virtual memory number (e.g., I'm seeing 1.4 GB virtual memory for a long-running instance).

I haven't tested this across a wide range of instances or tileset size / request throughput scenarios, so I'm not able to provide specific recommendations.

When you say crash, does it crash when you are running it, or crash when you are building it from source or via go get? I certainly have run into problems with building on memory restricted instances esp. for certain versions of Go, so that could be an issue here.

philvarner commented 3 years ago

That's very helpful -- thanks!

When I said crash, a more accurate description would be unresponsive after some number of tile requests are successful. I think having too little memory would explain it -- 512MB and no swap vs. 1GB + 1GB swap. The 1.4GB is a good baseline -- I'll try it with 2GB and see what happens.

philvarner commented 3 years ago

Also, I just wanted to thank you for the great work on this app -- we were planning to use tileserver-gl (which seems to be at a development dead-end), and the thoroughness of documentation and evident thoughtfulness in the features of this project made the decision pretty easy!