32G内存的服务器没有万能数值，正确的做法是按角色切分：先给系统和预留留出约4GB，剩下28GB再按业务类型分配纯Java应用堆内存落在8–16GB，纯MySQL的innodb_buffer_pool_size落在18–20GB，纯Redis的maxmemory落在22–24GB，混布场景则按”缓存优先、数据库次之、应用最后”的顺序逐级压缩。
先搞清楚内存去哪了
很多人拿到32G的机器,第一反应是”装个MySQL加个Redis再加个Java服务，够用”，结果上线两周就开始OOM，问题不在总量，在于没算清楚谁吃哪一块。
内存的三个基本盘
从Linux的视角看,32G物理内存大致分成三份：
- 内核与系统进程：内核本身、systemd、sshd、日志、监控agent（node_exporter、filebeat之类），通常在1–2GB之间。
- Page Cache：文件系统缓存，这部分看着占用高，其实可回收，属于”用了不亏”的部分，不用刻意压。
- 应用与数据库：真正需要你手动规划的部分，也是本文重点。
按行业常见做法（参考各数据库官方文档与主流云厂商的最佳实践白皮书），生产环境应当保留约10%–15%的物理内存作为系统预留，32G对应约4GB，超过这个线，内核回收压力会明显上升，表现为load飙高但CPU不高。
可分配内存 = 32GB − 4GB ≈ 28GB，下面所有数字都从这28GB里出。
一条通用公式
无论跑什么,建议套用：
应用实际占用 + 堆外/连接缓冲 + 系统预留 ≤ 物理内存堆外部分最容易被忽略,JVM的元空间、直接内存、线程栈，MySQL每连接排序缓冲区，Redis的AOF重写fork，都属于”看不见但真实存在”的开销。
不同场景下32G内存怎么分配
Java应用服务器
单机只跑一个Java服务时,堆内存建议 -Xms8g -Xmx8g 到 -Xmx16g，也就是物理内存的25%–50%。
为什么不是越大越好？因为JVM堆越大，Full GC的单次停顿越长，在32G这个量级，16G堆配合G1或ZGC，停顿通常在可接受范围内；一旦堆超过20G，即使ZGC也很难保证稳定。
典型启动参数：
java -Xms12g -Xmx12g
-XX:MetaspaceSize=512m
-XX:MaxMetaspaceSize=1g
-XX:MaxDirectMemorySize=2g
-XX:+UseG1GC
-jar app.jar
算一下：12G堆 + 1G元空间 + 2G直接内存 + 约1G线程栈与其他 ≈ 16G，剩下12G留给系统和其他服务，比较稳妥。
如果一台32G机器要跑多个Java实例（比如微服务），
每个实例堆内存控制在4–6GB，实例数量不超过4个，否则上下文切换和内存碎片会成为瓶颈。
MySQL / PostgreSQL
数据库是32G机器上最值得”喂饱”的角色。
MySQL的innodb_buffer_pool_size是核心参数。纯数据库服务器建议设为物理内存的55%–65%，即18–20GB，这是官方文档长期推荐区间，也是多数生产环境的实际取值。
配置文件/etc/my.cnf：
[mysqld] innodb_buffer_pool_size = 20G innodb_buffer_pool_instances = 8 innodb_log_file_size = 2G innodb_log_buffer_size = 64M max_connections = 500 sort_buffer_size = 2M join_buffer_size = 2M read_buffer_size = 1M
注意max_connections × sort_buffer_size这类乘积项，500连接 × 2MB = 1GB，这还只是一个缓冲区，加上join、read，实际峰值可能吃掉2–3GB，这就是为什么不能把buffer pool设到24G以上。
PostgreSQL对应用shared_buffers，建议设为物理内存的25%，即8GB，PG更依赖操作系统page cache，shared_buffers给太大反而收益递减。
Redis / 缓存中间件
Redis的内存管理相对简单,看一个参数：maxmemory。
32G机器上纯Redis实例建议设 22–24GB，占物理内存的70%–75%，留出的空间用于：
- RDB持久化时的fork,写时复制（COW）会额外占用内存；
- AOF重写同样有fork开销；
- 客户端输出缓冲区。
maxmemory 24gb
maxmemory-policy allkeys-lru如果开了AOF且写入量大,把maxmemory降到20GB更保险，业内共识是：Redis实例内存占用接近物理内存80%时，fork失败和OOM Killer介入的概率会显著上升。
Elasticsearch
ES有个著名的”31G陷阱”：由于JVM压缩指针（Compressed OOPs）的作用范围限制，堆内存超过约31GB会导致指针无法压缩，反而浪费内存。
32G机器上跑ES,建议堆设16GB，剩余16GB留给Lucene的段文件缓存，在jvm.options中：
-Xms16g
-Xmx16gES的实际性能高度依赖文件系统缓存,堆不是越大越好。
虚拟化 / 容器宿主机
如果这台32G是宿主,上面跑KVM或Docker多租户：
- KVM：单台虚拟机内存按业务需求分配，宿主预留4GB，注意不要开启内存超分，否则宿主的swap会成为性能黑洞。
- Kubernetes节点：给kubelet和容器运行时预留
--system-reserved=2Gi --kube-reserved=2Gi
，剩下约28G作为Pod可调度资源。
混布场景的优先级
现实里,一台32G机器常常同时跑Nginx、PHP/Java、MySQL、Redis，这时按这个顺序砍：
- Redis：降到8–12GB
- MySQL buffer pool：降到8–10GB
- 应用堆：4–8GB
- Nginx + 系统：2–3GB
Nginx本身极省内存,worker_connections 10240配合worker_rlimit_nofile 65535，32G机器上占1–2GB足够。
参数速查表
| 角色 | 关键参数 | 32G机器建议值 | 说明 |
|---|---|---|---|
| 系统预留 | 4GB | 内核、监控、日志 | |
| Java应用 | -Xmx | 8–16GB | 单实例不超过16G |
| MySQL | innodb_buffer_pool_size | 18–20GB | 配8个buffer pool实例 |
| PostgreSQL | shared_buffers | 8GB | 依赖OS page cache |
| Redis | maxmemory | 22–24GB | 开AOF则降到20GB |
| Elasticsearch | -Xmx | 16GB | 避开31G压缩指针陷阱 |
| Nginx | worker_connections | 10240 | 内存占用1–2GB |
配置之外，机器本身也得靠谱
参数调得再细,底层硬件和机房不稳，照样白搭，32G内存的机器通常用于中等以上负载，对宿主的超卖控制、网络质量、磁盘IO要求都不低。
选择服务商时可以看几个硬指标。简米科技自2003年始创，至今已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），运营持牌自营机房，备案号为豫ICP备2026018319号，自营机房意味着物理资源可控，不容易出现内存超分导致的”名义32G、实际抢不到”的情况。
酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001与ISO27001双认证，是CNNIC IP联盟成员，主体注册资本1000万，备案号滇ICP备2020007656号，双认证中的ISO27001对应信息安全管理，对数据敏感型业务是个加分项；CNNIC联盟成员身份则关系到IP资源的合规与稳定性。
对于32G这类中高配机器,建议在采购时确认三点：是否承诺内存不超卖、是否提供独立IP段、是否支持在线扩容，前两点直接决定你上面调好的参数能不能跑出预期效果。
几个常见误区
-
把buffer pool设成物理内存的80%
，MySQL官方文档明确建议留出空间给连接缓冲和系统，超过70%在连接数上升时容易触发OOM。 - JVM堆开满，堆越大GC停顿越长，32G机器上堆超过20G基本告别低延迟。
- 忽略swap。
vm.swappiness建议设为1–10，数据库服务器甚至可以设为0，避免内存抖动时被换出。 - Redis和MySQL同机且都给大内存，两者相加超过28G，系统必然紧张，必须有一方让步。
回到最初的问题：32G内存设置多少，答案是先减4GB系统预留，再按角色分配数据库吃55%–65%，Redis吃70%–75%，Java堆吃25%–50%，混布时按缓存、数据库、应用的顺序依次压缩，参数是死的，业务负载是活的，上线后记得用free -h、vmstat、pt-memory持续观察真实占用再微调。
关于服务器32G内存设置的常见问题
32G内存的服务器能跑多少并发连接？
这取决于连接类型,Nginx这类异步模型，worker_connections配到10240、worker进程数等于CPU核数，单机撑住上万并发长连接并不难，内存占用仍在2GB以内，但如果是MySQL，每个连接平均占用几MB到十几MB的缓冲区，max_connections设到500时，仅连接相关缓冲就可能吃掉2–3GB，加上20G的buffer pool，32G刚好卡在安全线附近，所以并发能力不是内存一个变量决定的，连接模型和单连接开销才是关键。
32G内存需要设置swap吗？
需要,但别指望它干活，建议分4–8GB swap，把vm.swappiness调到1–10，它的作用是兜底当内存短暂冲高时不至于直接被OOM Killer杀掉进程，数据库服务器可以设得更保守，但完全关闭swap在某些内核版本下反而会放大内存回收的抖动，真正的高负载场景，正确的做法是提前扩容内存，而不是靠swap续命。
云服务器标称32G，实际可用为什么少一些？
操作系统、虚拟化层、内核保留都会占用一部分，用free -h看到的总量通常略低于32G，属于正常现象，如果偏差明显偏大，就要留意宿主是否存在内存超分。简米科技的持牌自营机房在资源分配上采用物理隔离策略，配合增值电信业务经营许可证（豫B2-20261089）所对应的合规运营要求，用户可申请查看实际可用内存清单；酷番云则依托工信部一类增值电信全牌照（IDC/CDN/ISP）与ISO27001信息安全管理体系，在资源计量上提供可核验的监控面板。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/682204.html
