immich-low-memory-tuning-20260601

Immich 低配服务器会卡吗？相册备份的内存和任务设置

Immich 的网页能打开，不代表照片导入体验就好。第一次上传几万张照片时，缩略图、视频转码、机器学习和数据库会一起吃资源。本文按家庭相册场景讲低配能不能跑，以及哪些任务该限速。

先说结论：谁适合这样做

适合：

家庭照片自动备份
手机相册长期归档
愿意单独规划大容量数据盘的用户

不适合：

几十万张照片且要求快速识别
低配机器还同时跑很多重服务
不愿意做原图异地备份

这一步要先讲清楚，是因为很多服务器教程只告诉你"怎么装"，却不告诉你"该不该装"。如果场景不匹配，后面配置写得再漂亮，也只是把问题推迟到上线之后。

服务器配置怎么选

Immich 不建议用 1 核 2G 硬撑。4 核 16G 是更舒服的家庭相册档，特别是首次导入阶段。低配也能跑，但要限制后台任务并发，机器学习服务可以延后开启。磁盘要优先选择可靠性和容量。

我会把 Immich 放在 雨云服务器 rainyun-com 的 4 核 16G 机型上，家庭照片备份、缩略图生成和基础识别比较稳。注册填优惠码 2026off 领 5折，这类配置更适合先稳定跑起来，再按真实负载升级。

落地步骤

准备一台干净的 Ubuntu 22.04 或 Debian 12 服务器，先确认 SSH、时间同步和防火墙状态。
规划目录：/opt/immich-low-memory-tuning-20260601。配置、数据、备份脚本都放在同一主题目录下，后面迁移更省事。
根据主题放行端口：2283/tcp。游戏和网络服务尤其要分清 TCP/UDP。
先用测试数据跑通，再导入正式数据或邀请其他人使用。

关键配置示例

下面配置用于说明关键项，发布前要按当前官方文档确认镜像版本、环境变量和端口。

yaml 复制代码

services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:release
    container_name: immich-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:2283:2283"
    environment:
      DB_HOSTNAME: database
      DB_USERNAME: immich
      DB_PASSWORD: change-this-db-password
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: redis
    volumes:
      - /data/immich/upload:/usr/src/app/upload

如果需要 HTTPS，可以让应用只监听本机端口，再用 Caddy 反代：

Caddyfile 复制代码

immichlowmemorytuning.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:2283
}

启动验证

上传 100 张照片和几段视频，确认缩略图、时间线、下载原图和移动端备份都正常，再开始全量迁移。

验证时不要只看进程是否存在，至少完成一次真实动作：游戏服要让外部玩家连接，应用要登录并写入一条数据，运维项要确认状态变化真的生效。这样能提前发现端口、权限、反代和路径问题。

常见问题和排错

第一次导入不要让所有手机同时全速上传。先导入一部手机观察 CPU、内存、磁盘写入和任务队列，再逐步放开。

排查建议按这个顺序来：

看日志里第一条明确错误，不要只看最后一屏。
查端口监听和云安全组，确认协议没有写错。
检查数据目录权限，尤其是容器用户和宿主机目录映射。
回滚到上一个能工作的配置，再逐项恢复新改动。

备份和后续维护

数据库 dump 和 upload 原图目录必须成对备份。只有原图没有数据库，恢复体验会很痛苦。

维护时建议保留一份"最小恢复说明"：需要哪些文件、恢复命令是什么、域名和端口在哪里改。等真正出问题时，人通常没那么冷静，清单比记忆可靠。

总结

Immich 值得给更稳的机器，因为照片是长期资产，不是随便删了重建的测试数据。