用于前端的 nginx 将 rsync/rsync-ssl 反代给后端真实的 rsync 服务，通过 proxy protocol 传递客户端真实IP。

stream {

    server {
        listen 873;
        proxy_pass 192.168.10.10:873;
        proxy_protocol on;
        proxy_timeout 1m;
        proxy_connect_timeout 5s;
    }

    server {
        listen 874 ssl;
        listen [::]:874 ssl;
   
	ssl_certificate ssl/yaoge123_com-ecc.crt;
        ssl_certificate_key ssl/yaoge123_com-ecc.key;
        ssl_certificate ssl/yaoge123_com-rsa.crt;
        ssl_certificate_key ssl/yaoge123_com-rsa.key;

	ssl_session_timeout 1d;
        ssl_session_cache shared:rsyncSSL:10m;

	ssl_dhparam ssl/dhparam.pem;

        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ecdh_curve X25519:prime256v1:secp384r1;
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
        ssl_prefer_server_ciphers off;

        ssl_stapling on;
        ssl_stapling_verify on;

        proxy_pass 192.168.10.10:873;
        proxy_protocol on;
        proxy_timeout 1m;
        proxy_connect_timeout 5s;
    }
}

Seafile 13 版本将缩略图服务从主服务中拆分出来成为独立的 thumbnail-server 容器，这个架构改变在生产环境中遇到了内存泄漏和高并发下的性能问题。经过和AI几天的折腾，总结出以下优化方案。

问题现象

生产环境高并发请求，nginx 大面积499/504，用户看到的缩略图都裂开了。thumbnail-server 运行后可见内存快速增长，直到 OOM Killer 介入，重启，继续涨，继续崩，Grafana 上看内存曲线就是一个又一个锯齿。

问题分析

内存泄漏

通过 tracemalloc 分析发现主要有三处内存泄漏：

1. SeaFile._content 缓存泄漏：seafobj 库中 SeaFile 对象的 _content 属性会缓存整个文件内容，处理完成后没有清理，导致大文件内容一直驻留在内存中。
2. 缩略图生成函数无显式清理：PIL 图像对象、临时文件等资源在函数结束后没有显式释放，依赖 Python 的垃圾回收机制，但在高并发场景下 GC 跟不上分配速度。
3. task_results_map 无限增长：任务结果存储在字典中，当客户端超时断开连接时，结果永远不会被取走，字典持续增长。

C 扩展层面的碎片化

Python 层面修复后，内存仍然缓慢增长。用 /proc/PID/smaps 分析发现：

总 RSS: 3020 MB
├── 匿名内存 (malloc): 2995 MB (99%)
│   ├── libavif (Pillow): 743 MB
│   ├── _imagingmath (Pillow): 282 MB
│   └── 碎片化块: 20+ 个 50-64MB 块
└── Python (tracemalloc): 8 MB

Pillow 处理图片时 glibc malloc 分配的内存无法归还系统，造成严重碎片化。

大文件占用内存

大文件（视频/PDF）会全部加载到内存，占用大量内存容量。

性能瓶颈

1. 异步阻塞：http_response.py 中使用 time.sleep() 而不是 await asyncio.sleep()，阻塞了事件循环，影响并发处理能力。
2. 队列竞争：PDF/PSD 等慢任务与普通图片在同一队列中处理，慢任务阻塞快任务。
3. Worker 数量固定：默认只有 3 个 worker，无法充分利用多核服务器。

Nginx 配置问题

容器内 nginx 配置 proxy_pass http://localhost:8088，当启用IPv6时 localhost 解析到 IPv6 地址，而后端只监听 IPv4，导致连接失败。

优化方案

1. 内存泄漏修复

在 utils.py 的 get_file_content_by_obj_id() 函数中添加 finally 块清理 SeaFile 对象：

def get_file_content_by_obj_id(repo_id, file_id):
    f = fs_mgr.load_seafile(repo_id, 1, file_id)
    try:
        return f.get_content()
    finally:
        # 清理缓存的文件内容，防止内存泄漏
        if hasattr(f, '_content'):
            f._content = None
        if hasattr(f, 'blocks'):
            f.blocks = None

在 thumbnail.py 的各个缩略图生成函数中添加显式的垃圾回收：

def create_image_thumbnail(repo_id, file_id, thumbnail_file, size):
    try:
        # 原有逻辑
        ...
    finally:
        gc.collect()

在 thumbnail_task_manager.py 中添加任务结果过期清理机制：

RESULT_EXPIRE_TIME = 120  # 秒

def _cleanup_expired_results(self):
    """清理超过 120 秒的任务结果"""
    now = time.time()
    expired_keys = []
    with self._results_lock:
        for task_id, (result, timestamp) in self.task_results_map.items():
            if now - timestamp > RESULT_EXPIRE_TIME:
                expired_keys.append(task_id)
        for key in expired_keys:
            del self.task_results_map[key]

2. 使用 jemalloc 替换 glibc malloc

jemalloc 内存管理更好，能主动归还内存给系统。

Dockerfile 添加：

RUN apt-get install -y libjemalloc2

启动脚本添加：

export JEMALLOC_LIB=${JEMALLOC_LIB:-/usr/lib/x86_64-linux-gnu/libjemalloc.so.2}
if [ -z "$LD_PRELOAD" ] && [ -f "$JEMALLOC_LIB" ]; then
    export LD_PRELOAD="$JEMALLOC_LIB"
fi

3. 大文件流式处理

文件大于阈值时不再全部加载到内存，而是流式写入临时文件：

def stream_file_to_path(seafile_obj, dest_path, chunk_size=8*1024*1024):
    with open(dest_path, 'wb') as f:
        for chunk in iter(lambda: seafile_obj.read(chunk_size), b''):
            f.write(chunk)

4. 异步阻塞修复

将 http_response.py 中的 time.sleep() 改为 await asyncio.sleep()：

# 修改前
time.sleep(0.2)

# 修改后
await asyncio.sleep(0.2)

5. 队列分离

新增 pdf_queue 处理慢任务（PDF、PSD），让快任务（图片、SVG、XMIND）不被阻塞：

def __init__(self):
    self.image_queue = queue.Queue(32)      # 快任务
    self.pdf_queue = queue.Queue(32)        # 慢任务
    self.video_queue = queue.Queue(32)      # 视频

队列分配：

• image_queue：图片、SVG、XMIND（快）
• pdf_queue：PDF、PSD（慢）
• video_queue：视频（很慢）

6. 环境变量支持

添加 TASK_WORKERS 和 THUMBNAIL_IMAGE_SIZE_LIMIT 环境变量支持，方便根据服务器配置调整：

# settings.py
TASK_WORKERS = int(os.environ.get('THUMBNAIL_TASK_WORKERS', TASK_WORKERS))
THUMBNAIL_IMAGE_SIZE_LIMIT = int(os.environ.get('THUMBNAIL_IMAGE_SIZE_LIMIT', 30))

7. Nginx IPv6 修复

将 localhost 改为 127.0.0.1 强制使用 IPv4：

proxy_pass http://127.0.0.1:8088;

同时启用日志便于排查问题：

access_log /opt/seafile/logs/thumbnail-server.access.log seafileformat;
error_log /opt/seafile/logs/thumbnail-server.error.log;

8. 内存限制自动重启

万一还有漏网之鱼，超过内存限制就自动退出让容器重启：

MEMORY_LIMIT_MB = int(os.environ.get('THUMBNAIL_MEMORY_LIMIT', 4096))

def _check_memory_and_exit():
    with open('/proc/self/statm') as f:
        rss_pages = int(f.read().split()[1])
    rss_mb = rss_pages * 4096 / 1024 / 1024
    if rss_mb > MEMORY_LIMIT_MB:
        logger.warning(f'Memory {rss_mb:.0f}MB exceeds limit, exiting')
        os._exit(1)

生产环境配置

优化后服务器配置缩减到 8 核 16 GB，完全够用。

环境变量配置（/nfs/thumbnail.env）：

THUMBNAIL_TASK_WORKERS=32
THUMBNAIL_IMAGE_SIZE_LIMIT=100
THUMBNAIL_IMAGE_ORIGINAL_SIZE_LIMIT=1024

变量	值	默认值	说明
THUMBNAIL_TASK_WORKERS	32	4	每种队列的 worker 线程数
THUMBNAIL_IMAGE_SIZE_LIMIT	100 MB	30 MB	原始文件大小限制
THUMBNAIL_IMAGE_ORIGINAL_SIZE_LIMIT	1024 MB	256 MB	图片解码后内存限制

PR 提交

以上优化已提交 PR 到官方仓库 haiwen/seafile-thumbnail-server 的 13.0 分支：

PR	内容
#23	Python 内存泄漏修复
#24	asyncio.sleep 修复
#25	THUMBNAIL_TASK_WORKERS 环境变量
#26	nginx IPv6 修复
#27	THUMBNAIL_IMAGE_SIZE_LIMIT 环境变量
#28	队列分离优化
#29	智能流式处理
#30	内存限制自动重启
#32	jemalloc 支持

总结

缩略图服务是典型的 I/O 密集型应用，瓶颈主要在 S3 存储的网络延迟而非 CPU。优化的重点是：

1. 及时释放内存：处理完文件后立即清理缓存
2. 避免阻塞：异步代码不要用同步 sleep
3. 队列隔离：快慢任务分开处理
4. 可配置性：通过环境变量调整参数

优化后内存稳定在 <2GB 左右，高峰期也能正常处理请求。

git.nju.edu.cn 从2025年11月开始得到了 AI bot 的热爱，CPU 根本扛不住，临时限制了校外的网络带宽，但这导致校外慢的几乎无法使用。所以趁着元旦，用 Anubis 对网站进行保护，把 bot 拒之门外。

反向代理模式

Anubis 默认以反向代理的模式运行，所有的流量都经过 Anubis ，Anubis 再将流量反代给后端服务。这种情况下前面还要有一个 HTTPd 如 nginx 实现 TLS 终结再将流量反向代理给 Anubis。在这种情况下怎么将客户端的真实IP传递给最后的应用尤为关键。

当正常访问者的IP有可能为 RFC 1918 私网IP，如校园网环境，校园网内用户使用私网IP访问校园网内服务器是非常正常的行为。但是当这种情况下，Anubis 的处理就有点不尽如人意了。

Anubis 使用 X-Real-IP 和 X-Forwarded-For 处理客户端真实IP，与之相关的环境变量有两个 CUSTOM_REAL_IP_HEADER 和 XFF_STRIP_PRIVATE。

Anubis 会对 X-Forwarded-For 进行处理

• 当 XFF_STRIP_PRIVATE=true (默认值)时从右向左扫描将第一个公网IP配置为新的 X-Forwarded-For ，如果所有的客户端都是公网 IP 这没有问题，但是如果客户端是公网和私网 IP 混合的模式就是麻烦了。对于私网 IP 的客户端，Anubis 的日志中 X-Forwarded-For 就变空了，如果后端服务使用 X-Forwarded-For 识别客户端真实IP（ GitLab 中配置 nginx[‘real_ip_header’] = ‘X-Forwarded-For’ ），结果后端记录的都是前端 nginx 的 IP，这里的 nginx IP 也是私网IP。
• 当 XFF_STRIP_PRIVATE=false 时从右向左扫描将第一个公网或私网IP配置为新的 X-Forwarded-For ，结果 Anubis 的日志中 X-Forwarded-For 均为前端 nginx 的IP，后端记录的也都是前端 nginx 的 IP。

Anubis 要求前端反向代理将客户端真实IP放在 X-Real-IP 中，如果请求头名字不是这个可以用 CUSTOM_REAL_IP_HEADER 来配置，但是必须有否则会报错。如果后端服务使用 X-Real-IP 识别客户端真实IP（ GitLab 中配置 nginx[‘real_ip_header’] = ‘X-Real-IP’ ），结果后端记录的都是 Anubis 的 IP，估计是反代给后端的时候就没有 X-Real-IP ，但在 Anubis 的日志中是正常的，具体我没有探究，在群友的提醒下马上改用 sidecar 模式了。

当然也不是没有解决办法，可以过两次 nginx 。第一次 nginx 把 X-Real-IP 和 X-Forwarded-For 用其它名字的请求头再保存一次，然后将流量反代给 Anubis 。Anubis处理完后将流量反代给 nginx，第二次 nginx 用第一次保存的其它名字做恢复，然后将流量反代给后端服务。配置看起来像下面这样，还是赶快用边车模式吧。

#第一层nginx
  listen 443 ssl;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Real-IP-Frontend $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-For-Frontend $proxy_add_x_forwarded_for;
  proxy_pass http://anubis:8923;
#anubis
  BIND=":8923"
  TARGET=: "http://nginx:3923"
#第二层nginx
  listen 3923;
  proxy_set_header X-Real-IP $http_x_real_ip_frontend;
  proxy_set_header X-Forwarded-For $http_x_forwarded_for_frontend;
  proxy_pass http://gitlab:80;

不太理解 Anubis 为什么要去这样修改 X-Real-IP 和 X-Forwarded-For，正常的反向代理应该从网络层获取客户端IP然后添加到 X-Forwarded-For 后面。

sidecar 模式

对所有的请求，nginx 都会内部发起子请求 auth_request 到 /.within.website/x/cmd/anubis/api/check ，如果认证服务（anubis）返回 200，则请求继续反代给 gitlab 。如果认证服务（anubis）返回 401，则返回客户端 307 重定向到 /.within.website/?redir=……，引导客户端通过 anubis 验证，成功后再跳回原来的链接。

nginx 配置片段

• /.within.websit 是需要反代给 Anubis 的内容，不包括请求体，只包括请求头，通过请求头传递客户端IP。需要注意的是虽然 proxy_pass_request_body off;，但 nginx 的 body 大小检查发生在处理 proxy_pass 之前，所以还需要添加 client_max_body_size 0;。
• @redirectToAnubis 是给客户端的重定向，让客户端通过 Anubis 验证。注意这里需要 nginx 有 ndk 和 set-misc 模块
• / 是主入口，auth_request 把所有的请求先给 /.within.website/x/cmd/anubis/api/check ，如果返回200则继续，如果返回401则转给上面的@redirectToAnubis

    location /.within.website/ {
        proxy_pass http://anubis:8923;
	proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_pass_request_body off;
        proxy_set_header content-length "";
        auth_request off;
        client_max_body_size 0;
    }
    location @redirectToAnubis {
        set_escape_uri $encoded_redir $scheme://$host$request_uri;
        return 307 /.within.website/?redir=$encoded_redir;
        auth_request off;
    }
    location / {
        auth_request /.within.website/x/cmd/anubis/api/check;
        error_page 401 = @redirectToAnubis;
        include conf.d/proxy_git;
    }

其中 proxy_git 的内容

        proxy_connect_timeout 600;
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        proxy_buffering off;
        proxy_request_buffering off;
        client_max_body_size 0;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_pass http://gitlab:80;

anubis 策略配置片段

• 为了能够让 nginx 区别被拦截的请求，需要对 anubis 的拒绝策略更改 HTTP 状态码为403
• 对于生产环境建议持久化数据，而不是使用内存

status_codes:
  CHALLENGE: 200
  DENY: 403
store:
  backend: bbolt
  parameters:
    path: /data/bbolt/anubis.bdb

anubis 容器配置片段

• 挂载配置文件和持久化目录，注意持久化目录对于1000:1000要可写
• BIND 为接受请求的端口，在 sidecar 模式下 TARGET 为空格
• 持久化存储需要固定一个64个字符的16进制私钥（可用 openssl rand -hex 32 生成）
• Anubis 输出的日志是标准的 ndjson

    volumes:
      - ./anubis/policy.yaml:/data/cfg/botPolicy.yaml:ro
      - ./anubis/bbolt:/data/bbolt:rw
    environment:
      BIND: ":8923"
      TARGET: " "
      COOKIE_DOMAIN: "git.nju.edu.cn"
      CUSTOM_REAL_IP_HEADER: "X-Real-IP"
      ED25519_PRIVATE_KEY_HEX: "123456789abcdef123456789abcdef123456789abcdef123456789abcdef1234"
      POLICY_FNAME: "/data/cfg/botPolicy.yaml"
    labels:
      - co.elastic.logs/json.target=""
      - co.elastic.logs/json.add_error_key=true

以上的 nginx 和 GitLab 均在容器中运行，anubis 容器镜像为 ghcr.io/techarohq/anubis:v1.24.0