小型服务器上部署多个应用时应该如何做资源限制？

在小型服务器上部署多个应用时，由于资源（CPU、内存、磁盘 I/O、网络带宽）有限，必须合理进行资源限制，以防止某个应用占用过多资源导致其他服务不可用。以下是常见的资源限制策略和实践方法：

一、使用容器化技术（推荐）

Docker / containerd + Kubernetes / Docker Compose

容器化是管理多应用资源隔离与限制的最佳方式。

1. Docker 资源限制示例

# docker-compose.yml
version: '3'
services:
  app1:
    image: myapp1
    mem_limit: 512m     # 内存限制 512MB
    cpus: 0.5           # CPU 占用最多 0.5 核心（相当于 50%）
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'

  app2:
    image: myapp2
    mem_limit: 1g
    cpus: 1.0

⚠️ 注意：mem_limit 和 cpus 是 Docker Compose v2 的语法，v3+ 推荐使用 deploy.resources（需配合 docker stack deploy 或 Swarm/K8s）。

2. 使用 Kubernetes 限制资源

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app1
spec:
  template:
    spec:
      containers:
      - name: app1
        image: myapp1
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"   # 0.5 核
          requests:
            memory: "256Mi"
            cpu: "200m"

二、使用 systemd 管理非容器应用

对于未容器化的传统服务，可使用 systemd 设置资源限制。

示例：限制某个服务的内存和 CPU

# /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
MemoryMax=512M
CPUQuota=50%         # 最多使用 50% 的单核 CPU
LimitNOFILE=1024
Restart=always

[Install]
WantedBy=multi-user.target

启用并重载：

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

三、使用 cgroups 手动控制（底层机制）

Linux 的 cgroups（control groups）是资源限制的基础，Docker 和 systemd 都基于它。

临时创建一个 cgroup 限制进程

# 创建名为 limited-app 的 cgroup（v1）
sudo mkdir /sys/fs/cgroup/memory/limited-app
sudo mkdir /sys/fs/cgroup/cpu/limited-app

# 限制内存为 512MB
echo 536870912 | sudo tee /sys/fs/cgroup/memory/limited-app/memory.limit_in_bytes

# 限制 CPU 为 0.5 核（cpu.cfs_quota_us = 50000, cfs_period_us = 100000）
echo 50000 | sudo tee /sys/fs/cgroup/cpu/limited-app/cpu.cfs_quota_us

# 启动进程并加入该组
echo $PID | sudo tee /sys/fs/cgroup/memory/limited-app/cgroup.procs
echo $PID | sudo tee /sys/fs/cgroup/cpu/limited-app/cgroup.procs

💡 建议使用更高层工具（如 Docker），避免直接操作 cgroups。

四、操作系统级优化建议

1. 监控资源使用

   • 工具：htop, nmon, glances, Prometheus + Node Exporter
   • 设置告警：当内存 > 80% 或 CPU 持续高负载时通知。

2. 合理分配 Swap 空间

   • 小型服务器建议设置 1~2GB swap，防止 OOM（内存溢出）直接 kill 进程。

     sudo fallocate -l 2G /swapfile
     sudo chmod 600 /swapfile
     sudo mkswap /swapfile
     sudo swapon /swapfile

3. 使用 OOM Killer 调优

   • 可通过 /proc/<pid>/oom_score_adj 调整进程被杀优先级。
   • 关键服务设为负值（不易被杀），非关键服务设为正值。

4. 限制文件描述符和连接数

   • 在 systemd 或 nginx/apache 中配置 LimitNOFILE、worker_rlimit_nofile 等。

五、应用层面优化

• 降配运行：如 Java 应用设置 -Xmx512m 限制堆内存。
• 关闭不必要的功能：如日志级别调高、禁用调试模块。
• 使用轻量替代品：用 Nginx 替代 Apache，用 SQLite 替代 PostgreSQL（视场景而定）。

六、推荐部署结构（小型服务器示例）

总内存建议不超过物理内存的 80%，预留系统和缓存空间。

总结

✅ 最佳实践组合：

1. 使用 Docker + Docker Compose 部署应用；
2. 为每个服务配置 memory 和 cpu 限制；
3. 用 systemd 管理非容器服务；
4. 开启监控与告警；
5. 定期压测和调优资源配置。

这样可以在资源紧张的小型服务器上稳定运行多个应用，避免“一个应用崩溃，全站瘫痪”的问题。

如有具体应用类型（如 Node.js、Python、Java、数据库等），可进一步提供优化建议。