@opengps 可能有个超时切换重连时间，如果能设置得短一点就好了，不知道官方是否提供这种配置透出

我的还好，1890M
root@ecs:~# free -m
total used free shared buff/cache available
Mem: 1890 223 107 2 1558 1496
Swap: 0 0 0
root@ecs:~# date

@SkywalkerJi 国内的看得多了，想看点国外有技术含量的，谢谢推荐

@julyclyde 有道理，我 test 下

@chroming 有可能是这个逻辑导致的，之前其他的 python 程序并没有发生这种情况，这样说 docker 的 volume 是要绑定 inode 的？

@Puteulanus 这个算解压吧

@SkywalkerJi 感谢。 有几个 NAS 的评测，如钱韦德，司波图之类的，还有硬件类的 AK ，这几个咋样？

@EricFuture 谢谢，我喜欢油管

@villivateur 展开讲讲？

@chroming 有文件的拆分动作，比如一个大文件拆成 10 个小文件，但是大文件一直有新增，这个也会导致 inode 变化？

@julyclyde 对的

@chroming 这个应该没有，就是新增文件

@Honkaiteio 里面就是个 while True 循环，然后每次循环都会重新去 list mount point 里的文件，按理说没啥问题啊

@julyclyde 容器部署维护简单。最终通过多线程+多路代理搞定了并发处理的需求。

@julyclyde docker-compose.yaml 文件

version: "3"
services:
pro:
build: .
container_name: subtitles_translator
restart: always
volumes:
- /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime
- ./translator.py:/app/translator.py
- ./logs:/app/logs
- "/truenas_pool/video:/video"

备份用 unraid 默认的 VM backup ，还可以

谢谢各位，我用单线程和多线程来试试。

@lianyue 1 每个文件处理时间大概 10 都 60 分钟不等，看文件大小
2 ，对 cpu 占用有一定的开销，是 cpu 计算型应用
3 ，每天新增 10-50 个文件
4 ，是本地文件，在一个目录下

@shendaowu 反复确认的肯定能记住，就怕灵感稍纵即逝想不起来了，总会有 xx%的遗忘，这部分也许是最宝贵的