Bean Deng 邓斌
Bean Deng 邓斌
Hi, @farnabaz . I created a PR #2729 fixed this problem. Please take a look.
建议 reopen 下这个 issue 吧，经常遇到
在服务前架一个 nginx，临时将 /feeds/ 目录的请求代理到某个目录，目录下放一个之前返回的 xml，并修改其中认证相关的 description，等认证完成之后再去掉这层拦截就好了。 ``` location /feeds/ { default_type application/xml; alias /etc/nginx/static/feeds/; } ```
再补充一次测试截图，操作就是 CloudSync 一直在上传新的文件，内存使用一直在线性上升。
@Mmx233 我刚试了 `mmx233/alist:v3.36.0-gamma2` 镜像也是一样的情况。你有测试的脚本吗？我看看在我的环境中用你的脚本能不能复现，看看能不能帮助定位到问题
使用环境 - 宿主机：`群晖 DS918+` - 宿主机 DSM 版本：`DSM 7.2.1-69057 Update 5` - 宿主机 CPU：`INTEL Celeron J3455 (amd64)` - 宿主机内存：`12G` - 系统内核版本：`4.4.302+` - Docker 版本：`20.10.23` - 镜像版本：`v3.34.0`（之前使用 `v3.36.0`、`main` 发现有内存问题，昨晚尝试回退到 `v3.34.0` 测试的）...
上面的测试是昨晚基于 `v3.34.0` 的结果，我待会儿重新做一个基于 `mmx233/alist:v3.36.0-gamma2` 的测试
测试镜像：`mmx233/alist:v3.36.0-gamma2` 容器 compose： ```yaml services: alist: image: mmx233/alist:v3.36.0-gamma2 container_name: alist network_mode: bridge volumes: - ./data:/opt/alist/data ports: - 10008:5244 environment: - PUID=0 - PGID=0 - UMASK=022 - TZ=Asia/Shanghai restart: unless-stopped ```...
> 如果设置是 webdav 走本机代理，且 alist 使用纯内存缓存的话（我还没看这部分代码），在持续上传的场景的下可能不是内存泄漏而是没上传的部分全在内存里的问题 没有开启 Web 代理，webdav 策略是 302 重定向
> 添加本机存储驱动后，在网页上复制的内存占用呢？ @pongfcnkl 通过网页复制 `本机存储` 的文件到 `115网盘` 的内存使用情况和通过 webdav 上传看起来不太一样： - `18:21:07`：通过 alist 网页开始上传文件至 `本机存储` - `18:23:35`：上传完成，Memory Usage 没有发生任何变化，但 Memory Cached 增加了 300 多 M，差不多等于文件总大小 - `18:33:00`：等待了10分钟，Memory Cached 没有释放 -...