postgresql vps
数据库与内存工作负载
超过一定的工作集大小，唯一重要的优化就是将整个数据集放入 RAM。FORGE 每个核心提供最多 16 GB 的注册 ECC 内存，并预先配置了 hugepages 和 NUMA 感知的放置，这正是 PostgreSQL、Redis、ClickHouse 和大型 JVM 堆所需要的。底层是 Gen5 NVMe RAID10，这样真正写入磁盘的数据也不会成为瓶颈。
为什么这个配置
具有单 NUMA 亲和性的 FORGE 可保持内存访问在本地进行工作。添加每日备份，保留三十个恢复点，因为你实际会遇到的是糟糕的迁移，而不是磁盘故障。
我们会部署什么
规模确定
根据工作集而不是数据库大小来规划内存。工作集是热索引页加上实际访问的行，通常占 2 TB OLTP 数据集的 10-20%。将 InnoDB buffer pool 设置为 RAM 的 70-75%，或者将 Postgres shared_buffers 设置为 25%，并让页面缓存保存其余部分。FORGE 每个核心达到 16 GB，因此一个 512 GB 的缓冲区池大致需要 700 GB RAM 和至少 44 个核心。如果缓存未命中率超过 1%，就购买更多 RAM。
Hugepages 以及为什么 THP 不同
一个 256 GB 的缓冲池以 4 KB 页面映射需要大约 6400 万个页表条目。TLB 无法容纳其中有意义的部分，因此随机访问在大多数查找时都会付出页表遍历的代价。静态 2 MB 大页将条目数量减少 512 倍，随之减少遍历——在大型池上，每次查询的 CPU 时间有望显著下降。通过 vm.nr_hugepages 在启动时分配，大小为池加上约 10%，并给数据库用户 memlock 限制。透明大页实现相同的映射，但它是机会性的，并带有压缩停顿。禁用 THP 并显式分配。
工作集，测量而非猜测
不要根据数据目录大小来估计工作集。测量它。在 Postgres 中，pg_buffercache 告诉你哪些关系占用了 shared_buffers，而 pg_statio_user_tables 中的 heap_blks_hit 与 heap_blks_read 之比给出了每个表的缓存命中率。在 MySQL 中，Innodb_buffer_pool_reads 与 Innodb_buffer_pool_read_requests 之比提供了同样的信号。高于 99% 你就在内存中，增加 RAM 收益不大。在 95% 到 99% 之间，你处于悬崖边缘，一个未索引的查询就可能把你推下去。低于 95%，你所有的延迟数字实际上都是乔装打扮的磁盘延迟数字。
常见问题
- 保持透明大页启用。THP 的碎片整理会在不可预测的时刻使进程停顿数毫秒，这表现为无法解释的 p99 延迟。将其设置为 never，并改为分配静态大页。
- 在双插槽 FORGE 上忽略 NUMA。缓冲区池位于一个节点上，一半的核心通过互连读取，尽管有可用内存，MySQL 仍可能会进行交换。使用 numactl --interleave=all 或显式绑定。
- 根据平均吞吐量规划 IOPS。检查点、vacuum 和备份才是重要的峰值。一个能处理稳定状态的池在检查点刷新期间会使整个实例停滞。
调整配置
- CPU调度 — Single-NUMA-node affinity · €14
- 备份 — 每日备份，30个恢复点 · €11
- 其他所有选项 — 秒级指标和告警 · €5
- 存储和加密 — ZFS with hourly snapshots · €7