EC2平台基于mod_tile/renderd的OSM瓦片服务器推荐配置咨询

你目前用的t2.xlarge属于突发性能实例，CPU性能波动大，而国家级OSM地图的实时渲染（renderd）和PostGIS空间查询都是持续高负载的场景，这才导致实时渲染慢、不得不依赖render_list预渲染。结合你的技术栈（mod_tile/renderd + osm2pgsql），推荐以下EC2实例配置和配套优化：

一、计算优化型实例：优先解决CPU瓶颈 #

renderd的瓦片渲染是典型的CPU密集型任务，稳定的CPU性能比突发性能重要得多：

• 入门升级：c5.2xlarge：8vCPU（Xeon Scalable 稳定主频）+16G内存，相比t2.xlarge的突发CPU，能稳定跑满renderd的多线程渲染（建议把renderd.conf里的num_threads设为6-7，匹配CPU核心数），实时渲染延迟会明显降低。
• 进阶高配：c5.4xlarge：16vCPU+32G内存，适合地图数据复杂（比如高密度道路网、大量POI）的国家级场景，能同时支撑更多渲染线程，还能给PostgreSQL分配更多CPU资源处理空间查询。

二、内存优化型实例：针对PostGIS缓存需求 #

OSM的PostgreSQL数据库需要把大量空间索引和热门地图数据缓存到内存，避免频繁磁盘IO：

• 基础款：r5.xlarge：4vCPU+32G内存（1:8的内存配比），可以把PostgreSQL的shared_buffers设置为8-12G，work_mem调大到64MB以上，让空间查询更快，减少渲染时的数据库等待时间。
• 高配款：r5.2xlarge：8vCPU+64G内存，适合数据库数据量超过50G的场景（国家级全量OSM数据大概在100-200G），能把大部分常用数据缓存到内存，彻底解决磁盘IO拖慢渲染的问题。

三、存储必须升级：别让EBS拖后腿 #

默认的gp2卷IOPS随容量变化，对于国家级OSM数据库来说，IO性能往往是隐藏瓶颈：

• 推荐用gp3卷：独立配置IOPS（至少3000）和吞吐量（至少250MB/s），把数据库数据和mod_tile缓存目录分别挂载到单独的gp3卷，避免互相抢占IO资源。
• 如果预算充足，选c5d/r5d系列实例：自带NVMe本地存储，IO性能比EBS高一个量级，适合存放mod_tile的临时渲染文件和PostgreSQL的缓存，导入osm数据时速度也会快很多（注意本地盘是临时存储，要定期快照备份数据库）。

四、配合实例的优化小技巧 #

升级硬件后，这些调整能最大化性能：

• 调优renderd.conf：num_threads设为CPU核心数的70%-80%，避免CPU过载；tile_dir指向高性能存储。
• PostgreSQL优化：开启pg_stat_statements定位慢查询，优化空间索引，把shared_buffers设为总内存的25%，maintenance_work_mem调大到2G以上。
• 预渲染策略：用render_list提前渲染z0-z14的全区域，以及z15-z17的重点城市，减少实时渲染的压力。
• 缓存优化：启用mod_tile的磁盘缓存，或者配合Redis做内存缓存，避免重复渲染相同瓦片。

内容的提问来源于stack exchange，提问作者ssast