512MB 机器上的静态托管

一台 1 核 512MB 的机器，跑一个纯静态站，能撑多少并发？答案取决于配置，不取决于机器。默认装完的 Nginx 在空闲时就要吃掉 60–80MB，而调完之后常驻能压到 30MB 左右——省下来的部分，比换一台更大的机器更划算。

先量，再调

没有基线的优化都是猜。两条命令足够：

bash

free -m | awk '/^Mem:/{print "used "$3" / total "$2" MB"}'
ps -o rss=,comm= -C nginx | awk '{s+=$1} END{print s/1024" MB (nginx 全部进程)"}'

注意 Nginx 是 master + worker 的结构，ps 里会有好几行，但 worker 之间大量内存是共享的。所以这些数字加起来会高估真实占用，真实值看 free 的差值更准。

四个真正起作用的参数

nginx

worker_processes      1;
worker_connections    512;

events {
    multi_accept on;
}

http {
    keepalive_timeout   30;
    keepalive_requests  200;

    open_file_cache          max=200 inactive=60s;
    open_file_cache_valid    80s;
    open_file_cache_min_uses 2;
    open_file_cache_errors   on;

    access_log off;
}

worker_processes 1——单核机器开多个 worker 只会让它们抢同一个核，还各占一份缓存。自动检测在这里是负优化。
worker_connections——512 意味着理论上限约 256 个并发连接（每个客户端占两个）。对个人站绰绰有余，而且每个连接的开销是有上限的。
open_file_cache——把 stat 结果缓存在内存里，静态文件每次请求都要做的元数据查询就省了。这是静态站最有效的一项。
access_log off——写日志是小站最没意义的磁盘 IO。如果确实要看流量，改成 buffer=32k flush=5m，别关。

不要做的事

几个看起来「很优化」但实际添乱的做法：

做法	为什么别做
装 Docker 跑 Nginx	多一层网络栈和守护进程，轻松多吃 50MB，收益接近零
上缓存插件 / Varnish	静态文件本来就是读盘直出，多一层缓存只是多一个可能出错的地方
把 `worker_processes` 设成 CPU 核数	单核时这是 1，多核而流量极小时仍然是浪费
编译时加一堆第三方模块	每个模块都常驻内存，而你大概只用得到其中两个

swap 不是耻辱

很多教程建议「小内存机器关掉 swap」，这在小内存 + 低流量场景下是错的。swap 的价值不是提升性能，而是在内存出现尖峰时让进程活下来，而不是被 OOM killer 直接干掉。

bash

fallocate -l 512M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# 降低换出倾向，只在真需要时用
sysctl -w vm.swappiness=10

我宁可它慢一点，也不希望它某天被内核无声地杀掉。

比内存更容易忽略的两件事

调完内存，往往还剩两个隐性风险：

时间同步。默认没开的话，证书校验会莫名其妙失败。一条 timedatectl show -p NTPSynchronized --value 就能确认。
系统盘只有 20GB。日志、旧内核、残留的 apt 缓存能吃掉一半。定期看 df -h，比事后删文件省心。

结果

这台机器最终的状态：Nginx 常驻约 30MB，系统整体占用 120MB 左右，剩下 700MB 全是页缓存——页缓存不是浪费，它让静态文件的读取几乎不碰磁盘。

结论是：小内存机器的瓶颈很少是内存本身，更多是「装了什么」和「怎么配的」。一个纯静态站不需要任何现代化的基础设施，它只需要一个能读文件的进程。